idnits 2.17.1 draft-ietf-ips-iscsi-boot-05.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 141: '... The option field consists of an UTF-8[8] string. The string MUST...' RFC 2119 keyword, line 165: '... domain name, the name MUST be a fully...' RFC 2119 keyword, line 166: '... name (FQDN) and SHOULD abide by the r...' RFC 2119 keyword, line 168: '... configuration server SHOULD contain the Domain Name Server Option[1]....' RFC 2119 keyword, line 183: '...ansport protocol MUST have been approv...' 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 (22 February 2002) is 8098 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 336, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 375, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 386, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 389, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 392, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 395, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 398, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 401, 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. '16' -- 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. '23' -- Possible downref: Non-RFC (?) normative reference: ref. '24' Summary: 15 errors (**), 0 flaws (~~), 11 warnings (==), 10 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-05.txt Duncan Missimer 5 Category: Standards HP 6 Constantin Sapuntzakis 7 Cisco 8 22 February 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 Abstract 31 The Small Computer Systems Interface (SCSI) is a popular family of 32 protocols for communicating with I/O devices, especially storage 33 devices. iSCSI is a proposed transport protocol for SCSI that 34 operates on top of TCP[12]. This memo describes a standard mechanism 35 to enable clients to bootstrap themselves using the iSCSI protocol. 36 The goal of this standard is to enable iSCSI boot clients to obtain 37 the information to open an iSCSI session with the iSCSI boot server, 38 assuming this information is not available. 40 1. Requirements 42 1. There must be no restriction of network topology between the iSCSI 43 boot client and the boot server. Consequently, it is possible for an 44 iSCSI boot client to boot from an iSCSI boot server behind gateways 45 or firewalls as long as it is possible to establish an iSCSI session 46 between the client and the server. 48 2. The following represents the minimum information required for an 50 Standards-Track iSCSI BootStrapping Draft 22 February 2001 52 iSCSI boot client to contact an iSCSI boot server: (a) the client's 53 IP address (IPv6 or IPv4); (b) the server's iSCSI Service Delivery 54 Port Name; and (c) mandatory iSCSI initiator capability. 56 The above assumes that the default LUN for the boot process is 0 and 57 the default port for the iSCSI boot server is the well-known iSCSI 58 port. However, both may be overridden at the time of configuration. 60 Additional information may be required at each stage of the boot 61 process. 63 3. It is possible for the iSCSI boot client to have none of the above 64 information or capability on starting. 66 4. The client should be able to complete boot without user 67 intervention (for boots that occur during an unattended power-up). 68 However, there should be a mechanism for the user to input values so 69 as to bypass stages of the boot protocol. 71 5. Additional protocol software (for example, DHCP) may be necessary 72 if the minimum information required for an iSCSI session is not 73 provided. 75 2. Related Work 77 The Reverse Address Resolution Protocol (RARP)[7](through the 78 extensions defined in the Dynamic RARP (DRARP))[4] explicitly 79 addresses the problem of network address discovery, and includes an 80 automatic IP address assignment mechanism. The Trivial File Transfer 81 Protocol (TFTP)[9] provides for transport of a boot image from a boot 82 server. BOOTP[5,8,10] is a transport mechanism for a collection of 83 configuration information. BOOTP is also extensible, and official 84 extensions have been defined for several configuration parameters. 85 DHCPv4[3,6] and DHCPv6[13] are standards for hosts to be dynamically 86 configured in an IP network. The Service Location Protocol (SLP) 87 provides for location of higher level services[1,15]. 89 3. Software stage 91 Some iSCSI boot clients may lack the resources to boot up with the 92 mandatory iSCSI initiator capability. Such boot clients may choose to 93 obtain iSCSI initiator software from a boot server. Currently, there 94 are many established protocols that allow such a service to enable 95 clients to load software images. For example, BOOTP and DHCP servers 96 have the capability to provide software images on requests from boot 97 clients. A particular implementation of this approach is the PXE 98 protocol[17], which uses DHCP extensions and MTFTP to allow boot 99 clients to load software images. 101 Standards-Track iSCSI BootStrapping Draft 22 February 2001 103 It is to be noted that this document does not recommend any of the 104 above protocols, and the final decision of which boot protocol is to 105 be used to load iSCSI initiator software is left to the discretion of 106 the implementor. 108 4. DHCP stage 110 In order to use an iSCSI boot server, the following pieces of 111 information are required. 113 - The IP address of the iSCSI boot client (IPv4 or IPv6) 115 - The IP transport endpoint for the iSCSI service delivery port for 116 the iSCSI boot server. If the transport is TCP, for example, this 117 has to resolve to an IP address and a TCP port number. 119 - The eight-byte LUN structure identifying the device within the 120 iSCSI boot server. 122 At boot time, all or none of this information may be stored in the 123 firmware of the iSCSI boot client. This section describes techniques 124 for obtaining the required information. 126 An iSCSI boot client which does not know its IP address at power-on 127 may acquire its IP address via DHCP. An iSCSI boot client which is 128 capable of using both DHCPv6 and DHCPv4 should first attempt to use 129 DHCPv6 to obtain its IP address, falling back on DHCPv4 in the event 130 of failure. 132 Unless otherwise specified here, DHCP fields such as the client ID 133 and gateway information are used identically with applications other 134 than iSCSI. 136 A DHCP server (v4 or v6) may instruct an iSCSI client how to reach 137 its boot device. This is done using the variable length DHCP option 138 named Root Path. The use of the option field is reserved for iSCSI 139 boot use by prefacing the string with "iscsi:". 141 The option field consists of an UTF-8[8] string. The string MUST 142 contain only alphanumberic characters, "." , ":" and "-"; no other 143 characters are permissible. The string has the following composition: 145 "iscsi:"":"":"":"":" 147 The fields "servername", "port", "protocol" and "LUN" are optional 148 and should be left blank if there are no corresponding values. The 149 "targetname" field is not optional and must be provided. 151 Standards-Track iSCSI BootStrapping Draft 22 February 2001 153 Thv "servername" is the name of iSCSI server and contains either a 154 valid domain name, a literal IPv4 address, or a literal IPv6 address. 156 If the "servername" field contains a literal IPv4 address, the IPv4 157 address is in standard dotted decimal notation as defined in Section 158 2.1 of RFC 1123[6]. 160 If the "servername" field contains an IPv6 address, the address is 161 represented in the IPv6 address format x.x.x.x.x.x.x.x where the 'x's 162 are the hexadecimal values of the eight 16-bit pieces of the address. 163 Note that this format representation is specific to iSCSI boot. 165 If the "servername" is a domain name, the name MUST be a fully 166 qualified domian name (FQDN) and SHOULD abide by the rules specified 167 in Sections 3.1 and 3.5 of RFC 1034[7] and the reply from the host 168 configuration server SHOULD contain the Domain Name Server Option[1]. 169 It must also be pointed out that the use of DNS for address 170 translation in enterprise environments must contain adequate levels 171 of fault tolerance and security. 173 If the "servername" field contains 4 decimal components, the 174 "servername" is assumed to be an IPv4 address. If there are more than 175 4 decimal components or if there is a hexadecimal component, the the 176 "servername" is assumed to be an IPv6 address. If the least 177 significant (rightmost) component is an approved domain extension, 178 then the "servername" field is assumed to be a domain name. 180 The "protocol" field is the decimal representation of the IANA- 181 approved string for the trasport protocol to be used for iSCSI. If 182 the protocol field is left bank, the default value is assumed to be 183 "6" for TCP. The transport protocol MUST have been approved for use 184 in iSCSI; currently, the only approved protocol is TCP. 186 The "port" is the decimal representation of the port on which the 187 iSCSI boot server is listening. If not specified, the port defaults 188 to the well-known iSCSI port. 190 The "LUN" field is a 16 byte hexadecimal representation of the 8-byte 191 LU number in hex. Digits above 9 may be either lower or upper case, 192 and all 16 nibbles must be present. If the LUN field is blank, then 193 LUN 0 is assumed. 195 Note that SCSI targets are allowed to present different LU numberings 196 for different SCSI initiators, so that to our knowledge nothing 197 precludes a SCSI target from exporting several different devices to 198 several different SCSI initiators as their respective LU 0s. 200 The "targetname" field is an iSCSI Name that is defined by the naming 202 Standards-Track iSCSI BootStrapping Draft 22 February 2001 204 and discovery in Section 2.1 iSCSI Naming and Discovery draft[9] to 205 uniquely identify an iSCSI target. The use of the targetname 206 component is also defined by the iSCSI standard[4] and is to be used 207 accordingly. 209 If the "servername" field is left blank, then no default value is 210 assumed in its place. If the "protocol" field is left bank, the 211 default value is assumed to be "6" for TCP. If the "port" field is 212 not specified, the port defaults to the well-known iSCSI port. If 213 the LUN field is blank, then LUN 0 is assumed. 215 If the "servername" field is provided by DHCP, then that field is 216 used in conjunction with other associated fields to contact the boot 217 server in the Boot stage (Section 6). 219 However, if the "servername" field is not provided, then the 220 "targetname" field is then used in the Discovery Service stage 221 (Section 5). 223 5. Discovery Service stage: 225 This stage is required if the DHCP server (v4 or v6) is unaware of 226 the Service Delivery Port Name of the iSCSI boot server. The 227 implemention of the discovery service is to based on the SLP 228 protocol[1,24]. 230 The iSCSI boot client may have obtained the targetname of the iSCSI 231 boot server in the DHCP stage (Section 4). In that case, the iSCSI 232 boot client queries the Discovery Service using query string 1 as 233 specified in the iSCSI SLP interaction document[24] to resolve the 234 targetname to an IP address and port number. One this is obtained, 235 the iSCSI boot client proceeds to the Boot Stage (Section 6). 237 It is possible that the port number obtained from the Discovery 238 Service may conflict with the one obtained from the DHCP service. In 239 such a case, the implementor has the option to try both port numbers 240 in the Boot stage. 242 If the iSCSI boot client does not have any targetname information, 243 the iSCSI boot client then may query the Discovery Service with query 244 string 4 as specified in the iSCSI SLP interaction document[24]. In 245 response to this query, the discovery service provides the boot 246 client with a list of iSCSI boot servers the boot client is allowed 247 to access. 249 If the list of iSCSI boot servers is empty, subsequent actions are 250 left to the discretion of the implementor. Otherwise, the iSCSI boot 252 Standards-Track iSCSI BootStrapping Draft 22 February 2001 254 client may contact any iSCSI boot server in the list. Moreover, the 255 the order in which iSCSI boot servers are contacted is also left to 256 the discretion of the implementor. 258 6. Boot Stage 260 Once the iSCSI boot client has obtained the minimum information to 261 open an iSCSI session with the iSCSI boot server, the actual booting 262 process can start. 264 The actual sequence of iSCSI commands needed to complete the boot 265 process is left to the implementor. This was done because of varying 266 requirements from different vendors and equipments, making it 267 difficult to specify a common subset of the iSCSI standard that would 268 be acceptable to everybody. 270 However, the use of a discovery session is not recommended because at 271 this stage (i) a boot server has probably been found and (ii) the 272 response obtained from the discovery session does not qualify an 273 iSCSI boot server from an iSCSI target. 275 The iSCSI session established for boot may be taken over the booted 276 software in the iSCSI boot client. 278 7. Security 280 The security discussion is centered around each stage of the iSCSI 281 boot process. 283 The software stage can be secured by using public key encryption and 284 digitial signatures. This is the approach taken by the popular PXE 285 boot framework. 287 With regards to the DHCP stage, securing the host configuration 288 protocol is beyond the scope of this document. Authentication of DHCP 289 messages is described in [16]. 291 The security issues in the Discovery Service stage are addressed by 292 public key ciphering as stated in the the SLP version 2 document[1]. 294 For the Boot stage, the iSCSI standard supports various methods of 295 authenticated login and encrypted and authenticated connections for 296 security[12]. How to configure the security parameters of an iSCSI 297 boot client is beyond the scope of this document. 299 The iSCSI boot service may be subjected to denial of service attacks. 300 The use of IPSEC as mandated by the iSCSI standard[12] can be used to 302 Standards-Track iSCSI BootStrapping Draft 22 February 2001 304 protect against such attacks. However, ARP is still vulnerable to 305 such type of attacks. 307 Security in the Boot stage is also dependent on the verification of 308 the boot image being loaded. One key difference between the iSCSI 309 boot mechanism and BOOTP-based image loading is the fact that the 310 identity of a boot image may not be known when the Boot stage starts. 311 The identity of certain boot images and their locations are known 312 only after examining the contents of a boot disk exposed by the iSCSI 313 boot service. Furthermore, images themselves may recursively load 314 other images based on both hardware configurations and user input. 316 Consequently, a practical way to verify loaded boot images is to make 317 sure that each image loading software verify the image to be loaded 318 using a mechanism of their choice. 320 Another point to be noted is that if a boot image inherits an iSCSI 321 session from a previously loaded boot image, the boot image also 322 inherts the security properties of the iSCSI session. 324 Acknowledgments 326 We wish to thank John Hufferd for taking the initiative to form the 327 iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, 328 Bernard Aboba, David Robinson and Mark Bakke for helpful suggestions 329 and pointers regarding the draft document. 331 References 333 [1] Guttman, E., Perkins, C., Verizades, J., Day, M., "Service 334 Location Protocol v2", RFC 2608, June 1999. 336 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 337 Extensions", RFC 2132, Lachman Technology, Inc., Bucknell 338 University, October 1993. 340 [3] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 341 Bucknell University, March 1997. 343 [4] Brownell, D, "Dynamic Reverse Address Resolution Protocol 344 (DRARP)", Work in Progress. 346 [5] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 347 Stanford and SUN Microsystems, September 1985. 349 [6] Droms, D., "Interoperation between DHCP and BOOTP" RFC 1534, 350 Bucknell University, October 1993. 352 Standards-Track iSCSI BootStrapping Draft 22 February 2001 354 [7] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse 355 Address Resolution Protocol", RFC 903, Stanford, June 1984. 357 [8] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, 358 USC/Information Sciences Institute, August 1993. 360 [9] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, 361 June 1981. 363 [10] Wimer, W., "Clarifications and Extensions for the Bootstrap 364 Protocol", RFC 1532, Carnegie Mellon University, October 1993. 366 [11] Bradner, S., "The Internet Standards Process -- 367 Revision 3", RFC 2026, October 1996. 369 [12] Satran, J. et al., "iSCSI", Internet-Draft, July 2001. 371 [13] Bound, J., Canney, M., and Perkins, C., "Dynamic Host 372 Configuration 373 Protocol for IPv6", Internet-Draft, June 2001. 375 [14] Bakke, M. et al., "iSCSI Naming and Discovery", Internet-Draft, 376 July 2001. 378 [15] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service 379 Location Protocol", RFC 2165, June 1997. 381 [16] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 382 Internet-Draft, November 2000. 384 [17] http://developer.intel.com/ial/WfM/wfm20/design/pxedt/index.htm 386 [18] Stewart, R., et al. "Stream Control Transmission Protocol", RFC 387 2960, October 2000. 389 [19] Droms, R., "Procedures and IANA Guidelines for Approval of New 390 DHCP Options and Message Types", RFC 2939, September 2000. 392 [20] Yergeau, F., "UTF-8: A Transformation Format for ISO-10646", RFC 393 2279, January 1998. 395 [21] Hinden, R., Deering, S., "IP version 6 Addressing Architecture", 396 RFC 2273, July 1998. 398 [22] Braden, R., "Requirements for Internet Hosts - Application and 399 Support", RFC 1123, October 1989. 401 [23] Mockaopertis, P., "Domain Names - Concepts and Facilities", RFC 403 Standards-Track iSCSI BootStrapping Draft 22 February 2001 405 1034, November 1987. 407 [24] Bakke, M., et al. "Finding iSCSI Targets and Name Servers using 408 SLP", Internet-Draft, July 2001. 410 Author's Addresses 412 Prasenjit Sarkar 413 IBM Almaden Research Center 414 650 Harry Road 415 San Jose, CA 95120, USA 416 Phone: +1 408 927 1417 417 Email: psarkar@almaden.ibm.com 419 Duncan Missimer 420 Hewlett-Packard Company 421 19420 Homestead Road, M/S 43lo 422 Cupertino, CA 95014, USA 423 Phone: +1 408 447 5390 424 Email: duncan_missimer@hp.com 426 Constantine Sapuntzakis 427 Cisco Systems, Inc. 428 170 W. Tasman Drive 429 San Jose, CA 95134, USA 430 Phone: +1 650 520 0205 431 Email: csapuntz@cisco.com 433 Full Copyright Statement 435 "Copyright (C) The Internet Society (date). All Rights Reserved. This 436 document and translations of it may be copied and furnished to 437 others, and derivative works that comment on or otherwise explain it 438 or assist in its implementation may be prepared, copied, published 439 and distributed, in whole or in part, without restriction of any 440 kind, provided that the above copyright notice and this paragraph are 441 included on all such copies and derivative works. However, this 442 document itself may not be modified in any way, such as by removing 443 the copyright notice or references to the Internet Society or other 444 Internet organizations, except as needed for the purpose of 445 developing Internet standards in which case the procedures for 446 copyrights defined in the Internet Standards process must be 447 followed, or as required to translate it into languages other than 448 English. 450 The limited permissions granted above are perpetual and will not be 451 revoked by the Internet Society or its successors or assigns. 453 Standards-Track iSCSI BootStrapping Draft 22 February 2001 455 This document and the information contained herein is provided on an 456 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 457 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 458 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 459 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 460 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."