Subject: RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments

From: [email-masked]
Date: Thu, 13 Jul 2006 11:33:51 -0400

Dave,

> A couple comments a points for clarification, while this is fresh on
> everyone's minds below.
> 
> > iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30
min
> >         (draft-ietf-ips-iscsi-nodearch-key.txt)
> >
> >         WG Discussion:
> >         - Key should be allowed only after Authentication.  Revise draft
> >                 to impose this restriction
> >
> This is actually already in there if you read the fine print of the "Use"
portion of
> the declaration and note that "Any-Stage" is not there (see Section 12 in
3720).
> Since it has come up repeatedly though from various people, I will add
some
> text to point this out explicitly and refer to Sections 11 and 12 of 3720.

Yes, please do that.

> >         - Make sure it's a regular-size text key (not a big one, like
the
> >                 one used for the large numbers involved in some
authentication
> >                 methods).
> >
> Was the comment to limit the value size to 255 bytes, i.e. a single
> "text-value" (or "simple-value"), as defined by 3720, or something else?

Limiting the value size to 255 bytes was the intention.

> I liked the comma separated values and list-of-values seemed to
> fit well.  But if there are concerns about key length I suppose we
> can add an explicit max length of the list-of-values.  Another reviewer
> raised the question about the maximum length early on so perhaps
> an explicit limit is the way to go here.

An explicit limit is probably a good idea, as an implementation that
receives this key and doesn't recognize it may only log the first
255 bytes, so imposing that as a max limit may encourage more useful
behavior from implementations that aren't expecting the key.

> >         - "protocol logic": crucial point is that **behavior** is the
same
> >                 independent of presence, absence, or content of the key.
Add
> >                 or revise text to make this point.
> >
> Was the consensus that the original term, "functional behavior",
> was clear enough, and I just muddied the water by trying to
> make it more crisp?

The "protocol logic" wording is not inherently a problem, but it is
important
that the on-the-wire "behavior" is unchanged, and "behavior" is an important
word.

> >         - Document behavior of RFC 3720-compliant implementation that
> >                 receives this new key and does not understand it, and
how
> >                 the other side deals with the resulting response.
> >
> Ok.
> 
> >         - "configure different levels" text needs to be rephrased to be
> >                 specific that the amount of detail is what changes
across levels.
> >
> I'm not sure about this comment because I thought the existing text
> does just that.  Here's what the text says today:
> 
>     all
>     implementations of this extension key SHOULD provide an 
>     administrative mechanism to configure different levels of
>     detail in the extension key values and MUST provide an
>     administrative mechanism to disable sending the key.

"levels of detail" seems to be less than perfectly clear.  Talking
about being able to set "amount of information" provided to one of
several levels, and perhaps "verbosity" or "verbosity level" of
the key could be clearer.

> >         - Align ability to configure amount of details with "SHOULD NOT"
> >                 in Section 1.2 about administrative setting of key
value.
> >                 (the prior "SHOULD NOT" appears to conflict with this
"SHOULD").
> >
> Point taken - will work on it.
> 
> >         - Double-check there is a 3720-format definition of the key,
> >                 including description clearly in the draft. 
> >
> Was the comment that the existing declaration in section 2
> conforms to section 12 of 3720, and specifically, section
> 12.22?

If it does, I think you're done.  We weren't 100% sure in the meeting.

> >         - Make the examples phony (no real company names), and remove
> >                 the double quotes ("), as they don't appear on the wire.
> >
> Ok.  Main intent in providing company names was to show valid
> examples for implementers but I will remove them.  Note that
> RFC 2616 does have valid examples
> 
>    Examples:
> 
>        User-Agent: CERN-LineMode/2.15 libwww/2.17b3
>        Server: Apache/0.8.4

The big concern was use of company names.  Example, Inc. is definitely
ok, and non-offensive parodies of the company names used are probably
fair game (Dave Noveck may already be thinking up some of the latter).

> >         - Spaces are forbidden in text strings.  See RFC 3720, Section
5.1,
> >                 and feel free to ask on the list for options on how to
deal
> >                 with this.
> >
> Good catch - looks like I got carried away in my intent to provide
> clear examples.

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: David Wysochanski <[email-masked]>
Date: Thu, 13 Jul 2006 18:34:03 -0400

I think the attached addresses all of the comments
below (or is pretty close).  I know the format
is wrong in some cases (pages too long, etc) but I'll
fix that later.  Diffing should be simpler.

Some remaining points still for discussion:
1) Still not sure about proper use / behavioral text
2) Now explicitly states the key may be sent in either
normal or discovery sessions.

Specific comments / explanations below.

>  > text to point this out explicitly and refer to Sections 11 and 12 of 

