idnits 2.17.1 draft-ietf-ips-iscsi-nodearch-key-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 334. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3720, updated by this document, for RFC5378 checks: 2000-11-06) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 2006) is 6356 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3720 (ref. '2') (Obsoleted by RFC 7143) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '3') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Storage Working Group D. Wysochanski 3 Internet-Draft November 21, 2006 4 Updates: 3720 (if approved) 5 Intended status: Standards Track 6 Expires: May 25, 2007 8 Declarative Public Extension Key for iSCSI Node Architecture 9 draft-ietf-ips-iscsi-nodearch-key-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 25, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The iSCSI protocol, described in RFC 3720 [2], allows for extension 43 items to the protocol in the form of Private or Public Extension 44 Keys. This Internet-Draft describes a Public Extension Key for the 45 purpose of enhancing iSCSI supportability. The key accomplishes this 46 objective by allowing iSCSI nodes to communicate architecture details 47 during the iSCSI login sequence. The receiving node can then use 48 this information for enhanced logging and support. This document 49 updates RFC 3720 to allow iSCSI extension items to be defined by 50 standards track RFCs and experimental RFCs in addition to 51 informational RFCs. 53 1. Introduction 55 1.1. Terminology 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in RFC 2119 [1]. 61 1.2. Overview 63 This Internet-Draft describes a declarative Public Extension Key as 64 defined by section 12.22 of RFC 3720 [2] that may be used to 65 communicate additional iSCSI node information to the peer node in a 66 session. The information carried in the described key has been found 67 to be valuable in real iSCSI customer environments as initiator and 68 target vendors collaborate to resolve technical issues and better 69 understand the interaction of iSCSI implementations. 71 The key has been modeled after the HTTP "Server" and "User-Agent" 72 header fields as specified in sections 14.38 and 14.43 of RFC 2616 73 [3], with the text-value(s) of the key roughly equivalent to Product 74 Tokens in section 3.8 of RFC 2616 [3]. Note however that the text- 75 value(s) in the key's list-of-values MUST conform to the Text Format 76 as specified in section 5.1 of RFC 3720 [2]. 78 The key is sent during operational parameter negotiation of an iSCSI 79 session's login phase. The intended use of this key is to provide 80 enhanced logging and support capabilities, and to enable collection 81 of iSCSI implementation and usage information. 83 2. Definition 85 The definition of the key is as follows, conforming to sections 11 86 and 12 of RFC 3720 [2], with example list-of-values conforming to 87 section 5.1 of RFC 3720 [2]. 89 The key is defined with a Use of "LO", making it a Leading Only key, 90 and does not modify sections 11 or 12 of RFC 3720 [2]. Thus, the key 91 MUST only be sent on the leading connection, MUST NOT be changed 92 after the leading connection login, and MUST only be sent after the 93 security negotiation login stage has completed (during operational 94 negotiation login stage). The key may be sent during normal or 95 discovery sessions. 97 2.1. X#NodeArchitecture 99 Use: LO, Declarative 100 Senders: Initiator and Target 101 Scope: SW 103 X#NodeArchitecture= 105 Examples: 107 X#NodeArchitecture=ExampleOS/v1234,ExampleInc_SW_Initiator/1.05a 108 X#NodeArchitecture=ExampleInc_HW_Initiator/4010,Firmware/2.0.0.5 109 X#NodeArchitecture=ExampleInc_SW_Initiator/2.1,CPU_Arch/i686 111 The initiator or target declares the details of its iSCSI node 112 architecture to the remote endpoint. These details may include, but 113 are not limited to, iSCSI vendor software, firmware, or hardware 114 versions, the OS version, or hardware architecture. 116 The length of the key value (total length of the list-of-values) MUST 117 NOT be greater than 255 bytes. 119 X#NodeArchitecture MUST NOT be redeclared. 121 3. Implementation 123 Functional behavior of the iSCSI node (this includes the iSCSI 124 protocol logic -- the SCSI, iSCSI, and TCP/IP protocols) MUST NOT 125 depend on the presence, absence, or content of the key. The key MUST 126 NOT be used by iSCSI nodes for interoperability, or exclusion of 127 other nodes. To ensure proper use, key values SHOULD be set by the 128 node itself, and there SHOULD NOT be provisions for the key values to 129 contain user-defined text. 131 Nodes implementing this key MAY choose to only transmit the key, only 132 log the key values received from other nodes, or both transmit and 133 log the key values. Each node choosing to implement transmission of 134 the key values MUST be prepared to handle the response of RFC 3720 135 [2] compliant nodes that do not understand the key (RFC 3720 [2] 136 states that compliant nodes MUST respond with 137 X#NodeArchitecture=NotUnderstood). 139 Nodes that implement transmission and/or logging of the key values 140 may also implement administrative mechanisms that disable and/or 141 change the logging and key transmission detail (see Security 142 Considerations). Thus, a valid implementation of this key may be 143 that a node is completely silent (the node does not transmit any key 144 value, and simply discards any key values it receives without issuing 145 a NotUnderstood response). 147 4. Security Considerations 149 This extension key transmits specific implementation details about 150 the node that sends it; such details may be considered sensitive in 151 some environments. For example, if a certain software or firmware 152 version is known to contain security weaknesses, announcing the 153 presence of that version via this key may not be desirable. The 154 countermeasures for this security concern are: 156 o sending less detailed information in the key values, or 158 o not sending the extension key, or 160 o using IPsec to provide confidentiality for the iSCSI connection on 161 which the key is sent (see RFC 3720 [2] and RFC 3723 [4]). 163 To support the first and second countermeasures, all implementations 164 of this extension key MUST provide an administrative mechanism to 165 disable sending the key. In addition, all implementations SHOULD 166 provide an administrative mechanism to configure a verbosity level of 167 the key value, thereby controlling the amount of information sent. 168 For example, a lower verbosity might enable transmission of node 169 architecture component names only, but no version numbers. 171 The choice of which countermeasure is most appropriate depends on the 172 environment. However, sending less detailed information in the key 173 values may be an acceptable countermeasure in many environments, 174 since it provides a compromise between sending too much information 175 and the other more complete countermeasures of not sending the key at 176 all or using IPsec. 178 In addition to security considerations involving transmission of the 179 key contents, any logging method(s) used for the key values MUST keep 180 the information secure from intruders. For all implementations, the 181 requirements to address this security concern are: 183 o display of the log MUST only be possible with administrative 184 rights to the node 186 o options to disable logging to disk and to keep logs for a fixed 187 duration SHOULD be provided 189 Finally, it is important to note that different nodes may have 190 different levels of risk, and these differences may affect the 191 implementation. The components of risk include assets, threats, and 192 vulnerabilities. Consider the following example iSCSI nodes, which 193 demonstrate differences in assets and vulnerabilities of the nodes, 194 and as a result, differences in implementation: 196 o One iSCSI target based on a special-purpose operating system. 197 Since the iSCSI target controls access to the data storage 198 containing company assets, the asset level is seen as very high. 199 Also, because of the special-purpose operating system, in which 200 vulnerabilities are less well-known, the vulnerability level is 201 viewed as low. 203 o Multiple iSCSI initiators in a blade farm, each running a general- 204 purpose operating system. The asset level of each node is viewed 205 as low, since blades are replaceable and low cost. However, the 206 vulnerability level is viewed as high, since there are many well- 207 known vulnerabilities to the general-purpose operating system. 209 For the above target, an appropriate implementation might be logging 210 of received key values, but no transmission of the key. For the 211 initiators, an appropriate implementation might be transmission of 212 the key, but no logging of received key values. 214 5. IANA Considerations 216 The standards action of this document updates RFC 3720 to allow any 217 iSCSI extension item, specifically X# extension text keys, Y# digest 218 algorithms, and Z# authentication methods, to be defined by a 219 standards track RFC or experimental RFC in addition to an 220 informational RFC. This document is a standards track RFC that 221 defines an X# extension text key. 223 The IANA iSCSI Extended Key registry does not correspond to RFC 3720 224 that defined it. The registry should contain three fields for each 225 extended key: 227 o Key Name 229 o Description 231 o Reference 233 IANA should modify the registry accordingly. 235 IANA should register this key as follows: 237 o Key Name: X#NodeArchitecture 239 o Description: Node architecture details 241 o Reference: [this RFC-to-be] 243 -- RFC Editor: The text from "The IANA iSCSI Extended Key" through 244 "modify the registry accordingly." should be removed after the IANA 245 actions for this document are performed prior to RFC publication. 247 6. References 249 6.1. Normative References 251 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 252 Levels", BCP 14, RFC 2119, March 1997. 254 [2] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. 255 Zeidner, "Internet Small Computer Systems Interface (iSCSI)", 256 RFC 3720, April 2004. 258 6.2. Informative References 260 [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 261 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 262 HTTP/1.1", RFC 2616, June 1999. 264 [4] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, 265 "Securing Block Storage Protocols over IP", RFC 3723, 266 April 2004. 268 Appendix A. Acknowledgments 270 The IP Storage (ips) Working Group in the Transport Area of IETF has 271 been responsible for defining the iSCSI protocol (apart from a host 272 of other relevant IP Storage protocols). The editor acknowledges the 273 contributions of the entire working group. 275 The following individuals directly contributed to identifying issues 276 and/or suggesting resolutions to the issues found in this document: 277 David Black, Mallikarjun Chadalapaka, Paul Koning, Julian Satran, 278 John Hufferd, Claire Kraft, Ranga Sankar, Joseph Pittman, Greg Berg, 279 John Forte, Jim Yuill, William Studenmund, and Ken Sandars. This 280 document benefited from all these contributions. 282 Finally, the author recognizes Network Appliance, Inc. for 283 sponsorship and support during the development of this work. 285 Author's Address 287 Dave Wysochanski 288 8311 Brier Creek Parkway 289 Suite 105-296 290 Raleigh, NC 27617 291 US 293 Phone: +1 919 696 8130 294 Email: wysochanski@pobox.com 296 Full Copyright Statement 298 Copyright (C) The Internet Society (2006). 300 This document is subject to the rights, licenses and restrictions 301 contained in BCP 78, and except as set forth therein, the authors 302 retain all their rights. 304 This document and the information contained herein are provided on an 305 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 306 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 307 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 308 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 309 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 310 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 312 Intellectual Property 314 The IETF takes no position regarding the validity or scope of any 315 Intellectual Property Rights or other rights that might be claimed to 316 pertain to the implementation or use of the technology described in 317 this document or the extent to which any license under such rights 318 might or might not be available; nor does it represent that it has 319 made any independent effort to identify any such rights. Information 320 on the procedures with respect to rights in RFC documents can be 321 found in BCP 78 and BCP 79. 323 Copies of IPR disclosures made to the IETF Secretariat and any 324 assurances of licenses to be made available, or the result of an 325 attempt made to obtain a general license or permission for the use of 326 such proprietary rights by implementers or users of this 327 specification can be obtained from the IETF on-line IPR repository at 328 http://www.ietf.org/ipr. 330 The IETF invites any interested party to bring to its attention any 331 copyrights, patents or patent applications, or other proprietary 332 rights that may cover technology that may be required to implement 333 this standard. Please address the information to the IETF at 334 ietf-ipr@ietf.org. 336 Acknowledgment 338 Funding for the RFC Editor function is provided by the IETF 339 Administrative Support Activity (IASA).