RE: iSCSI: IPsec tunnel / transport mode decision

["Bill Strahm" <bill@sanera.net>]

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
|