Subject: [Ips] Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt

From: David Wysochanski <[email-masked]>
Date: Fri, 07 Jul 2006 14:42:37 -0400

Attached is an updated version of draft-ietf-ips-iscsi-nodearch-key which
addresses all of the remaining items on my list.  Comments welcome.
Note that I will not be attending the Montreal meeting.  However, my
colleage, Tom Talpey should be in attendance.

Significant changes are:

1. p. 2. Updated usage paragraph.  This seemed a little vague, so I tried
to make it more specific and focus on prevention of the previous problem
with JavaScript.  I also loosened the requirement for setting the key
value automatically to a SHOULD instead of a MUST (based on another reviewer
comment).

2.  p. 4. Security updates related to logging and different levels of
risk for nodes.  These ideas came from a computer security reviewer,
and I believe address important issues.

List of all changes (verified via RFC diff tool below)
draft-ietf-ips-iscsi-nodearch-key-00.txt
draft-ietf-ips-iscsi-nodearch-key-01r1.txt
- p. 2: Modified proper use paragraph
- p. 3: fix typeo
- p. 4: fix typeo
- p. 4: added paragraphs 3-5
- p. 8: added another contributor

http://www1.tools.ietf.org/tools/rfcdiff/rfcdiff.pyht

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-00.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 the login phase of an iSCSI normal session.
   The intended use of this key is to provide enhanced logging and
   support capabilities, and to enable collection of iSCSI
   implementation and usage information.  The protocol logic of the
   iSCSI stack (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 be modified by end users or
   system administrators.

Wysochanski              Expires November 4, 2006          [Page  2] 


Internet-Draft        iSCSI Node Architecture              July 2006

2.  Definition

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

X#NodeArchitecture

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

   X#NodeArchitecture=<list-of-values>

   Examples:

      X#NodeArchitecture="Microsoft Software Initiator/1.05a,
                          Microsoft Windows/2003Build1489,
                          Microsoft Cluster Services/2.0,
                          CPU Architecture/x86_64"
      X#NodeArchitecture="Qlogic iSCSI 4010 Hardware Initiator/rev1,
                          Qlogic Firmware/2.0.0.5,
                          Qlogic Driver/2.0.0.1"
      X#NodeArchitecture="Linux iSCSI Software Initiator/4:0.1.11-3,
                          Red Hat Enterprise Linux/4u3,
                          Linux Kernel/2.6.9-34.26.ELsmp,
                          CPU Architecture/i686,
                          CPU Speed/3.06GHz,
                          Memory Size/4059364kB"
      X#NodeArchitecture="NetApp Software Target/7.1,
                          Data ONTAP/7.1,
                          NetApp FAS/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.

   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 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.

    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] 

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

---

From: [email-masked]
Date: Wed, 12 Jul 2006 10:19:03 -0400

Quick note: -00 is what's currently on the Internet-Draft servers, so
the final form of this -01 is headed for submission after the Montreal
meetings.  In the meeting, I intend to project at least what I consider
the crucial paragraphs for detailed editing/wordsmithing:
- Last paragraph of Section 1.2, forbidding behavioral dependencies
- First paragraph of the security section on what to do if there's
	a need to keep implementation details secret.
Dave W took the latter paragraph directly from an email I sent, so
blame me rather than him for any problems with that text.

The -01 version of this draft is probably headed for WG Last Call
within the next few weeks.

Thanks,
--David

> -----Original Message-----
> From: David Wysochanski [mailto:[email-masked]] 
> Sent: Friday, July 07, 2006 2:43 PM
> To: [email-masked]
> Subject: [Ips] Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt
>

---

From: David Wysochanski <[email-masked]>
Date: Wed, 12 Jul 2006 11:57:03 -0400

Thanks.  I will await the outcome of the meeting and
be ready to respond to any edits in a timely manner.