Subject: I-D ACTION:draft-ietf-ips-security-04.txt

From: [email-masked]
Date: Thu, 25 Oct 2001 07:03:43 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Storage Working Group of the IETF.

	Title		: Securing iSCSI, iFCP and FCIP
	Author(s)	: B. Aboba et al.
	Filename	: draft-ietf-ips-security-04.txt
	Pages		: 56
	Date		: 24-Oct-01
	
This document discusses how iSCSI, iFCP, and FCIP utilize IPsec to
provide security.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ips-security-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ips-security-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Saqib Jang" <[email-masked]>
Date: Fri, 26 Oct 2001 12:02:05 -0700

Have a couple of quick questions about the transport vs. tunnel mode;
discussion in the firewall traversal section of the latest draft.
The section reads:

     Firewall traversal. Where a storage protocol is to traverse
     administrative domains, the firewall administrator may desire to
     verify the integrity and authenticity of each transiting packet,
     rather than opening a hole in the firewall for the storage
     protocol. IPsec tunnel mode lends itself to such verification,
     since the firewall can terminate the tunnel mode connection while
     still allowing the endpoints to communicate end-to-end. If desired,
     the endpoints can in addition utilize IPsec transport mode for end-
     to-end security, so that they can also verify authenticity and
     integrity of each packet for themselves.

My question is how important is the requirement for firewall adminstrators
to "verify the integrity and authenticity of each transiting packet" if
the iSCSI endpoints are using transport-mode IPsec/ESP (implying
authentication
and integrity checking) connections. Why would (in this case) opening a hole
in the firewall to allow traversal of IPsec traffic not be sufficient? Also,
are there potential latency issues that may arise if the firewall
is terminating IPsec (vs. iSCSI end-points terminating IPsec). I see
the emergence of IPsec acceleration in iSCSI end-points (vs. in
general-purpose
firewalls) to be a more like scenario.

Saqib

Saqib Jang
Margalla Communications, Inc.
3301 El Camino Real, Suite 220
Atherton, CA 94027
Ph: 650 298 8462
Fax: 650 851 1613