Re: DRAFT Montreal minutes - X#NodeArchitecture comments
I think the attached addresses all of the comments
below (or is pretty close). I know the format
is wrong in some cases (pages too long, etc) but I'll
fix that later. Diffing should be simpler.
Some remaining points still for discussion:
1) Still not sure about proper use / behavioral text
2) Now explicitly states the key may be sent in either
normal or discovery sessions.
Specific comments / explanations below.
Black_David@xxxxxxx wrote:
Dave,
> A couple comments a points for clarification, while this is fresh on
> everyone's minds below.
>
> > iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30
min
> > (draft-ietf-ips-iscsi-nodearch-key.txt)
> >
> > WG Discussion:
> > - Key should be allowed only after Authentication. Revise
draft
> > to impose this restriction
> >
> This is actually already in there if you read the fine print of the
"Use"
portion of
> the declaration and note that "Any-Stage" is not there (see Section
12 in
3720).
> Since it has come up repeatedly though from various people, I will add
some
> text to point this out explicitly and refer to Sections 11 and 12 of
3720.
Yes, please do that.
This has been fixed with a small change to the first
sentence of paragraph 3, section 1.2 and added a
second paragraph in section 2.
> > - Make sure it's a regular-size text key (not a big one, like
the
> > one used for the large numbers involved in some
authentication
> > methods).
> >
> Was the comment to limit the value size to 255 bytes, i.e. a single
> "text-value" (or "simple-value"), as defined by 3720, or something else?
Limiting the value size to 255 bytes was the intention.
> I liked the comma separated values and list-of-values seemed to
> fit well. But if there are concerns about key length I suppose we
> can add an explicit max length of the list-of-values. Another reviewer
> raised the question about the maximum length early on so perhaps
> an explicit limit is the way to go here.
An explicit limit is probably a good idea, as an implementation that
receives this key and doesn't recognize it may only log the first
255 bytes, so imposing that as a max limit may encourage more useful
behavior from implementations that aren't expecting the key.
Addressed in Section 2.
> > - "protocol logic": crucial point is that **behavior** is the
same
> > independent of presence, absence, or content of the
key.
Add
> > or revise text to make this point.
> >
> Was the consensus that the original term, "functional behavior",
> was clear enough, and I just muddied the water by trying to
> make it more crisp?
The "protocol logic" wording is not inherently a problem, but it is
important
that the on-the-wire "behavior" is unchanged, and "behavior" is an
important
word.
I put back the "functional behavior" term and made
my added "protocol logic" sentence parenthetical.
Please let me know if this hits the mark.
> > - Document behavior of RFC 3720-compliant implementation that
> > receives this new key and does not understand it, and
how
> > the other side deals with the resulting response.
> >
> Ok.
>
Adddressed with last paragraph added in 1.2.
The paragraph starts with a short discussion about
possible valid implementations, which complements
part of the latter security section.
> > - "configure different levels" text needs to be rephrased
to be
> > specific that the amount of detail is what changes
across levels.
> >
> I'm not sure about this comment because I thought the existing text
> does just that. Here's what the text says today:
>
> 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.
"levels of detail" seems to be less than perfectly clear. Talking
about being able to set "amount of information" provided to one of
several levels, and perhaps "verbosity" or "verbosity level" of
the key could be clearer.
I think this is clearer now. Please see paragraph
2, section 3.
> > - Align ability to configure amount of details with "SHOULD
NOT"
> > in Section 1.2 about administrative setting of key
value.
> > (the prior "SHOULD NOT" appears to conflict with this
"SHOULD").
> >
> Point taken - will work on it.
>
Also, I think addressed with slight modification to
3rd paragraph of section 1.2
> > - Double-check there is a 3720-format definition of the key,
> > including description clearly in the draft.
> >
> Was the comment that the existing declaration in section 2
> conforms to section 12 of 3720, and specifically, section
> 12.22?
If it does, I think you're done. We weren't 100% sure in the meeting.
I double checked this and I think for the most part it
is there. However, upon examination and more thinking,
I do not see or remember a reason to preclude use in
discovery sessions (again, logging may be useful), and
3270 does not seem to forbid declarative keys in discovery
sessions (are declarative keys "requests"?). Thus, I've
clarified some text to make this clear. Please let me
know if there are objections to this. If so, I will add
"Irrelevant when: SessionType=Discovery" to the key
declaration and remove the references to discovery sessions.
> > - Make the examples phony (no real company names), and remove
> > the double quotes ("), as they don't appear on the
wire.
> >
> Ok. Main intent in providing company names was to show valid
> examples for implementers but I will remove them. Note that
> RFC 2616 does have valid examples
>
> Examples:
>
> User-Agent: CERN-LineMode/2.15 libwww/2.17b3
> Server: Apache/0.8.4
The big concern was use of company names. Example, Inc. is definitely
ok, and non-offensive parodies of the company names used are probably
fair game (Dave Noveck may already be thinking up some of the latter).
Done.
> > - Spaces are forbidden in text strings. See RFC 3720, Section
5.1,
> > and feel free to ask on the list for options on how to
deal
> > with this.
> >
> Good catch - looks like I got carried away in my intent to provide
> clear examples.
Replaced all spaces with underscores.
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-01r2.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 operational parameter negotiation of an
iSCSI session's login phase. The intended use of this key is
to provide enhanced logging and support capabilities, and to
enable collection of iSCSI implementation and usage information.
Functional behavior of the iSCSI node (this includes the iSCSI
protocol logic -- the 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 contain user-defined text.
Nodes implementing this key may choose to only transmit the
key, only log the key values received from other nodes, or both
transmit and log the key values. Each node choosing to implement
transmission of the key values MUST be prepared to handle the
response of [RFC3720] compliant nodes that do not understand the
key ([RFC3720] states that compliant nodes MUST respond with
X#NodeArchitecture=NotUnderstood).
Wysochanski Expires November 4, 2006 [Page 2]
Internet-Draft iSCSI Node Architecture July 2006
2. Definition
The definition of the key is as follows, conforming to sections 11
and 12 of [RFC3720], with example list-of-values conforming to
section 5.1 of [RFC3720].
The key is defined with a Use of "LO", making it a Leading Only
key, and does not amend sections 11 or 12 of [RFC3720]. Thus, the
key MUST only be sent on the leading connection, MUST NOT be
changed after the leading connection login, and MUST only be sent
after the security negotiation login stage has completed (during
operational negotiation login stage). The key may be sent during
normal or discovery sessions.
X#NodeArchitecture
Use: LO, Declarative
Senders: Initiator and Target
Scope: SW
X#NodeArchitecture=<list-of-values>
Examples:
X#NodeArchitecture=ExampleInc_Software_Initiator/1.05a,
ExampleInc_OperatingSystem/2003Build1489,
ExampleInc_Cluster_Services/2.0,
CPU_Architecture/x86_64
X#NodeArchitecture=ExampleInc_iSCSI_4010_Hardware_Initiator/rev1,
ExampleInc_Firmware/2.0.0.5,
ExampleInc_Driver/2.0.0.1
X#NodeArchitecture=Linux_iSCSI_Software_Initiator/4:0.1.11-3,
ExampleInc_Enterprise_Linux/4u3,
Linux_Kernel/2.6.9-34.26.ELsmp,
CPU_Architecture/i686,
CPU_Speed/3.06GHz,
Memory_Size/4059364kB
X#NodeArchitecture=ExampleInc_Software_Target/7.1,
ExampleInc_Firmware/7.1,
ExampleInc_Model/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.
The length of the key value (total length of the list-of-values)
MUST NOT be greater than 255 bytes.
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 MUST provide an
administrative mechanism to disable sending the key. In addition,
all implementations SHOULD provide an administrative mechanism to
configure a verbosity level of the key value, thereby controlling
the amount of information sent. For example, a lower verbosity
might enable transmission of node architecture component names
only, but no version numbers.
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@xxxxxxxxxx
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@xxxxxxxxx
Wysochanski Expires November 4, 2006 [Page 10]
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
[IETF]
[Linux iSCSI]
[Linux SCSI]
[Linux Resources]
[Yosemite News]
[IETF Announcements]
[IETF Discussion]
[SCSI]
