[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IBM VPN Bakeoff Issues



Title: RE: IBM VPN Bakeoff Issues


---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617


> -----Original Message-----
> From: Richard Draves [mailto:richdr@microsoft.com]
> Sent: Thursday, November 05, 1998 1:25 PM
> To: 'Stephen Waters'; Tim Jenkins
> Cc: ipsec@tis.com
> Subject: RE: IBM VPN Bakeoff Issues
>
>
> > Yes, a point that was not raised at the workshop.  We did a
> > test with AH+ESP
> > in tunnel mode. We took this to mean AH+ESP adjacent with a
> > shared tunnel
> > header.  The other vendor took this to mean
> > IP1+AH+IP2+ESP+IP3.  There was
> > some agreement that a proposal that offered AH-tunnel AND
> > ESP-tunnel should
> > mean a shared tunnel-header, but maybe we need more text somewhere.
>
> Maybe I'm not understanding this. Looking at the four
> possible combinations,
> this is my understanding of how transport & tunnel mode combine:
>
> AH-transport + ESP-transport:
>       IP1 AH ESP transport
> AH-transport + ESP-tunnel:
>       IP1 AH ESP IP2 transport
> AH-tunnel + ESP-transport:
>       IP1 AH IP2 ESP transport
> AH-tunnel + ESP-tunnel:
>       IP1 AH IP2 ESP IP3 transport
>
> Rich
>

You are correct in how they combine if that's what you explicitly negotiate. But why would you negotiate the third and fourth examples within a single SA payload?

I think we should allow only the first and the second of the two above. Further, since I'm clinging to the concept of multiple services in a single SA, I want to specify all the transforms in the proposals as tunnel and get example 2 above, and if I use transport, get example 1 above.

If we decide that proposed order within an SA payload is meaningless, we have to do the same for the encapsulation as well, since the encapsulation attribute is tied to the proposal or transform, rather than the SA payload.


Follow-Ups: