RE: IPSEC target and transport mode

["Sperry, Todd" <Todd_Sperry@adaptec.com>]

David,

> What I've heard is a desire to use existing gateway implementations of
> IPsec that don't support tunnel mode well or at all due to:
                           ^^^^^

Did you mean to say transport?
Again, I believe thats the case - but I don't believe thats
sufficient reason to override 2401.

> The WG contains both communities and "rough consensus" needs to span them.


Agreed.  The concensus in the IPSec WG is MUST/MUST.  2401
says so.  We had a unanimous vote in HB for the same thing.  We
did not have that in Minn. 

> I take strong exception to the argument that only IPsec transport
> mode can deliver end-to-end security;

Agreed.  I never said it was not possible - I only alluded to
our preference to achieving the host/host scenerio using 
Transport mode.

There's no reason that I know of to lock out Transport mode. 
2401 does not require gateways to use/implement it.  

Give transport mode a chance.  I'm hearing that we have allowed
2 weeks for draft completion of  CHAP+DH.  I'm assuming there
will be a vote.  Let's take a vote on MUST/MUST as well.  Then,
let's get on with last call.

Thanks,
Todd.

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, April 03, 2002 2:13 PM
To: Todd_Sperry@adaptec.com; ips@ece.cmu.edu
Subject: RE: IPSEC target and transport mode


Todd,

> I still don't understand the rationale for overriding the language
> in 2401, part 'a'.
> 
> 	In summary,
>            a) A host MUST support both transport and tunnel mode.

What I've heard is a desire to use existing gateway implementations of
IPsec that don't support tunnel mode well or at all due to:

>            b) A security gateway is required to support only tunnel
>               mode.  If it supports transport mode, that should be used
>               only when the security gateway is acting as a host, e.g.,
>               for network management.

Which leads to what I wrote in the original message:

> >If I were starting from a clean sheet of paper without regard to existing
> >IPsec implementations/technology/etc., I would be inclined to do as Jason
> >suggests.  However, we are not in that situation.
> >The current situation is that there is significant interest in the WG in
> >using existing IPsec systems/devices/etc. to address this area of
> >functionality;

As for new devices and existing devices:

> There are plenty of people/companies building new devices, as well.  Some
of
> those, including my company, are interested in Transport mode support.
> Your argument in the past has been "you can still do that -  its a MAY".
> I really can't agree with that when we're thinking about interop.

The WG contains both communities and "rough consensus" needs to span them.  

> The MUST/MUST language was fine.  2401 says its the right thing to do.
> The requirement for IP storage is end-to-end.  

That's back to the "clean sheet of paper" argument for those building new
devices.  I take strong exception to the argument that only IPsec transport
mode can deliver end-to-end security; security policy and distribution of
IKE authentication material is far more important and can yield end-to-end
security in tunnel mode when done right and lack of end-to-end security
in transport mode when done wrong - L2TP security is resulting in the
creation of security gateway-like entities that use transport mode among
themselves.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------