Network Working Group D. Wysochanski
Request for Comments: 4850 Network Appliance, Inc.
Updates: 3720 April 2007
Category: Standards Track
Network Working Group D. Wysochanski
Request for Comments: 4850 Network Appliance, Inc.
Updates: 3720 April 2007
Category: Standards Track
Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture
用于Internet小型计算机系统接口（iSCSI）节点体系结构的声明性公共扩展密钥
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document 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. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs.
RFC 3720中描述的Internet小型计算机系统接口（iSCSI）协议允许以私有或公共扩展密钥的形式对协议进行扩展项。本文档介绍了用于增强iSCSI支持性的公共扩展密钥。密钥通过允许iSCSI节点在iSCSI登录序列期间通信体系结构详细信息来实现此目标。然后，接收节点可以使用此信息来增强日志记录和支持。本文档更新了RFC 3720，以允许由标准跟踪RFC和实验RFC以及信息RFC定义iSCSI扩展项。
This document describes a declarative Public Extension Key, as defined by Section 12.22 of RFC 3720 [2], that may be used to communicate additional iSCSI node information to the peer 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 interaction of iSCSI implementations.
本文档描述了RFC 3720[2]第12.22节定义的声明性公共扩展密钥，该密钥可用于在会话中向对等节点传递附加iSCSI节点信息。所述密钥中包含的信息在实际的iSCSI客户环境中很有价值，因为发起方和目标供应商协作解决技术问题并更好地了解iSCSI实施的交互。
The key has been modeled after the HTTP "Server" and "User-Agent" header fields as specified in Sections 14.38 and 14.43 of RFC 2616 [3], with the text-value(s) of the key roughly equivalent to Product Tokens in Section 3.8 of RFC 2616 [3]. Note, however, that the text-value(s) in the key's list-of-values MUST conform to the Text Format as specified in Section 5.1 of RFC 3720 [2].
密钥按照RFC 2616[3]第14.38节和第14.43节规定的HTTP“服务器”和“用户代理”头字段建模，密钥的文本值大致相当于RFC 2616[3]第3.8节中的产品令牌。但是，请注意，键值列表中的文本值必须符合RFC 3720[2]第5.1节规定的文本格式。
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.
密钥在iSCSI会话登录阶段的操作参数协商期间发送。此密钥的预期用途是提供增强的日志记录和支持功能，并能够收集iSCSI实施和使用信息。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The definition of the key is as follows, conforming to Sections 11 and 12 of RFC 3720 [2], with example list-of-values conforming to Section 5.1 of RFC 3720 [2].
密钥的定义如下，符合RFC 3720[2]第11节和第12节的要求，数值示例列表符合RFC 3720[2]第5.1节的要求。
The key is defined with a use of "LO", making it a Leading Only key, and does not modify Sections 11 or 12 of RFC 3720 [2]. 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.
该键定义为使用“LO”，使其成为唯一的前导键，并且不修改RFC 3720[2]的第11或12节。因此，密钥只能在主要连接上发送，在主要连接登录后不得更改，并且只能在安全协商登录阶段完成后（在操作协商登录阶段）发送。密钥可以在正常会话或发现会话期间发送。
Use: LO, Declarative Senders: Initiator and Target Scope: SW
用法：LO，声明性发送方：启动器和目标作用域：SW
X#NodeArchitecture=<list-of-values>
X#NodeArchitecture=<list-of-values>
Examples:
示例：
X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a
X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5
X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686
X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a
X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5
X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686
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.
启动器或目标向远程端点声明其iSCSI节点体系结构的详细信息。这些详细信息可能包括但不限于iSCSI供应商软件、固件或硬件版本、操作系统版本或硬件体系结构。
The length of the key value (total length of the list-of-values) MUST NOT be greater than 255 bytes.
键值的长度（值列表的总长度）不得大于255字节。
X#NodeArchitecture MUST NOT be redeclared.
X#节点体系结构不得重新声明。
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 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.
iSCSI节点的功能行为（包括iSCSI协议逻辑——SCSI、iSCSI和TCP/IP协议）不得依赖于密钥的存在、不存在或内容。iSCSI节点不得将密钥用于互操作性或排除其他节点。为确保正确使用，键值应由节点本身设置，并且不应规定键值包含用户定义的文本。
Nodes implementing this key MUST choose one of the following implementation options:
实现此键的节点必须选择以下实现选项之一：
o only transmit the key, o only log the key values received from other nodes, or o both transmit and log the key values.
o 仅传输密钥，o仅记录从其他节点接收的密钥值，或o同时传输和记录密钥值。
Each node choosing to implement transmission of the key values MUST be prepared to handle the response of RFC 3720 [2] compliant nodes that do not understand the key (RFC 3720 [2] states that compliant nodes MUST respond with X#NodeArchitecture=NotUnderstood).
选择实现密钥值传输的每个节点必须准备好处理不理解密钥的RFC 3720[2]兼容节点的响应（RFC 3720[2]声明兼容节点必须使用X#NodeArchitecture=notUnderstanding进行响应）。
Nodes that implement transmission and/or logging of the key values may also implement administrative mechanisms that disable and/or
实现键值传输和/或记录的节点还可以实现禁用和/或记录的管理机制
change the logging and key transmission detail (see Security Considerations). Thus, a valid behavior for this key may be that a node is completely silent (the node does not transmit any key value, and simply discards any key values it receives without issuing a NotUnderstood response).
更改日志记录和密钥传输详细信息（请参阅安全注意事项）。因此，该密钥的有效行为可能是节点完全静默（该节点不发送任何键值，并且简单地丢弃它接收的任何键值，而不发出NotUnderstanding响应）。
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:
该扩展键传输发送它的节点的具体实现细节；在某些环境中，这些细节可能被认为是敏感的。例如，如果已知某个软件或固件版本存在安全漏洞，则可能不希望通过此密钥宣布该版本的存在。针对这一安全问题的对策是：
o sending less detailed information in the key values,
o 在键值中发送不太详细的信息，
o not sending the extension key, or
o 未发送扩展密钥，或
o using IPsec to provide confidentiality for the iSCSI connection on which the key is sent (see RFC 3720 [2] and RFC 3723 [4]).
o 使用IPsec为发送密钥的iSCSI连接提供机密性（请参阅RFC 3720[2]和RFC 3723[4]）。
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, sending less detailed information in the key values may be an acceptable countermeasure 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.
选择哪种对策最合适取决于环境。然而，在许多环境中，发送密钥值中不太详细的信息可能是一种可接受的对策，因为它在发送太多信息和根本不发送密钥或使用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:
除了涉及密钥内容传输的安全注意事项外，用于密钥值的任何日志记录方法都必须确保信息的安全，以防入侵者。对于所有实现，解决此安全问题的要求如下：
o Display of the log MUST only be possible with administrative rights to the node.
o 只有对节点具有管理权限时才能显示日志。
o Options to disable logging to disk and to keep logs for a fixed duration SHOULD be provided.
o 应提供禁用磁盘日志记录和将日志保留固定时间的选项。
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:
最后，需要注意的是，不同的节点可能具有不同的风险级别，这些差异可能会影响实现。风险的组成部分包括资产、威胁和漏洞。考虑下面的示例iSCSI节点，它演示了节点的资产和漏洞的差异，因此，实现中的差异：
o 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.
o 一个基于专用操作系统的iSCSI目标。由于iSCSI目标控制对包含公司资产的数据存储的访问，因此资产级别被视为非常高。此外，由于专用操作系统的漏洞不太为人所知，因此漏洞级别被视为较低。
o 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.
o 刀片服务器场中有多个iSCSI启动器，每个启动器运行一个通用操作系统。每个节点的资产级别被视为较低，因为刀片是可更换的且成本较低。但是，由于通用操作系统存在许多众所周知的漏洞，因此漏洞级别被视为很高。
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.
对于上述目标，适当的实现可能是记录接收到的键值，但不传输键值。对于启动器，适当的实现可能是传输密钥，但不记录接收到的密钥值。
The standards action of this document updates RFC 3720 to allow any iSCSI extension item, specifically X# extension text keys, Y# digest algorithms, and Z# authentication methods, to be defined by a standards track, experimental, or informational RFC. This document is a standards track RFC that defines an X# extension text key.
本文档的标准操作更新了RFC 3720，以允许任何iSCSI扩展项，特别是X扩展文本键、Y摘要算法和Z验证方法，由标准跟踪、实验或信息RFC定义。本文档是一个标准跟踪RFC，它定义了一个X扩展文本键。
IANA registered this key as follows:
IANA按如下方式注册了此密钥：
o Key Name: X#NodeArchitecture
o 关键字名称：X#节点体系结构
o Description: Node architecture details
o 描述：节点架构详细信息
o Reference: [RFC4850]
o 参考文献：[RFC4850]
The update to RFC 3720 to allow additional types of RFCs for iSCSI Extension items has the same effect as if the following changes were made to the text of RFC 3720 (RFC text cannot be changed after publication):
对RFC 3720进行更新以允许iSCSI扩展项使用其他类型的RFC，其效果与对RFC 3720的文本进行以下更改时相同（发布后无法更改RFC文本）：
1) In Section 11.1, the requirement that Z# Authentication methods "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
1) 在第11.1节中，Z#认证方法“必须由信息RFC描述”的要求更改为“必须由标准跟踪RFC、实验RFC或信息RFC描述”
2) In Section 12.1, the requirement that Y# Digest algorithms "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
2) 在第12.1节中，Y#摘要算法“必须由信息RFC描述”的要求更改为“必须由标准轨道RFC、实验RFC或信息RFC描述”
3) In Section 12.22, the requirement that X# text keys "MUST be described by an informational RFC." is changed to "MUST be described by a standards track RFC, an experimental RFC, or an informational RFC."
3) 在第12.22节中，X#文本键“必须由信息RFC描述”的要求更改为“必须由标准轨道RFC、实验RFC或信息RFC描述”
4) In Section 13.3, the description of allowed RFC types for extension items is changed from "The RFC may be informational rather than Standards-Track," to "The RFC MUST be standards track, experimental, or informational,"
4) 在第13.3节中，扩展项目允许的RFC类型的描述从“RFC可能是信息性的，而不是标准轨道”更改为“RFC必须是标准轨道、实验性的或信息性的”
5) In Section 13.5.2, the phrase "standards track" is changed to "standards track or experimental" in the last sentence of the first paragraph, so that the sentence reads: "If the specification is a standards track or experimental document, the usual IETF procedures for such documents are followed."
5) 在第13.5.2节中，第一段最后一句中的短语“标准跟踪”改为“标准跟踪或实验性”，因此该句为：“如果规范是标准跟踪或实验性文件，则遵循此类文件的通常IETF程序。”
The registries for iSCSI extension items should be managed as if these changes had been made to the text of RFC 3720.
iSCSI扩展项的注册表应该像对RFC 3720的文本进行了这些更改一样进行管理。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[2] Satran，J.，Meth，K.，Sapuntzakis，C.，Chadalapaka，M.，和E.Zeidner，“互联网小型计算机系统接口（iSCSI）”，RFC 3720，2004年4月。
[3] 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.
[3] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[4] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[4] Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.，和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年4月。
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 author acknowledges the contributions of the entire working group.
IETF传输领域的IP存储（ips）工作组负责定义iSCSI协议（除一系列其他相关IP存储协议外）。提交人感谢整个工作组的贡献。
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, Jim Yuill, William Studenmund, and Ken Sandars. This document benefited from all these contributions.
以下个人直接参与了确定问题和/或建议解决本文件中发现的问题：大卫·布莱克、马利卡琼·查达拉帕卡、保罗·科宁、朱利安·萨特兰、约翰·赫弗德、克莱尔·卡夫、兰加·桑卡尔、约瑟夫·皮特曼、格雷格·伯格、约翰·福特、吉姆·尤伊尔、威廉·斯图登蒙德和肯·桑德斯。这份文件得益于所有这些贡献。
Finally, the author recognizes Network Appliance, Inc. for sponsorship and support during the development of this work.
最后，作者感谢Network Appliance，Inc.在这项工作的开发过程中提供的赞助和支持。
Author's Address
作者地址
Dave Wysochanski 8311 Brier Creek Parkway Suite 105-296 Raleigh, NC 27617 US
Dave Wysochanski 8311 Brier Creek Parkway套房105-296美国北卡罗来纳州罗利市27617
Phone: +1 919 696 8130
EMail: wysochanski@pobox.com
Phone: +1 919 696 8130
EMail: wysochanski@pobox.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。