|
|
My concern is with the requirement that a host MUST support both Tunnel and
Transport Mode. A large enterprise most likely has its own VPN today. For it
to not trust its Intranet is a question they already addressed. Instead of
imposing another layer of IPSec for the enterprise, we ought to make it easy
for them to use their existing VPNs for securing transport over the Internet.
Bottom line, I think we should go with Tunnel Mode, that can be deployed
anywhere in the customer environment, and leave it up to the customer and
vendor to determine where exactly to deploy the Tunnel Mode. Transport Mode
should be Optional and let the market demand vs cost drive its
implementations.
Trust the customer!
Funny because RFC 2401 says (Section 4.1)
"
In summary,
a) A host MUST support both transport and tunnel mode.
b) A security gateway is required to support only tunnel
mode. If it supports transport mode, that should be used
only when the security gateway is acting as a host, e.g.,
for network management.
"
I am assuming that at least one end of the iSCSI implementation is a Host
(if not both ends) and therefore will have a conformant IPsec
implementation...
Now the question is where do we want to allow security endpoints to be. If
we want to allow only host-host security (and the requisite policy
nightmares) then Transport Mode will work. However if we want to allow
Tunneling between hosts and security gateways, then Tunnel mode will need to
be used. In reality I think we should stick with the 2401 requirements,
that way I don't have to write my own implementation...
I have not seen a call of consensus on this issue, have you issued it David
?
Bill
+========+=========+=========+=========+=========+=========+=========+
Bill Strahm Software Development is a race between Programmers
Member of the trying to build bigger and better idiot proof software
Technical Staff and the Universe trying to produce bigger and better
bill@sanera.net idiots.
(503) 601-0263 So far the Universe is winning --- Rich Cook
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Saqib Jang
Sent: Thursday, November 01, 2001 10:03 AM
To: Ofer Biran; ips@ece.cmu.edu
Subject: RE: iSCSI: IPsec tunnel / transport mode decision
I thought the latest security draft already closed
on this issue.
>From Section 2.3 of -04 draft.
iSCSI security implementations MUST support ESP in transport mode.
Saqib
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Ofer Biran
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: Thu Nov 01 21:17:34 2001
7524 messages in chronological order
|
