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               May 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 following described Public Extension Key is sent during
   the login phase of an iSCSI normal session.  It is important
   to note that the intended use of this key is to provide enhanced
   logging and support capabilities, and to enable collection of
   iSCSI implementation usage information.  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, or exclusion or
   deception of other nodes.  To enforce intended use, iSCSI nodes
   MUST NOT allow user modification of the key value(s), and SHOULD
   set the value automatically based on standard internal
   interfaces.


Wysochanski              Expires November 4, 2006          [Page  2]



Internet-Draft        iSCSI Node Architecture               May 2006

2.  Definition

   The definition of extension 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               May 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 second 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.



Wysochanski              Expires November 4, 2006          [Page  4]



Internet-Draft        iSCSI Node Architecture               May 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               May 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               May 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: davidw@netapp.com









Wysochanski              Expires November 4, 2006          [Page  7]



Internet-Draft        iSCSI Node Architecture               May 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, and John Forte. This document benefited
   from all these contributions.









Wysochanski              Expires November 4, 2006          [Page  8]



Internet-Draft        iSCSI Node Architecture               May 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               May 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 ietf-ipr@ietf.org.









Wysochanski              Expires November 4, 2006          [Page 10]