Subject: [Ips] X#NodeArchitecture draft - next steps

From: [email-masked]
Date: Mon, 27 Mar 2006 11:46:25 -0500

This draft is better known as: draft-wysochanski-xkey-iscsi-support-00.txt

This draft will be an official WG draft, but three things
need to happen first:

(1) New security text.  The existing "SHOULD" in the security
	considerations text needs to be a "MUST".  In addition,
	there needs to be a sentence pointing out that it may
	be important to shield the contents of this key from
	observers of network traffic, and that IPsec as specified
	for iSCSI in RFC 3720 and 3723 (cite both of them) is an
	appropriate tool for this purpose.

(2) New "prevention of abuse" text.  The current "The key MUST NOT
	be used by iSCSI nodes for things such as ..." is well-
	intentioned but does not get the job done.  My recollection
	of discussion in Dallas is that saying that "functional behavior
	of the iSCSI node MUST NOT depend on this key (presence/absence
	or value)"  may be closer to the mark.  The only permitted
	(and intended) use of this key is to report it/log it in order
	to avoid the browser detection JavaScript disasters caused by
	the corresponding HTTP header fields.

(3) The draft needs a new title and file name ("supportability" just
	reeks of marketing ;-) ).  Let's try:

	   The iSCSI X#NodeArchitecture Key
	draft-ietf-ips-iscsi-nodearch-key-00.txt

Text for (1) and (2), or at least initial versions of it should be
worked out on the list before the -00 version of the draft-ietf-ips-...
draft is submitted.  I've just sent the request to the secretariat for
an end-of-2006 completion milestone for this, but in practice, it
could be done shortly after Montreal, if not before.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Dave Wysochanski <[email-masked]>
Date: Fri, 31 Mar 2006 21:34:57 -0500

[email-masked] wrote:

> This draft is better known as: 
> draft-wysochanski-xkey-iscsi-support-00.txt
>
New proposed text:

3.  Security Considerations 

   In certain environments where security is a primary concern,
   the use of this extension key may not be appropriate as it
   reveals specific details about an iSCSI node.  For these
   environments, nodes implementing this public extension key
   MUST provide a method to disable sending the key.  In
   addition to providing a disable mechanism, security sensitive
   environments SHOULD consider use of IPsec, as specified in 
   RFC 3720 and 3723, as a means to shield the contents of this
   key from observers of network traffic.

Original text:      

3.  Security Considerations 

   In certain environments where security is a primary concern,
   the use of this extension key may not be appropriate as it
   reveals specific details about an iSCSI node. For these
   environments, nodes implementing this public extension key
   SHOULD provide a method to disable sending the key.

>         the corresponding HTTP header fields.

I wasn't sure about deleting the original "MUST NOT" sentence so I left 
it in.  Anyone
have a preference?  Also wasn't sure whether it's worth putting in a 
sentence or two at
least acknowledging what has happened in the past with User-Agent -- 
intent would be
the working group acknowledges this historical misuse and wishes to 
avoid it.

New proposed text:

   The following described Public Extension Key is sent during
   the login phase of an iSCSI normal session.  It is important
   to note that the proper use of this key is to provide enhanced
   logging and support capabilities, and for better understanding
   of customer environments.  Functional behavior of the iSCSI
   node MUST NOT depend on the presence, absence, or content of
   the key.  The key MUST NOT be used by iSCSI nodes for things
   such as interoperability, performance, exclusion or deception
   of other nodes, or other uses not defined here.  To enforce
   proper use, iSCSI nodes MUST NOT allow user modification of
   the key value(s), and SHOULD set the value automatically based
   on standard internal interfaces.

Original text:

   The following described Public Extension Key is sent during
   the login phase of an iSCSI normal session.  It is important
   to note that the proper use of this key is to provide enhanced
   logging and support capabilities, and for better understanding
   of customer environments.  The key MUST NOT be used by iSCSI
   nodes for things such as interoperability, performance,
   exclusion or deception of other nodes, or other uses not
   defined here.  To enforce proper use, iSCSI nodes MUST NOT
   allow user modification of the key value(s), and SHOULD set
   the value automatically based on standard internal interfaces.

>         draft-ietf-ips-iscsi-nodearch-key-00.txt
Sounds fine to me.

> could be done shortly after Montreal, if not before.
Great, thanks.