This has been fixed with a small change to the first
sentence of paragraph 3, section 1.2 and added a
second paragraph in section 2.

> behavior from implementations that aren't expecting the key.

Addressed in Section 2.

> that the on-the-wire "behavior" is unchanged, and "behavior" is an 

I put back the "functional behavior" term and made
my added "protocol logic" sentence parenthetical.
Please let me know if this hits the mark.

>  > >                 the other side deals with the resulting response.

Adddressed with last paragraph added in 1.2.
The paragraph starts with a short discussion about
possible valid implementations, which complements
part of the latter security section.

> the key could be clearer.

I think this is clearer now.  Please see paragraph
2, section 3.

>  > Point taken - will work on it.

Also, I think addressed with slight modification to
3rd paragraph of section 1.2

> If it does, I think you're done.  We weren't 100% sure in the meeting.

I double checked this and I think for the most part it
is there.  However, upon examination and more thinking,
I do not see or remember a reason to preclude use in
discovery sessions (again, logging may be useful), and
3270 does not seem to forbid declarative keys in discovery
sessions (are declarative keys "requests"?).  Thus, I've
clarified some text to make this clear.  Please let me
know if there are objections to this.  If so, I will add
"Irrelevant when: SessionType=Discovery" to the key
declaration and remove the references to discovery sessions.

> fair game (Dave Noveck may already be thinking up some of the latter).

Done.

>  > Good catch - looks like I got carried away in my intent to provide

Replaced all spaces with underscores.

INTERNET-DRAFT                                       Dave Wysochanski
Expires: November 4, 2006                      Network Appliance, Inc
                                                          May 4, 2006

      Declarative Public Extension Key for iSCSI Node Architecture
               draft-ietf-ips-iscsi-nodearch-key-01r2.txt

Status of this Memo 

   By submitting this Internet-Draft, each author represents 
   that any applicable patent or other IPR claims of which he or 
   she is aware have been or will be disclosed, and any of which 
   he or she becomes aware will be disclosed, in accordance with 
   Section 6 of BCP 79. 

   Internet-Drafts are working documents of the Internet 
   Engineering Task Force (IETF), its areas, and its working 
   groups.  Note that other groups may also distribute working 
   documents as Internet-Drafts. 

   Internet-Drafts are draft documents valid for a maximum of 
   six months and may be updated, replaced, or obsoleted by 
   other documents at any time.  It is inappropriate to use 
   Internet-Drafts as reference material or to cite them other 
   than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/1id-abstracts.html 

   The list of Internet-Draft Shadow Directories can be accessed 
   at http://www.ietf.org/shadow.html.  

   This Internet-Draft will expire on November 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The iSCSI protocol, described in [RFC3720], allows for extension
   items to the protocol in the form of Private or Public Extension
   Keys.  This Internet-Draft describes a Public Extension Key for
   the purpose of enhancing iSCSI supportability.  The key
   accomplishes this objective by allowing iSCSI nodes to
   communicate architecture details during the iSCSI login
   sequence.  The receiving node can then use this information
   for enhanced logging and support.

Wysochanski              Expires November 4, 2006          [Page  1] 


Internet-Draft        iSCSI Node Architecture              July 2006

1.  Introduction

1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119].

