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= 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]