Re: DRAFT Montreal minutes - X#NodeArchitecture comments

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:
> 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.
> 
> 
> [email protected] wrote:
>  > 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.
>  >
> 
> 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.
> 
> 
>  >  > >         - 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.
>  >
> 
> Addressed in Section 2.
> 
> 
>  >  > >         - "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.
>  >
> 
> I put back the "functional behavior" term and made
> my added "protocol logic" sentence parenthetical.
> Please let me know if this hits the mark.
> 
> 
>  >  > >         - 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.
>  >  >
> 
> 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.
> 
> 
>  >  > >         - "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.
>  >
> 
> I think this is clearer now.  Please see paragraph
> 2, section 3.
> 
> 
>  >  > >         - 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.
>  >  >
> 
> Also, I think addressed with slight modification to
> 3rd paragraph of section 1.2
> 
> 
>  >  > >         - 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.
>  >
> 
> 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.
> 
> 
>  >  > >         - 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).
>  >
> 
> Done.
> 
> 
>  >  > >         - 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.
>  >
> 
> 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 protected]
>            
>       
> 
> 
> 
> 
> 
>  
>  
> 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 protected].  
> 
>   
> 
> 
> 
> 
> 
>  
>  
> Wysochanski              Expires November 4, 2006          [Page 10] 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips

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