RE: IPSEC target and transport mode

[Black_David@emc.com]

I need to clarify one thing in John's post --

Transport mode was never an unqualified "MUST implement".  Rather
it was qualified in Huntington Beach as "MUST implement when RFC
2401 says it MUST be implemented".  That difference is crucial,
as the following paraphrased Q&A from the Huntington Beach
meeting on this topic illustrates:

Q: Is this a subterfuge to force FCIP to implement Transport mode?
A (David Black): No, gateway implementations would still be allowed,
	and Transport mode would not be required.

As I said earlier, in my opinion, WG rough consensus for an unqualified
"MUST implement" for transport mode cannot be obtained (e.g., see above
Q&A).  My current opinion is that the performance argument (one less
encapsulated header on the wire for each packet) for transport mode is
sufficient to justify only a SHOULD, not a MUST.  OTOH, Bernard's
"complicates routing considerably" argument could justify a MUST,
although I'm not sure whether the VPN/remote access considerations that
motivate it apply to IP Storage.

Meanwhile, several problems with RFC 2407 have turned up in the area of
transport/tunnel mode negotiation -

(1) Section 4.5 says that for transport/tunnel encapsulation mode:
           If unspecified, the default value shall be assumed to be
           unspecified (host-dependent).
	That needs to be overridden to say that the default mode in
	the absence of negotiation MUST be tunnel mode.  I have no idea
	how text with such an obvious interoperability issue got approved.
(2) Section 4.5.1 makes support for encapsulation mode negotiation
	OPTIONAL.  That needs to be overridden to a SHOULD assuming
	that the previous item is done.  If the previous item is not
	done, the override will need to be to a MUST for interoperability.
(3) Section 4.5.3 says:
	   If an implementation receives a defined IPSEC DOI attribute (or
	   attribute value) which it does not support, an
ATTRIBUTES-NOT-SUPPORT
	   SHOULD be sent and the security association setup MUST be
aborted,
	   unless the attribute value is in the reserved range.
	This has previously been identified as a potential source of
	interoperability problems - it has not cropped up in practice
because
	most IPsec implementations seem to support a common set of useful
	attributes in 2407.  If (2) is a SHOULD, the above paragraph will
	need to be overridden to say something like:
         If an implementation receives a set of proposals each of which
	   contains a defined IPSEC DOI attribute (or attribute value)
         which it does not support, an ATTRIBUTES-NOT-SUPPORT
	   SHOULD be sent and the security association setup MUST be
aborted,
	   unless the attribute value is in the reserved range.
Implementations
	   SHOULD examine all proposals in a set in an effort to find at
least
         one that consists entirely of attributes and attribute values that
         the implementation does support.
	As I said, I don't believe this has been a problem in practice, but
	it deserves to be corrected before it becomes one.  This change has
	been reviewed with the ipsec WG in the past and received their
support
	as something that should be changed when RFC 2407 is revised.

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
---------------------------------------------------


> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Sunday, March 31, 2002 12:24 AM
> To: Bernard Aboba
> Cc: thorpej@wasabisystems.com; ips@ece.cmu.edu
> Subject: Re: IPSEC target and transport mode
> 
> 
> 
> Well, as usual, I replace the term Transport, with Tunnel until no one can
> understand what I intended to say.  Corrections below following the xxxxxx
> which crossed out the word Tunnel.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
> 
> 
> John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 03/30/2002 05:58:24 PM
> 
> Sent by:    owner-ips@ece.cmu.edu
> 
> 
> To:    "Bernard Aboba" <bernard_aboba@hotmail.com>
> cc:    thorpej@wasabisystems.com, ips@ece.cmu.edu
> Subject:    Re: IPSEC target and transport mode
> 
> 
> 
> 
> These reasons you mentioned here, and the resulting performance were some
> of the reasons I thought we voted to make Transport a "Must implement".
It
> is also true that David Black may have caused some of the Tunnel folks to
> have rolled over on this issue, but I believe, a number of folks
understood
> various aspects of what you have said here, and wanted to use xxxxxx
> Transport mode,
> and wanted it to be a "Must Implement" since if xxxxxx 
> Transport mode, is not
> implemented by the other side, it can cause your side to have poorer
> performance, even if you can support the higher performance that come with
> Transport mode.
> 
> But more then David's statements, the thing that I understood helped get
> agreement on the MUST/MUST for Transport and Tunnel, was the fact that
> almost all the IPsec stacks that are available on the market come with
both
> Transport and Tunnel.  So it is now possible for iSCSI to not only operate
> at high speed, and support the key features mentioned below, but can
> interoperate with HW that can only pass through Tunnel mode.
> 
> I feel that Transport is the most capable and high performance mode, but
> feel that tunnel is also needed for firewalls that do not accept Transport
> at this time.  But, it seems clear to me, that if we have Transport mode
as
> a MUST (along with Tunnel), that the various hardware along the way, such
> as the firewalls, will be quickly adjusted to support Transport, since
each
> vendor will see the potential advantages of having their product support
> iSCSI traffic in the most efficient manner.  However, we will be able to
> operate with Tunnel mode until most vendors HW will be able to support
> Transport mode through their equipment (such as firewalls etc.)
> 
> So again, I feel that our original vote to support both Transport and
> Tunnel as Must implements, was the right decision, and best for iSCSI and
> the customer.
> 
> I propose we let the original agreement stand.
> 
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Home Office (408) 997-6136, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
> 
> 
> "Bernard Aboba" <bernard_aboba@hotmail.com>@ece.cmu.edu on 03/30/2002
> 05:51:18 AM
> 
> Sent by:    owner-ips@ece.cmu.edu
> 
> 
> To:    thorpej@wasabisystems.com, ips@ece.cmu.edu
> cc:
> Subject:    Re: IPSEC target and transport mode
> 
> 
> 
> >I really don't like this idea.
> >
> >While it is true that Tunnel Mode
> >does not require the use of a gateway, Transport Mode is actually
> >the more general mode.
> >
> >It is possible to combine Transport Mode with any arbitrary
something-in-IP
> >tunneling protocol (IP-IP, GRE, etc.).  In the case of Transport Mode +
> >IP-IP tunneling, you achieve something that is equivalent to Tunnel Mode,
> >thus satisfying those who need it (I suggest that everyone read
> >draft-touch-ipsec-vpn-03.txt).
> 
> Having worked with transport mode tunnels for a few years now (L2TP), we
> have come to the same conclusion. By linking SA selection to next hop
> forwarding, tunnel mode complicates routing considerably.  Transport mode
> tunnels are more compatible with dynamic routing protocols. Today most
> tunnel mode vendors only support either static routing or BGP run down the
> tunnel, and that makes it very difficult for enterprise customers to
manage
> and deploy large numbers of tunnels.
> 
> Although it can be done, Tunnel mode is also more difficult to implement
as
> an interface than Transport mode IP-IP. There already is pushback on iSCSI
> HBAs that cannot act as a full fledged interface; this will ensure that
> this continues to be a problem many years into the future.
> 
> >Transport Mode is also less expensive from a processing point of view.
> >If you use Tunnel Mode with no gateway (i.e. inner-dest==outer-dest,
> >outer-source==inner-source), you still have to de-encap the packet and
> >re-process it, which is something you don't have to do in Transport
>Mode.
> 
> It would seem to me that this additional cost might be a concern in the 10
> Gbps case in particular.
> 
> 
> _________________________________________________________________
> Chat with friends online, try MSN Messenger: http://messenger.msn.com
>