Note subject change. Further, we seem to be diverging past the original *intent* of the discussion. I'll clarify what I thought I was talking about.
I want clarification of the implementation when there is
1) a single SA payload
2) in a single quick mode negotiation
3) between 2 peers only
4) there are multiple proposals, and
5) the proposals have the same proposal number.
There are 2 issues (and they are sort of separate).
1) What is the order of application of the negotiated services (ESP, AH, IPCOMP)?
2) What encapsulation mode is specified and used for each of those services.
Options, Order Issue
1) The services are applied in the order proposed, in the outbound direction. For example, if ESP+IPCOMP+AH is proposed, the packet looks like (ignore encapsulation for now, please)
| AH | IPCOMP | ESP | packet |
2) The services are applied in the order proposed, in the inbound direction. Same example:
| ESP | IPCOMP | AH | packet |
3) The services are applied on reasonable rules of application, regardless of the order of proposal. Same example:
| AH | ESP | IPCOMP | packet |
Discussion, Order Issue
If option 1 or 2 is chosen, then the responder must not change the order of the proposals. While this allows more flexibility, most of that additional flexibility probably has debatable value. (Remember, we're talking about a single connection between two peers, not layered SAs between different peers.)
Proposal 3 may ease implementation issues.
Options, Encapsulation Issue
1) Each service specifies its encapsulation mode. This means that the services are not conceptually treated as a single SA.
2) The services are conceptually treated as a single SA, and they all specify tunnel encapsulation for an tunnel mode SA, and they all specify transport encapsulation for a transport mode SA.
3) The services are conceptually treated as a single SA, and the they are all specify transport encapsulation for a transport mode SA, but the inner-most service specifies tunnel mode encapsulation and all other services specify transport mode encapsulation for a tunnel mode SA.
Discussion, Encapsulation Issue
I don't see any reason to support option 1. First, it's not compatible with option 3 for the order issue. Second, the use of any additional IP headers between the services' headers appears to be a waste of bandwidth without providing any additional services.
Option 3 might ease implementation issues, since that's the effect of iterating SAs, but it's not compatible with option 2 of the order issue either.
Votes
My votes are for option 3 of the order issue (even though we've already implemented option 1) and option 2 of the encapsulation issue.
Note that this particular choice does not preclude the negotiation of different SAs between the same peers to get the effect of multiple separate SAs.
More below as well...
---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.on.ca]
> Sent: Thursday, November 05, 1998 4:20 PM
> To: ipsec@tis.com
> Subject: Re: IBM VPN Bakeoff Issues
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> [WRT: Tim comments and Paul's response, no specific quote]
>
> While I think that a definitive order is good, because it makes
> analysis easier (fewer combinations == less work), I am concerned
> about Tim's proposal about amalgamating headers. Before you
> comment on that: read the archives.
>
I did that in part to illustrate the concept of how I think proposals with the same proposal number in the same SA payload should be treated. I'm not terribly opinionated on that particular aspect of this issue.
> I am further concerned that the needs of the host, and the
> host+gateway^n+host are not clear enough to start putting restrictions
Could you elaborate on this? What host needs are you referring to?
> in the *spec*. If ISCA wants to certify a portion, or certain options,
> that is fine (and should be encouraged), but I don't think we should
> change things.
> Except for buggy code, why would an implementation that wants to do:
> IP|ESP|IPCOMP|IP
> or
> IP|AH|IP|ESP|IP|IPCOMP
>
> specifiy anything other than the order listed in an IKE proposal?
>
Why?
1) Because most vendors haven't implemented it that way based on the assumptions of reasonable use. Which we don't seem to have an real disagreement with. "Because we can" is not always a valid reason for doing something.
2) Because (at least) two vendors that did use ordered proposals came up with the opposite order. They both wanted the same thing, but they wouldn't have been able to negotiate it.
And we still don't seem to have much comment on the encapsulation assignment. As I said before, if you allow the proposals to be order independent, then you've got to add a rule about encapsulation.