Subject: iSCSI: Alias consensus call

From: [email-masked]
Date: Sat, 18 Aug 2001 15:08:32 -0400

Traffic on this topic has died down, so I believe that the
rough consensus of the IPS WG is to retain support for Alias
in the iSCSI protocol.

I have seen two expressions of the opposite view:
- Bob Snively's, which I am setting aside, as not
	being relevant to the topic - Bob's post
	concerned LU aliases rather than Initiator/
	Target aliases.
- Marj Krueger's, which I take note of in making this
	call (i.e., the consensus call is over Marj's
	objection).

Anyone other than Marj who wishes to object should post
to the list.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 20 Aug 2001 17:07:07 -0700

David,

The human abstraction offered by an alias may be misleading and in some
cases could be best handled by a management scheme that better understands
user's perspectives and can provide clues within the name to its real
designation.  This places fewer burdens on future transports should the
alias feature be removed.  In the end, a management scheme should be more
friendly than an odd collection of labels.  Here less is more but not in
keeping with the all-in-one approach.

Doug

---

From: Bill Strahm <[email-masked]>
Date: Mon, 20 Aug 2001 17:10:04 -0700 (PDT)

David,

I am becoming more and more concerned about the IPS security strategy the
longer I think about having to implement this into product.  The first
problem with defining a new keying standard is that an iSCSI vendor will
have to implement this keying standard, and then on a per OS bassis
attempt to push a negotiated key down into the IPsec layer to handle the
correct iSCSI traffic.  Many of these interfaces will be difficult to
find, if they are available at all...

I want to propose that our security story cover
1) Defining a security policy that can be used to cover iSCSI traffic
2) Allowing end users to use this security policy with their OSes current
IPsec stacks (on both the client and target end), or integrating an IPsec
stack into products
3) Allowing the IPsec WG cover all aspects of algorithm selection, key
negotiating, encapsulation, etc. that are needed

This will allow the IPS working group do what we do best, and allow the
IPsec WG to do what they do best, and lead to interoperating products the
fastest

Bill Strahm
Sanera Systems Inc.