Updates to draft-ietf-ips-iscsi-nodearch-key-00.txt
David Wysochanski <davidw <at> netapp.com>
2006-07-07 18:42:37 GMT
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: davidw <at> netapp.com
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 ietf-ipr <at> ietf.org.
Wysochanski Expires November 4, 2006 [Page 10]
_______________________________________________
Ips mailing list
Ips <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ips
RSS Feed