idnits 2.17.1 draft-ietf-ips-iscsi-boot-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([12]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '...erver (v4 or v6) MAY instruct an iSCSI...' RFC 2119 keyword, line 152: '... The option field consists of an UTF-8[8] string. The string MUST...' RFC 2119 keyword, line 158: '...rt", "protocol" and "LUN" are OPTIONAL...' RFC 2119 keyword, line 160: '... is not optional and MUST be provided....' RFC 2119 keyword, line 166: '... address MUST be in standard dotted ...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Standards', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (24 September 2002) is 7885 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) == Unused Reference: '2' is defined on line 344, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 383, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 395, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 398, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 403, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 409, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 412, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1497 (ref. '8') (Obsoleted by RFC 1533) ** Obsolete normative reference: RFC 783 (ref. '9') (Obsoleted by RFC 1350) ** Obsolete normative reference: RFC 1532 (ref. '10') (Obsoleted by RFC 1542) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2960 (ref. '18') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 2279 (ref. '20') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2273 (ref. '21') (Obsoleted by RFC 2573) -- Possible downref: Non-RFC (?) normative reference: ref. '24' Summary: 15 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS Prasenjit Sarkar 3 Internet Draft IBM 4 Document: draft-ietf-ips-iscsi-boot-07.txt Duncan Missimer 5 Category: Standards Rhapsody Networks 6 Constantin Sapuntzakis 7 Stanford University 8 24 September 2002 10 Bootstrapping Clients using the iSCSI Protocol 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [11]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or made obsolete by other documents at 22 any time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." The list 24 of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 31 documents are to be interpreted as described in RFC 2119. 33 Abstract 35 The Small Computer Systems Interface (SCSI) is a popular family of 36 protocols for communicating with I/O devices, especially storage 37 devices. iSCSI is a proposed transport protocol for SCSI that 38 operates on top of TCP[12]. This memo describes a standard mechanism 39 to enable clients to bootstrap themselves using the iSCSI protocol. 40 The goal of this standard is to enable iSCSI boot clients to obtain 41 the information to open an iSCSI session with the iSCSI boot server, 42 assuming this information is not available. 44 1. Requirements 46 1. There must be no restriction of network topology between the iSCSI 47 boot client and the boot server other than those in effect for 48 establishing the iSCSI session. Consequently, it is possible for an 50 Standards-Track iSCSI BootStrapping Draft 26 June 2002 52 iSCSI boot client to boot from an iSCSI boot server behind gateways 53 or firewalls as long as it is possible to establish an iSCSI session 54 between the client and the server. 56 2. The following represents the minimum information required for an 57 iSCSI boot client to contact an iSCSI boot server: (a) the client's 58 IP address (IPv6 or IPv4); (b) the server's iSCSI Target Name; and 59 (c) mandatory iSCSI initiator capability. 61 The above assumes that the default LUN for the boot process is 0 and 62 the default port for the iSCSI boot server is the well-known iSCSI 63 port. However, both may be overridden at the time of configuration. 65 Additional information may be required at each stage of the boot 66 process. 68 3. It is possible for the iSCSI boot client to have none of the above 69 information or capability on starting. 71 4. The client should be able to complete boot without user 72 intervention (for boots that occur during an unattended power-up). 73 However, there should be a mechanism for the user to input values so 74 as to bypass stages of the boot protocol. 76 5. Additional protocol software (for example, DHCP) may be necessary 77 if the minimum information required for an iSCSI session is not 78 provided. 80 2. Related Work 82 The Reverse Address Resolution Protocol (RARP)[7](through the 83 extensions defined in the Dynamic RARP (DRARP))[4] explicitly 84 addresses the problem of network address discovery, and includes an 85 automatic IP address assignment mechanism. The Trivial File Transfer 86 Protocol (TFTP)[9] provides for transport of a boot image from a boot 87 server. BOOTP[5,8,10] is a transport mechanism for a collection of 88 configuration information. BOOTP is also extensible, and official 89 extensions have been defined for several configuration parameters. 90 DHCPv4[3,6] and DHCPv6[13] are standards for hosts to be dynamically 91 configured in an IP network. The Service Location Protocol (SLP) 92 provides for location of higher level services[1,15]. 94 3. Software stage 96 Some iSCSI boot clients may lack the resources to boot up with the 97 mandatory iSCSI initiator capability. Such boot clients may choose to 98 obtain iSCSI initiator software from a boot server. Currently, there 99 are many established protocols that allow such a service to enable 101 Standards-Track iSCSI BootStrapping Draft 26 June 2002 103 clients to load software images. For example, BOOTP and DHCP servers 104 have the capability to provide software images on requests from boot 105 clients. A particular implementation of this approach is the PXE 106 protocol[17], which uses DHCP extensions and MTFTP to allow boot 107 clients to load software images. 109 It is to be noted that this document does not recommend any of the 110 above protocols, and the final decision of which boot protocol is to 111 be used to load iSCSI initiator software is left to the discretion of 112 the implementor. 114 4. DHCP stage 116 In order to use an iSCSI boot server, the following pieces of 117 information are required for an ISCSI boot client. 119 - The IP address of the iSCSI boot client (IPv4 or IPv6) 121 - The IP transport endpoint for the iSCSI Target Port for the iSCSI 122 boot server. If the transport is TCP, for example, this has to 123 resolve to an IP address and a TCP port number. TCP is currently the 124 only transport approved for iSCSI. 126 - The eight-byte LUN structure identifying the Logical Unit within 127 the iSCSI boot server. 129 At boot time, all or none of this information may be stored in the 130 iSCSI boot client. This section describes techniques for obtaining 131 the required information via the DHCP stage. Otherwise, if the iSCSI 132 boot client has all the information, the boot client may proceed 133 directly to the Boot stage. 135 An iSCSI boot client which does not know its IP address at power-on 136 may acquire its IP address via DHCP. An iSCSI boot client which is 137 capable of using both DHCPv6 and DHCPv4 should first attempt to use 138 DHCPv6 to obtain its IP address, falling back on DHCPv4 in the event 139 of failure. 141 Unless otherwise specified here, DHCP fields such as the client ID 142 and gateway information are used in an identical way as applications 143 other than iSCSI do. 145 A DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach 146 its boot device. This is done using the variable length DHCP option 147 named Root Path. The use of the option field is reserved for iSCSI 148 boot use by prefacing the string with "iscsi:". 150 Standards-Track iSCSI BootStrapping Draft 26 June 2002 152 The option field consists of an UTF-8[8] string. The string MUST 153 contain only alphanumberic characters, "." , ":" and "-"; no other 154 characters are permissible. The string has the following composition: 156 "iscsi:"":"":"":"":" 158 The fields "servername", "port", "protocol" and "LUN" are OPTIONAL 159 and should be left blank if there are no corresponding values. The 160 "targetname" field is not optional and MUST be provided. 162 The "servername" is the name of iSCSI server and contains either a 163 valid domain name, a literal IPv4 address, or a literal IPv6 address. 165 If the "servername" field contains a literal IPv4 address, the IPv4 166 address MUST be in standard dotted decimal notation as defined in 167 Section 2.1 of RFC 1123[6]. 169 If the "servername" field contains an IPv6 address, the address MUST 170 be represented in the IPv6 address format x.x.x.x.x.x.x.x where the 171 'x's are the hexadecimal values of the eight 16-bit pieces of the 172 address. Note that this format representation is specific to iSCSI 173 boot. 175 If the "servername" is a domain name, the name MUST be a fully 176 qualified domain name (FQDN) and should abide by the rules specified 177 in Sections 3.1 and 3.5 of RFC 1034[7] and the reply from the host 178 configuration server should contain the Domain Name Server Option[1]. 179 It must also be pointed out that the use of DNS for address 180 translation in enterprise environments must contain adequate levels 181 of fault tolerance and security. 183 If the "servername" field contains 4 decimal components, the 184 "servername" is assumed to be an IPv4 address. If there are more than 185 4 decimal components or if there is a hexadecimal component, the the 186 "servername" is assumed to be an IPv6 address. If the least 187 significant (rightmost) component is an approved domain extension, 188 then the "servername" field is assumed to be a domain name. If the 189 "servername" field is left blank, then no default value is assumed in 190 its place. 192 The "protocol" field is the decimal representation of the IANA- 193 approved string for the trasport protocol to be used for iSCSI. If 194 the protocol field is left bank, the default value is assumed to be 195 "6" for TCP. The transport protocol MUST have been approved for use 196 in iSCSI; currently, the only approved protocol is TCP. 198 The "port" is the decimal representation of the port on which the 199 iSCSI boot server is listening. If not specified, the port defaults 201 Standards-Track iSCSI BootStrapping Draft 26 June 2002 203 to the well-known iSCSI port. 205 The "LUN" field is a hexadecimal representation of the LU number. If 206 the LUN field is blank, then LUN 0 is assumed. If the LUN field is 207 not blank, the representation MUST be divided into four groups of 208 four hexadecimal digits, separated by "-". Digits above 9 may be 209 either lower or upper case. An example of such a representation 210 would be 4752-3A4F-6b7e-2F99. For the sake of brevity, at most three 211 leading zero ("0") digits MAY be omitted in any group of hexadecimal 212 digits. Thus, the "LUN" representation 6734-9-156f-127 is equivalent 213 to 6734-0009-156f-0127. Furthermore, trailing groups containing only 214 the "0" digit MAY be omitted along with the preceding "-". So, the 215 "LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000. 216 Other concise representations of the LUN field MUST NOT be used. 218 Note that SCSI targets are allowed to present different LU numberings 219 for different SCSI initiators, so that to our knowledge nothing 220 precludes a SCSI target from exporting several different LUs to 221 several different SCSI initiators as their respective LUN 0s. 223 The "targetname" field is an iSCSI Name that is defined by the iSCSI 224 standard[4] to uniquely identify an iSCSI target. 226 If the "servername" field is provided by DHCP, then that field is 227 used in conjunction with other associated fields to contact the boot 228 server in the Boot stage (Section 6). However, if the "servername" 229 field is not provided, then the "targetname" field is then used in 230 the Discovery Service stage in conjunction with other associated 231 fields. (Section 5). 233 5. Discovery Service stage 235 This stage is required if the DHCP server (v4 or v6) is unaware of 236 any iSCSI boot servers or if the DHCP server is unable to provide the 237 minimum information required to connect to the iSCSI boot server 238 other than the targetname. 240 The discovery service is based on the SLP protocol[1,24] and is an 241 instantiation of the SLP Service or Directory Agent. 243 The iSCSI boot client may have obtained the targetname of the iSCSI 244 boot server in the DHCP stage (Section 4). In that case, the iSCSI 245 boot client queries the Discovery Service using query string 1 of the 246 iSCSI Target Concrete Service Type Template as specified in Section 247 6.2 of the iSCSI SLP interaction document[24] to resolve the 248 targetname to an IP address and port number. Once this is obtained, 249 the iSCSI boot client proceeds to the Boot stage (Section 6). 251 Standards-Track iSCSI BootStrapping Draft 26 June 2002 253 It is possible that the port number obtained from the Discovery 254 Service may conflict with the one obtained from the DHCP service. In 255 such a case, the implementor has the option to try both port numbers 256 in the Boot stage. 258 If the iSCSI boot client does not have any targetname information, 259 the iSCSI boot client then may query the Discovery Service with query 260 string 4 of the iSCSI Target Concrete Service Type Template as 261 specified in Section 6.2 of the iSCSI SLP interaction document[24]. 262 In response to this query, the discovery service provides the boot 263 client with a list of iSCSI boot servers the boot client is allowed 264 to access. 266 If the list of iSCSI boot servers is empty, subsequent actions are 267 left to the discretion of the implementor. Otherwise, the iSCSI boot 268 client may contact any iSCSI boot server in the list. Moreover, the 269 order in which iSCSI boot servers are contacted is also left to the 270 discretion of the implementor. 272 6. Boot stage 274 Once the iSCSI boot client has obtained the minimum information to 275 open an iSCSI session with the iSCSI boot server, the actual booting 276 process can start. 278 The actual sequence of iSCSI commands needed to complete the boot 279 process is left to the implementor. This was done because of varying 280 requirements from different vendors and equipment, making it 281 difficult to specify a common subset of the iSCSI standard that would 282 be acceptable to everybody. 284 The iSCSI session established for boot may be taken over by the 285 booted software in the iSCSI boot client. 287 7. Security 289 The security discussion is centered around each stage of the iSCSI 290 boot process. 292 The software stage can be secured by using public key encryption and 293 digitial signatures. This is the approach taken by the popular PXE 294 boot framework. 296 With regards to the DHCP stage, securing the host configuration 297 protocol is beyond the scope of this document. Authentication of DHCP 298 messages is described in [16]. 300 Standards-Track iSCSI BootStrapping Draft 26 June 2002 302 The security issues in the Discovery Service stage are addressed by 303 public key ciphering as stated in the the SLP version 2 document[1]. 305 For the Boot stage, the iSCSI standard supports various methods of 306 authentication and encryption for transport security[12]. The means 307 to configure the security parameters of an iSCSI boot client is 308 beyond the scope of this document. 310 The iSCSI boot service may be subjected to denial of service attacks. 311 The use of IPSEC as mandated by the iSCSI standard[12] can be used to 312 protect against such attacks. However, ARP is still vulnerable to 313 such type of attacks. 315 Security in the Boot stage is also dependent on the verification of 316 the boot image being loaded. One key difference between the iSCSI 317 boot mechanism and BOOTP-based image loading is the fact that the 318 identity of a boot image may not be known when the Boot stage starts. 319 The identity of certain boot images and their locations are known 320 only after examining the contents of a boot disk exposed by the iSCSI 321 boot service. Furthermore, images themselves may recursively load 322 other images based on both hardware configurations and user input. 324 Consequently, a practical way to verify loaded boot images is to make 325 sure that each image loading software verify the image to be loaded 326 using a mechanism of their choice. 328 Another point to be noted is that if a boot image inherits an iSCSI 329 session from a previously loaded boot image, the boot image also 330 inherts the security properties of the iSCSI session. 332 Acknowledgments 334 We wish to thank John Hufferd for taking the initiative to form the 335 iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, 336 Bernard Aboba, David Robinson, Mark Bakke and Mallikarjun Chadalapaka 337 for helpful suggestions and pointers regarding the draft document. 339 References 341 [1] Guttman, E., Perkins, C., Verizades, J., Day, M., "Service 342 Location Protocol v2", RFC 2608, June 1999. 344 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 345 Extensions", RFC 2132, Lachman Technology, Inc., Bucknell 346 University, October 1993. 348 [3] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 349 Bucknell University, March 1997. 351 Standards-Track iSCSI BootStrapping Draft 26 June 2002 353 [4] Brownell, D, "Dynamic Reverse Address Resolution Protocol 354 (DRARP)", Work in Progress. 356 [5] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 357 Stanford and SUN Microsystems, September 1985. 359 [6] Droms, D., "Interoperation between DHCP and BOOTP" RFC 1534, 360 Bucknell University, October 1993. 362 [7] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse 363 Address Resolution Protocol", RFC 903, Stanford, June 1984. 365 [8] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, 366 USC/Information Sciences Institute, August 1993. 368 [9] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, 369 June 1981. 371 [10] Wimer, W., "Clarifications and Extensions for the Bootstrap 372 Protocol", RFC 1532, Carnegie Mellon University, October 1993. 374 [11] Bradner, S., "The Internet Standards Process -- 375 Revision 3", RFC 2026, October 1996. 377 [12] Satran, J. et al., "iSCSI", Internet-Draft, September 2002. 379 [13] Bound, J., Canney, M., and Perkins, C., "Dynamic Host 380 Configuration 381 Protocol for IPv6", Internet-Draft, June 2002. 383 [14] Bakke, M. et al., "iSCSI Naming and Discovery", Internet-Draft, 384 July 2002. 386 [15] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service 387 Location Protocol", RFC 2165, June 1997. 389 [16] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", RFC 390 3118, June 2001. 392 [17] Intel Corp., "Boot Integrity Services", 393 http://www.intel.com/labs/manage/wfm/tools/bis 395 [18] Stewart, R., et al. "Stream Control Transmission Protocol", RFC 396 2960, October 2000. 398 [19] Droms, R., "Procedures and IANA Guidelines for Approval of New 399 DHCP Options and Message Types", RFC 2939, September 2000. 401 Standards-Track iSCSI BootStrapping Draft 26 June 2002 403 [20] Yergeau, F., "UTF-8: A Transformation Format for ISO-10646", RFC 404 2279, January 1998. 406 [21] Hinden, R., Deering, S., "IP version 6 Addressing Architecture", 407 RFC 2273, July 1998. 409 [22] Braden, R., "Requirements for Internet Hosts - Application and 410 Support", RFC 1123, October 1989. 412 [23] Mockaopertis, P., "Domain Names - Concepts and Facilities", RFC 413 1034, November 1987. 415 [24] Bakke, M., et al. "Finding iSCSI Targets and Name Servers using 416 SLP", Internet-Draft, March 2002. 418 Authors' Addresses 420 Prasenjit Sarkar 421 IBM Almaden Research Center 422 650 Harry Road 423 San Jose, CA 95120, USA 424 Phone: +1 408 927 1417 425 Email: psarkar@almaden.ibm.com 427 Duncan Missimer 428 Rhapsody Networks 429 3450 W Warren Avenue, 430 Fremont, CA 94538, USA 431 Phone: +1 510 743 3095 432 Email: dmissimer@rhapsodynetworks.com 434 Constantine Sapuntzakis 435 Stanford University 436 353 Serra Hall #406 437 Stanford, CA 94306, USA 438 Phone: +1 650 520 0205 439 Email: csapuntz@stanford.edu 441 Full Copyright Statement 443 "Copyright (C) The Internet Society (date). All Rights Reserved. This 444 document and translations of it may be copied and furnished to 445 others, and derivative works that comment on or otherwise explain it 446 or assist in its implementation may be prepared, copied, published 447 and distributed, in whole or in part, without restriction of any 448 kind, provided that the above copyright notice and this paragraph are 449 included on all such copies and derivative works. However, this 451 Standards-Track iSCSI BootStrapping Draft 26 June 2002 453 document itself may not be modified in any way, such as by removing 454 the copyright notice or references to the Internet Society or other 455 Internet organizations, except as needed for the purpose of 456 developing Internet standards in which case the procedures for 457 copyrights defined in the Internet Standards process must be 458 followed, or as required to translate it into languages other than 459 English. 461 The limited permissions granted above are perpetual and will not be 462 revoked by the Internet Society or its successors or assigns. 464 This document and the information contained herein is provided on an 465 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 466 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 467 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 468 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 469 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."