---
Tim Jenkins TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Charles Lynn [mailto:clynn@BBN.COM]
> Sent: Wednesday, November 04, 1998 9:53 PM
> To: Tim Jenkins
> Cc: IPSEC Mailing List
> Subject: Re: IBM VPN Bakeoff Issues
>
>
> Tim,
>
> > If we consider that a fixed order is assumed, and that we will never
> > support ESP and ESP, there are only 4 kinds of bundles possible:
> > IPCOMP+ESP, IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH.
>
> I do not agree with this; maybe its just mixed terminology again.
> I thought that a "bundle" was a set of SAs that were all applied to
> a packet in a single security gateway, originating (or terminating).
> If that definition is correct, it does not say anything about the
> other end of those SAs having to terminate (or originate) at a
> single security gateway. Thus one can certainly have an ESP + ESP
> "bundle", etc. (both originating at SG1 and one terminating at SG2
> and the other at SG3).
>
> Your example is only for SAs that all begin at one SG (SG1) and all
> end at a second SG (SG2), correct? I.e., for AH/ESP/IPCOMP between a
> pair of IP headers, or between an IP header and the Upper
> Layer Protocol.
Yes, that's right. More specifically, it relates to the interpretation of proposals offered in the same SA payload that have the same proposal number.
>
> > We should conceptually think of bundles as a single SA that provides
> > multiple services.
>
> Ok.
>
> > This means that all three services expire at the same time and are
> > re-keyed at the same time.
>
> In the reverse of the split case mentioned above, I suspect that it
> would be hard to get SG1 to agree on a single time when the separate
> SAs established by SG2 and SG3 are created. If SG3 initiates, SG2
> may hold the ISAKMP until it negotiates an SA with SG1, then pass
> the SG3 ISAKMP through the SG2-SG1 SA to create the SG3-SG1 SA.
This is a different. Here, IMHO, the SAs between SG2 and SG3 by SG1 are independent. If we use the case where a host behind SG1 is attempting to communicate securely with a host behind SG3, SG1's policy probably says that an SA is needed with SG3 to get to the second host. Then, its policy says that it needs an SA with SG2 to talk to SG3. The are negotiated independently: in completely separate SAs.
>
> > This means that a gateway always offers tunnel mode for all three
> > services, since the bundle as a whole is in tunnel mode.
>
> (Except when the gateway is an endpoint of a communication.)
> Thus I'm not sure that limiting the cases as you suggest will actually
> make the implementations very much simpler.
>
> > For IPSecond:
> > In order to reduce any ambiguity of implementation, I would
> suggest that
> > we consider picturing these four combinations as their own
> protocols,
> > with a single header that contains only the necessary information:
> ...
> > A closer examination suggests that this 'super' header could be
> > identical to the AH protocol header,
>
> But it uses a new, distinct extension header (protocol) number, right?
If this was done, there would have to be 4 new protocol numbers.
> BTW, how would the next/Upper Layer Protocol be processed? The strong
> ESP folk would not want it exposed in the header shown, even
> though the
> firewall/diff serv folks may welcome the ability to expose it. One
> could say if it is zero in the header, then it is the usual
> ESP location,
> and if not zero, its the next extension/Upper Layer Protocol number.
> MUST one verify the header value is identical to the ESP location one?
These are all good points. But it's possible that this proposal has been raised before. Partly, I wanted to get people thinking conceptually this way, in order to help solidify the rules for SA bundles negotiated as part of the same SA proposal.
>
> Charlie
>