Subject: [Ips] Proposed Declarative Public Extension Key - X#NodeArchitecture

From: David Wysochanski <[email-masked]>
Date: Fri, 11 Mar 2005 15:58:57 -0500

Declarative Public Extension Key to Enhance iSCSI Supportability

This proposal identifies a declarative Public Extension Key as defined by
section 12.22 of RFC 3720 that may be used to communicate additional iSCSI
node information to the opposite node in a session.  The information carried
in the proposed key has been found to be valuable in real iSCSI customer 
environments as initiator and target vendors collaborate to resolve technical
issues and better understand the evolving iSCSI market.

The following proposed Public Extension Key is sent during the login phase
of an iSCSI normal session.  It is important to note that the intent of
providing this key is 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
by this proposal.  To enforce proper use, iSCSI nodes MUST NOT allow user
modification of the key value(s), but MUST set the value automatically based
on standard internal interfaces.

In certain environments where security is a primary concern, the use of this
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.

The definition of the proposed key is as follows, with example text-values
conforming to section 5.1 of RFC 3720.

X#NodeArchitecture

   Use: LO, Declarative
   Senders: Initiator and Target
   Scope: SW

   X#NodeArchitecture=<list-of-values>

   Examples:

      X#NodeArchitecture="os-v1.2.3.4,iscsi-vendor-software-v1.2.3.4"
      X#NodeArchitecture="os-v1.2.3.4,cpu-type-x,cpu-speed-2.0ghz,
                          iscsi-vendor-hardware-v1.2.3.4,
                          iscsi-vendor-firmware-v1.2.3.4"

   The initiator or target declares the details of its iSCSI node architecture
   to the remote endpoint.  These details may include, but are not limited to,
   the OS version, CPU or hardware architecture, iSCSI vendor software and/or 
   firmware version, iSCSI vendor hardware revision, and so on.

   NodeArchitecture MUST NOT be redeclared.

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

---

From: Paul Koning <[email-masked]>
Date: Sat, 12 Mar 2005 10:52:48 -0500

David,

A couple of questions on your proposal.

Are there cases where it makes sense to have this key be
per-connection rather than per-session?  

Should it be legal prior to the conclusion of the security negotiation
stage?  I think yes, because it is defined to have no effect on any
actions or negotiations.  It is helpful to identify what is at the
other end, and that information is potentially useful when
troubleshooting security negotiation failures.

The values are, I believe, free form (within the constraints of
"text-value") which means that they are only ever going to be
intellegible to people, not to algorithms.  That's fine given the
stated intended usage.  It also means that there is a possibility of
ambiguity; two implementations might pick the same value string to
represent different things.

	  paul

---

From: Dave Wysochanski <[email-masked]>
Date: Sat, 12 Mar 2005 13:49:50 -0500

> per-connection rather than per-session? 
Perhaps.  I couldn't really come up with likely scenarios,
although perhaps others can.  It's certainly reasonable
to expand the scope in this way if there are likely
scenarios.  I will think about this some more.

> troubleshooting security negotiation failures.
I definately agree.  I originally had a more broad Use,
but then pared it down (too much it seems). This would
make the use statement: IO, Declarative, Any-Stage. 

> represent different things.
The intent was free-form, yes.  I would imagine various
implementations would stick with the same general
strings, and as the proposal states, internal interfaces
should be used to identify various components.  So
I didn't view the possibility of ambiguity as something
warranting locking down the text-values to a specific
format.