idnits 2.17.1 draft-ietf-ips-iscsi-boot-06.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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (26 June 2002) is 7974 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 334, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 373, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 384, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 387, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 393, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 396, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 399, but no explicit reference was found in the text ** 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) ** 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) Summary: 14 errors (**), 0 flaws (~~), 10 warnings (==), 2 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-06.txt Duncan Missimer 5 Category: Informational HP 6 Constantin Sapuntzakis 7 Cisco 8 26 June 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 other than those in effect for 44 establishing the iSCSI session. Consequently, it is possible for an 45 iSCSI boot client to boot from an iSCSI boot server behind gateways 46 or firewalls as long as it is possible to establish an iSCSI session 47 between the client and the server. 49 Standards-Track iSCSI BootStrapping Draft 26 June 2002 51 2. The following represents the minimum information required for an 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 Target Port Name; 54 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 100 Standards-Track iSCSI BootStrapping Draft 26 June 2002 102 clients to load software images. 104 It is to be noted that this document does not recommend any of the 105 above protocols, and the final decision of which boot protocol is to 106 be used to load iSCSI initiator software is left to the discretion of 107 the implementor. 109 4. DHCP stage 111 In order to use an iSCSI boot server, the following pieces of 112 information are required for an ISCSI boot client. 114 - The IP address of the iSCSI boot client (IPv4 or IPv6) 116 - The IP transport endpoint for the iSCSI Target Port for the iSCSI 117 boot server. If the transport is TCP, for example, this has to 118 resolve to an IP address and a TCP port number. TCP is currently the 119 only transport approved for iSCSI. 121 - The eight-byte LUN structure identifying the Logical Unit within 122 the iSCSI boot server. 124 At boot time, all or none of this information may be stored in the 125 iSCSI boot client. This section describes techniques for obtaining 126 the required information via the DHCP stage. Otherwise, if the iSCSI 127 boot client has all the information, the boot client may proceed 128 directly to the Boot stage. 130 An iSCSI boot client which does not know its IP address at power-on 131 may acquire its IP address via DHCP. An iSCSI boot client which is 132 capable of using both DHCPv6 and DHCPv4 should first attempt to use 133 DHCPv6 to obtain its IP address, falling back on DHCPv4 in the event 134 of failure. 136 Unless otherwise specified here, DHCP fields such as the client ID 137 and gateway information are used in an identical way as applications 138 other than iSCSI do. 140 A DHCP server (v4 or v6) may instruct an iSCSI client how to reach 141 its boot device. This is done using the variable length DHCP option 142 named Root Path. The use of the option field is reserved for iSCSI 143 boot use by prefacing the string with "iscsi:". 145 The option field consists of an UTF-8[8] string. The string must 146 contain only alphanumberic characters, "." , ":" and "-"; no other 147 characters are permissible. The string has the following composition: 149 Standards-Track iSCSI BootStrapping Draft 26 June 2002 151 "iscsi:"":"":"":"":" 153 The fields "servername", "port", "protocol" and "LUN" are optional 154 and should be left blank if there are no corresponding values. The 155 "targetname" field is not optional and must be provided. 157 The "servername" is the name of iSCSI server and contains either a 158 valid domain name, a literal IPv4 address, or a literal IPv6 address. 160 If the "servername" field contains a literal IPv4 address, the IPv4 161 address is in standard dotted decimal notation as defined in Section 162 2.1 of RFC 1123[6]. 164 If the "servername" field contains an IPv6 address, the address is 165 represented in the IPv6 address format x.x.x.x.x.x.x.x where the 'x's 166 are the hexadecimal values of the eight 16-bit pieces of the address. 167 Note that this format representation is specific to iSCSI boot. 169 If the "servername" is a domain name, the name must be a fully 170 qualified domian name (FQDN) and should abide by the rules specified 171 in Sections 3.1 and 3.5 of RFC 1034[7] and the reply from the host 172 configuration server should contain the Domain Name Server Option[1]. 173 It must also be pointed out that the use of DNS for address 174 translation in enterprise environments must contain adequate levels 175 of fault tolerance and security. 177 If the "servername" field contains 4 decimal components, the 178 "servername" is assumed to be an IPv4 address. If there are more than 179 4 decimal components or if there is a hexadecimal component, the the 180 "servername" is assumed to be an IPv6 address. If the least 181 significant (rightmost) component is an approved domain extension, 182 then the "servername" field is assumed to be a domain name. 184 The "protocol" field is the decimal representation of the IANA- 185 approved string for the trasport protocol to be used for iSCSI. If 186 the protocol field is left bank, the default value is assumed to be 187 "6" for TCP. The transport protocol must have been approved for use 188 in iSCSI; currently, the only approved protocol is TCP. 190 The "port" is the decimal representation of the port on which the 191 iSCSI boot server is listening. If not specified, the port defaults 192 to the well-known iSCSI port. 194 The "LUN" field is a hexadecimal representation of the 8-byte LU 195 number. Digits above 9 may be either lower or upper case, and all 16 196 nibbles must be present. If the LUN field is blank, then LUN 0 is 197 assumed. 199 Standards-Track iSCSI BootStrapping Draft 26 June 2002 201 Note that SCSI targets are allowed to present different LU numberings 202 for different SCSI initiators, so that to our knowledge nothing 203 precludes a SCSI target from exporting several different LU to 204 several different SCSI initiators as their respective LUN 0s. 206 The "targetname" field is an iSCSI Name that is defined by the iSCSI 207 standard[4] to uniquely identify an iSCSI target. 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 iSCSI Target Port Name of the iSCSI boot server. 228 The discovery service is based on the SLP protocol[1,24] and is an 229 instantiation of the SLP Service or Directory Agent. 231 The iSCSI boot client may have obtained the targetname of the iSCSI 232 boot server in the DHCP stage (Section 4). In that case, the iSCSI 233 boot client queries the Discovery Service using query string 1 of the 234 iSCSI Target Concrete Service Type Template as specified in Section 235 6.2 of the iSCSI SLP interaction document[24] to resolve the 236 targetname to an IP address and port number. Once this is obtained, 237 the iSCSI boot client proceeds to the Boot stage (Section 6). 239 It is possible that the port number obtained from the Discovery 240 Service may conflict with the one obtained from the DHCP service. In 241 such a case, the implementor has the option to try both port numbers 242 in the Boot stage. 244 If the iSCSI boot client does not have any targetname information, 245 the iSCSI boot client then may query the Discovery Service with query 246 string 4 of the iSCSI Target Concrete Service Type Template as 247 specified in Section 6.2 of the iSCSI SLP interaction document[24]. 249 Standards-Track iSCSI BootStrapping Draft 26 June 2002 251 In response to this query, the discovery service provides the boot 252 client with a list of iSCSI boot servers the boot client is allowed 253 to access. 255 If the list of iSCSI boot servers is empty, subsequent actions are 256 left to the discretion of the implementor. Otherwise, the iSCSI boot 257 client may contact any iSCSI boot server in the list. Moreover, the 258 order in which iSCSI boot servers are contacted is also left to the 259 discretion of the implementor. 261 6. Boot stage 263 Once the iSCSI boot client has obtained the minimum information to 264 open an iSCSI session with the iSCSI boot server, the actual booting 265 process can start. 267 The actual sequence of iSCSI commands needed to complete the boot 268 process is left to the implementor. This was done because of varying 269 requirements from different vendors and equipments, making it 270 difficult to specify a common subset of the iSCSI standard that would 271 be acceptable to everybody. 273 The iSCSI session established for boot may be taken over by the 274 booted software in the iSCSI boot client. 276 7. Security 278 The security discussion is centered around each stage of the iSCSI 279 boot process. 281 The software stage can be secured by using public key encryption and 282 digitial signatures. This is the approach taken by the popular PXE 283 boot framework. 285 With regards to the DHCP stage, securing the host configuration 286 protocol is beyond the scope of this document. Authentication of DHCP 287 messages is described in [16]. 289 The security issues in the Discovery Service stage are addressed by 290 public key ciphering as stated in the the SLP version 2 document[1]. 292 For the Boot stage, the iSCSI standard supports various methods of 293 authentication and encryption for transport security[12]. The means 294 to configure the security parameters of an iSCSI boot client is 295 beyond the scope of this document. 297 The iSCSI boot service may be subjected to denial of service attacks. 299 Standards-Track iSCSI BootStrapping Draft 26 June 2002 301 The use of IPSEC as mandated by the iSCSI standard[12] can be used to 302 protect against such attacks. However, ARP is still vulnerable to 303 such type of attacks. 305 Security in the Boot stage is also dependent on the verification of 306 the boot image being loaded. One key difference between the iSCSI 307 boot mechanism and BOOTP-based image loading is the fact that the 308 identity of a boot image may not be known when the Boot stage starts. 309 The identity of certain boot images and their locations are known 310 only after examining the contents of a boot disk exposed by the iSCSI 311 boot service. Furthermore, images themselves may recursively load 312 other images based on both hardware configurations and user input. 314 Consequently, a practical way to verify loaded boot images is to make 315 sure that each image loading software verify the image to be loaded 316 using a mechanism of their choice. 318 Another point to be noted is that if a boot image inherits an iSCSI 319 session from a previously loaded boot image, the boot image also 320 inherts the security properties of the iSCSI session. 322 Acknowledgments 324 We wish to thank John Hufferd for taking the initiative to form the 325 iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, 326 Bernard Aboba, David Robinson, Mark Bakke and C. Mallikarjun for 327 helpful suggestions and pointers regarding the draft document. 329 References 331 [1] Guttman, E., Perkins, C., Verizades, J., Day, M., "Service 332 Location Protocol v2", RFC 2608, June 1999. 334 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 335 Extensions", RFC 2132, Lachman Technology, Inc., Bucknell 336 University, October 1993. 338 [3] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 339 Bucknell University, March 1997. 341 [4] Brownell, D, "Dynamic Reverse Address Resolution Protocol 342 (DRARP)", Work in Progress. 344 [5] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 345 Stanford and SUN Microsystems, September 1985. 347 [6] Droms, D., "Interoperation between DHCP and BOOTP" RFC 1534, 348 Bucknell University, October 1993. 350 Standards-Track iSCSI BootStrapping Draft 26 June 2002 352 [7] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse 353 Address Resolution Protocol", RFC 903, Stanford, June 1984. 355 [8] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, 356 USC/Information Sciences Institute, August 1993. 358 [9] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, 359 June 1981. 361 [10] Wimer, W., "Clarifications and Extensions for the Bootstrap 362 Protocol", RFC 1532, Carnegie Mellon University, October 1993. 364 [11] Bradner, S., "The Internet Standards Process -- 365 Revision 3", RFC 2026, October 1996. 367 [12] Satran, J. et al., "iSCSI", Internet-Draft, July 2001. 369 [13] Bound, J., Canney, M., and Perkins, C., "Dynamic Host 370 Configuration 371 Protocol for IPv6", Internet-Draft, June 2001. 373 [14] Bakke, M. et al., "iSCSI Naming and Discovery", Internet-Draft, 374 July 2001. 376 [15] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service 377 Location Protocol", RFC 2165, June 1997. 379 [16] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 380 Internet-Draft, November 2000. 382 [17] http://www.intel.com/labs/manage/wfm/tools/bis 384 [18] Stewart, R., et al. "Stream Control Transmission Protocol", RFC 385 2960, October 2000. 387 [19] Droms, R., "Procedures and IANA Guidelines for Approval of New 388 DHCP Options and Message Types", RFC 2939, September 2000. 390 [20] Yergeau, F., "UTF-8: A Transformation Format for ISO-10646", RFC 391 2279, January 1998. 393 [21] Hinden, R., Deering, S., "IP version 6 Addressing Architecture", 394 RFC 2273, July 1998. 396 [22] Braden, R., "Requirements for Internet Hosts - Application and 397 Support", RFC 1123, October 1989. 399 [23] Mockaopertis, P., "Domain Names - Concepts and Facilities", RFC 401 Standards-Track iSCSI BootStrapping Draft 26 June 2002 403 1034, November 1987. 405 [24] Bakke, M., et al. "Finding iSCSI Targets and Name Servers using 406 SLP", Internet-Draft, July 2001. 408 Author's Addresses 410 Prasenjit Sarkar 411 IBM Almaden Research Center 412 650 Harry Road 413 San Jose, CA 95120, USA 414 Phone: +1 408 927 1417 415 Email: psarkar@almaden.ibm.com 417 Duncan Missimer 418 Hewlett-Packard Company 419 19420 Homestead Road, M/S 43lo 420 Cupertino, CA 95014, USA 421 Phone: +1 408 447 5390 422 Email: duncan_missimer@hp.com 424 Constantine Sapuntzakis 425 Cisco Systems, Inc. 426 170 W. Tasman Drive 427 San Jose, CA 95134, USA 428 Phone: +1 650 520 0205 429 Email: csapuntz@cisco.com 431 Full Copyright Statement 433 "Copyright (C) The Internet Society (date). All Rights Reserved. This 434 document and translations of it may be copied and furnished to 435 others, and derivative works that comment on or otherwise explain it 436 or assist in its implementation may be prepared, copied, published 437 and distributed, in whole or in part, without restriction of any 438 kind, provided that the above copyright notice and this paragraph are 439 included on all such copies and derivative works. However, this 440 document itself may not be modified in any way, such as by removing 441 the copyright notice or references to the Internet Society or other 442 Internet organizations, except as needed for the purpose of 443 developing Internet standards in which case the procedures for 444 copyrights defined in the Internet Standards process must be 445 followed, or as required to translate it into languages other than 446 English. 448 The limited permissions granted above are perpetual and will not be 449 revoked by the Internet Society or its successors or assigns. 451 Standards-Track iSCSI BootStrapping Draft 26 June 2002 453 This document and the information contained herein is provided on an 454 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 455 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 456 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 457 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 458 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."