Re: IPSEC target and transport mode

["John Hufferd" <hufferd@us.ibm.com>]

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