[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> 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 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?
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?
Charlie