One document matched: draft-ietf-ips-iscsi-nodearch-key-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-19 20:24:16 |