SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: IPsec tunnel / transport mode decision



    Ok,
    
    I have implemented IPsec (both Transport & Tunnel) as a Win32 Intermediate
    Driver for Win 9x/NT 4 (We didn't need it in W2K because it is implemented
    there all ready).  I have also implemented it as a set of Linux Netfilter
    rules for the 2.4 kernel...  I would consider both of these BITS
    implementations and I consider these as OS modifications (all though
    depending on if you consider the drivers as a part of the OS they may not
    be)
    
    There are a few optimizations that you can make if you actually own the TCP
    stack.
    1) Setting the MTU for the connection to take out the size of the IPsec
    overhead, however you can use ICMP error messages from the IPsec layer to do
    the same thing.
    2) Handling TCP timeouts while a SA is negotiated.  My implementation would
    drop the first TCP/SYN packet while the negotiation was going on, then send
    the second packet that comes down, usually after the negotiation went
    through... The other option was to send the TCP/SYN packet in the clear...
    
    BITW implementations have many of the same things to do, the only difference
    is that it happens after it goes through Ethernet processing... I have heard
    of an implementation that went through a Linux TUN(???) driver to pass the
    full Ethernet packet up to user space to have the IPsec processing done on
    it before passing back down as a raw Ethernet packet to go out eth0...  Then
    there are external gateways that we are all familiar with...
    
    I am interested in external gateways mainly because they are
    1) Purchasable off of the shelf
    2) Don't have integration requirements - just tell the customer to buy two
    and get them to work, we run over it
    
    Bill
    
    -----Original Message-----
    From: CAVANNA,VICENTE V (A-Roseville,ex1)
    [mailto:vince_cavanna@agilent.com]
    Sent: Friday, November 02, 2001 9:29 AM
    To: 'Bill Strahm'
    Cc: SHEEHY,DAVE (A-Americas,unix1); CAVANNA,VICENTE V (A-Roseville,ex1);
    'Ofer Biran'; ips@ece.cmu.edu
    Subject: RE: iSCSI: IPsec tunnel / transport mode decision
    
    
    Good Morning Bill,
    
    To me, a BITS implementation of IPSec does not require changes to the OS
    (with its built-in network stack) and is in fact useful when such changes
    are not feasible. In BITS, I assume IPSec is implemented as a shim between
    the network and data link layer. I thought, from reading the literature,
    that this was a conventional definition of BITS.
    
    If you are allowed to make changes to the network stack when adding IPSec
    functionality then, as I noted in my original memo, I consider transport
    mode to be feasible .
    
    If I understand you correctly then, what you really favor is a BITW
    implementation which I understand to be essentially an external crypto
    device. I would like to be able to use that too, but only provisionally, as
    a BITW implementation will eventually (as iSCSI matures) be considered too
    expensive and IPSec will have to be incorporated more tightly into the
    network stack.
    
    Vince
    
    -----Original Message-----
    From: Bill Strahm [mailto:bill@Sanera.net]
    Sent: Thursday, November 01, 2001 10:18 PM
    To: CAVANNA,VICENTE V (A-Roseville,ex1); 'Ofer Biran'; ips@ece.cmu.edu
    Cc: SHEEHY,DAVE (A-Americas,unix1)
    Subject: RE: iSCSI: IPsec tunnel / transport mode decision
    
    
    Ok,
    
    First off with complexity comes a configuration nightmare...
    
    Second I can implement both a BITS and a BITW IPsec Transport and Tunnel
    mode... it really isn't all that hard.  BITS implies that you are making OS
    changes, or at least changes under the TCP/UDP layer that is traditionally
    exposed to user applications, so I think most of the argument you are trying
    to make in your second paragraph doesn't hold much water for me.  I would
    rather use Tunnel mode myself, however my reasons are that I can completely
    offload the implementation off of the host and target and let intermediate
    devices deal with security policies and such things... However most of the
    tone of the security draft is to require for at least one end if not both to
    be intimately aware of what is going on with security...
    
    Bill
    
    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    CAVANNA,VICENTE V (A-Roseville,ex1)
    Sent: Thursday, November 01, 2001 5:19 PM
    To: 'Ofer Biran'; ips@ece.cmu.edu
    Cc: CAVANNA,VICENTE V (A-Roseville,ex1); SHEEHY,DAVE (A-Americas,unix1)
    Subject: RE: iSCSI: IPsec tunnel / transport mode decision
    
    
    It seems to me (who has not had the experience of implementing IpSec) that
    tunnel mode, even when implemented in the end host (rather than in a
    router), is a superset of transport mode whose only significant disadvantage
    is that tunnel mode requires more overhead in the form of the extra IP
    header. On the other hand, tunnel mode offers more flexibility in
    implementation as it is easier to implement in BITS and BITW implementations
    whereas transport mode can only be easily implemented when IPSec is
    implemented as part of the network layer i.e. integrated into the OS. The
    reason is that the IPSec headers are inserted AFTER the IP payload is
    constructed. This means that IPSec has to duplicate IP functionality because
    it has to recalculate the IP checksum and fragment the packet when
    necessary.
    
    I would support making tunnel mode the favored mode in iSCSI. IPSec
    compliance requires that transport mode be implemented but if iSCSI
    discourages it the implementation need not be as efficient as tunnel mode.
    
    Vince
    
    |-----Original Message-----
    |From: Ofer Biran [mailto:BIRAN@il.ibm.com]
    |Sent: Thursday, November 01, 2001 4:31 AM
    |To: ips@ece.cmu.edu
    |Subject: iSCSI: IPsec tunnel / transport mode decision
    |
    |
    |I'd like to drive this open issue into group consensus. It seems to
    |me that the tendency was more toward making tunnel mode a MUST as iFCP
    |and FCIP did, mainly due the option of integrating an existing IPsec
    |chip/box with the iSCSI implementation offering. If we reach
    |this decision,
    |we may choose even not to mention transport mode (as MAY or some other
    |recommending text).
    |
    |There is an excellent analysis made by Bernard Aboba in Section
    |"5.1. Transport mode versus tunnel mode" of draft-ietf-ips-security-04
    |( http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt )
    |that can help us with this decision (also Section "5.2. NAT
    |traversal" is
    |relevant).
    |
    |   Regards,
    |     Ofer
    |
    |Ofer Biran
    |Storage and Systems Technology
    |IBM Research Lab in Haifa
    |biran@il.ibm.com  972-4-8296253
    |
    
    


Home

Last updated: Sun Nov 04 07:17:49 2001
7546 messages in chronological order