SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    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
    
    
    
    
    
    
    
    


Home

Last updated: Mon Apr 01 12:18:17 2002
9412 messages in chronological order