1.2  Overview

   This Internet-Draft describes a declarative Public Extension
   Key as defined by section 12.22 of [RFC3720] that may be used to
   communicate additional iSCSI node information to the opposite
   node in a session.  The information carried in the described
   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 key has been modeled after the "Server" and "User-Agent"
   header fields as specified in sections 14.38 and 14.43 of
   [RFC2616], with the text-value(s) of the key roughly equivalent
   to Product Tokens in section 3.8 of [RFC2616].  Note however
   that the text-value(s) in the keys list-of-values MUST conform
   to the Text Format as specified in section 5.1 of [RFC3720].

   The key is sent during operational parameter negotiation of an
   iSCSI session's login phase.  The intended use of this key is
   to provide enhanced logging and support capabilities, and to
   enable collection of iSCSI implementation and usage information.
   Functional behavior of the iSCSI node (this includes the iSCSI
   protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT
   depend on the presence, absence, or content of the key.  The key
   MUST NOT be used by iSCSI nodes for interoperability, or exclusion
   or deception of other nodes.  To ensure proper use, key values
   SHOULD be set by the node itself, and there SHOULD NOT be
   provisions for the key values to contain user-defined text.

   Nodes implementing this key may choose to only transmit the
   key, only log the key values received from other nodes, or both
   transmit and log the key values.  Each node choosing to implement
   transmission of the key values MUST be prepared to handle the 
   response of [RFC3720] compliant nodes that do not understand the
   key ([RFC3720] states that compliant nodes MUST respond with
   X#NodeArchitecture=NotUnderstood).

Wysochanski              Expires November 4, 2006          [Page  2] 


Internet-Draft        iSCSI Node Architecture              July 2006

2.  Definition

   The definition of the key is as follows, conforming to sections 11
   and 12 of [RFC3720], with example list-of-values conforming to
   section 5.1 of [RFC3720].

   The key is defined with a Use of "LO", making it a Leading Only
   key, and does not amend sections 11 or 12 of [RFC3720].  Thus, the
   key MUST only be sent on the leading connection, MUST NOT be
   changed after the leading connection login, and MUST only be sent
   after the security negotiation login stage has completed (during 
   operational negotiation login stage).  The key may be sent during
   normal or discovery sessions.

X#NodeArchitecture

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

   X#NodeArchitecture=<list-of-values>

   Examples:

      X#NodeArchitecture=ExampleInc_Software_Initiator/1.05a,
                         ExampleInc_OperatingSystem/2003Build1489,
                         ExampleInc_Cluster_Services/2.0,
                         CPU_Architecture/x86_64
      X#NodeArchitecture=ExampleInc_iSCSI_4010_Hardware_Initiator/rev1,
                         ExampleInc_Firmware/2.0.0.5,
                         ExampleInc_Driver/2.0.0.1
      X#NodeArchitecture=Linux_iSCSI_Software_Initiator/4:0.1.11-3,
                         ExampleInc_Enterprise_Linux/4u3,
                         Linux_Kernel/2.6.9-34.26.ELsmp,
                         CPU_Architecture/i686,
                         CPU_Speed/3.06GHz,
                         Memory_Size/4059364kB
      X#NodeArchitecture=ExampleInc_Software_Target/7.1,
                         ExampleInc_Firmware/7.1,
                         ExampleInc_Model/270c

   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, iSCSI vendor software, firmware, or
   hardware versions, the OS version, or hardware architecture.

   The length of the key value (total length of the list-of-values)
   MUST NOT be greater than 255 bytes.

   X#NodeArchitecture MUST NOT be redeclared.

Wysochanski              Expires November 4, 2006          [Page  3] 


Internet-Draft        iSCSI Node Architecture              July 2006
 
3.  Security Considerations 

    This extension key transmits specific implementation details
    about the node that sends it; such details may be considered
    sensitive in some environments.  For example, if a certain
    software or firmware version is known to contain security
    weaknesses, announcing the presence of that version via this
    key may not be desirable.  The countermeasures for this
    security concern are:
        - sending less detailed information in the key values, or
        - not sending the extension key, or
        - using IPsec to provide confidentiality for the iSCSI
          connection on which the key is sent (see [RFC3720]
          and [RFC3723]).
    To support the first and second countermeasures, all 
    implementations of this extension key MUST provide an 
    administrative mechanism to disable sending the key.  In addition,
    all implementations SHOULD provide an administrative mechanism to
    configure a verbosity level of the key value, thereby controlling
    the amount of information sent.  For example, a lower verbosity
    might enable transmission of node architecture component names
    only, but no version numbers.

    The choice of which countermeasure is most appropriate depends
    on the environment.  However, the first countermeasure may be
    acceptable in many environments, since it provides a compromise
    between sending too much information and the other more
    complete countermeasures of not sending the key at all or using
    IPsec.

    In addition to security considerations involving transmission of
    the key contents, any logging method(s) used for the key values
    MUST keep the information secure from intruders.  For all
    implementations, the requirements to address this security
    concern are:
	- display of the log MUST only be possible with administrative
	rights to the node
	- options to disable logging to disk and to keep logs for a
	fixed duration SHOULD be provided

    Finally, it is important to note that different nodes may have
    different levels of risk, and these differences may affect the
    implementation.  The components of risk include assets, threats,
    and vulnerabilities.  Consider the following example iSCSI nodes,
    which demonstrate differences in assets and vulnerabilities of
    the nodes, and as a result, differences in implementation:
        - One iSCSI target based on a special-purpose operating
	system.  Since the iSCSI target controls access to the data
	storage containing company assets, the asset level is seen
	as very high.  Also, because of the special-purpose 
	operating system, in which vulnerabilities are less 
	well-known, the vulnerability level is viewed as low.
	- Multiple iSCSI initiators in a blade farm, each running
	a general-purpose operating system.  The asset level of
	each node is viewed as low, since blades are replaceable
	and low cost.  However, the vulnerability level is viewed
	as high, since there are many well-known vulnerabilities
	to the general-purpose operating system.

    For the above target, an appropriate implementation might be
    logging of received key values, but no transmission of the key.
    For the initiators, an appropriate implementation might be
    transmission of the key, but no logging of received key values.  

Wysochanski              Expires November 4, 2006          [Page  4] 


Internet-Draft        iSCSI Node Architecture              July 2006
 
4.  IANA Considerations 

   This document defines the iSCSI Extension Key NodeArchitecture 
   to be registered in the IANA iSCSI extended key registry.

 
Wysochanski              Expires November 4, 2006          [Page  5] 


Internet-Draft        iSCSI Node Architecture              July 2006
 
5.  References

5.1  Normative References 

   [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997.  

   [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 
             M., and E. Zeidner, "Internet Small Computer Systems 
             Interface (iSCSI)", RFC 3720, April 2004. 

5.2  Informative References 

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
             Masinter, L., Leach, P., and T. Berners-Lee, 
             "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
             June 1999.

   [RFC3723] Adoba, B., Tseng, J., Walker, J., Rangan, V., and
             Travostino, F., "Securing Block Storage Protocols
             over IP", RFC 3723, April 2004.

 
 
Wysochanski              Expires November 4, 2006          [Page  6] 


Internet-Draft        iSCSI Node Architecture              July 2006
 
6.  Author's Address 

   Dave Wysochanski
   Network Appliance, Inc.
   7301 Kit Creek Road
   P. O. Box 13917
   Research Triangle, NC 27709
   Phone: +1-919-476-5628
   E-mail: [email-masked]

 
Wysochanski              Expires November 4, 2006          [Page  7] 


Internet-Draft        iSCSI Node Architecture              July 2006
 
7.  Acknowledgements 

   The IP Storage (ips) Working Group in the Transport Area of 
   IETF has been responsible for defining the iSCSI protocol 
   (apart from a host of other relevant IP Storage protocols).  
   The editor acknowledges the contributions of the entire 
   working group.   

   The following individuals directly contributed to identifying 
   issues and/or suggesting resolutions to the issues found in this
   document: David Black, Mallikarjun Chadalapaka, Paul Koning,
   Julian Satran, John Hufferd, Claire Kraft, Ranga Sankar,
   Joseph Pittman, Greg Berg, John Forte, and Jim Yuill. This
   document benefited from all these contributions. 

 
Wysochanski              Expires November 4, 2006          [Page  8] 


Internet-Draft        iSCSI Node Architecture              July 2006
 
8.  Full Copyright Statement 

   Copyright (C) The Internet Society (2006).  This document is 
   subject to the rights, licenses and restrictions contained in 
   BCP 78, and except as set forth therein, the authors retain 
   all their rights.  

   This document and the information contained herein are 
   provided on an "AS IS" basis and THE CONTRIBUTOR, THE 
   ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 
   THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 
   DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 
   OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

 
Wysochanski              Expires November 4, 2006          [Page  9] 


Internet-Draft        iSCSI Node Architecture              July 2006
 
9.  Intellectual Property Statement  

   The IETF takes no position regarding the validity or scope of    
   any Intellectual Property Rights or other rights that might 
   be claimed to pertain to the implementation or use of the 
   technology described in this document or the extent to which 
   any license under such rights might or might not be 
   available; nor does it represent that it has made any 
   independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can 
   be found in BCP 78 and BCP 79.  

   Copies of IPR disclosures made to the IETF Secretariat and 
   any assurances of licenses to be made available, or the 
   result of an attempt made to obtain a general license or 
   permission for the use of such proprietary rights by 
   implementers or users of this specification can be obtained 
   from the IETF on-line IPR repository at http://www.ietf.org/ipr.  

   The IETF invites any interested party to bring to its 
   attention any copyrights, patents or patent applications, 
   or other proprietary rights that may cover technology that 
   may be required to implement this standard.  Please address 
   the information to the IETF at [email-masked].  

 
Wysochanski              Expires November 4, 2006          [Page 10]

---

From: David Wysochanski <[email-masked]>
Date: Mon, 31 Jul 2006 17:36:26 -0400

Ping on the 2 items below - any comments?

Also adding a 3rd item:
3) Change key value format from list-of-values to
"iSCSI-name-value" (see 7/13/06 post).

For this one, I'd rather leave it as list-of-values, since
this is simple, underscores are just about as readable as
spaces, and iSCSI-name-value seems a little strange
to me in this context.

Wysochanski, David wrote:
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: William Studenmund <[email-masked]>
Date: Mon, 31 Jul 2006 15:26:17 -0700

> spaces, and iSCSI-name-value seems a little strange

Actually, how about "iSCSI-local-name-value".

The thing I don't like about list-of-values is that it implies, to me  
at least, list negotiations. Which we don't want here. :-) Also, list- 
of-values just vies us "text-value" plus comma. Among other things,  
we don't have spaces, nor do we have CR.

Take care,

Bill