idnits 2.17.1 draft-ietf-ips-iscsi-boot-04.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 7 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 8 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 (20 November 2001) is 8192 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 272, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 288, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 311, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 322, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 325, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 328, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 331, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 334, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 337, 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 (~~), 11 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-04.txt Duncan Missimer 5 Category: Informational HP 6 Constantin Sapuntzakis 7 Cisco 8 20 November 2001 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 20 November 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 20 November 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 a variable length DHCP option 138 field known as the Root Path option. The details of the use of this 139 option for the iSCSI boot process is detailed in [?]. The key fields 140 from the option are "servername", "protocol", "port", "LUN" and 141 "targetname". 143 If the "servername" field is left blank, then no default value is 144 assumed in its place. If the "protocol" field is left bank, the 145 default value is assumed to be "6" for TCP. If the "port" field is 146 not specified, the port defaults to the well-known iSCSI port. If 147 the LUN field is blank, then LUN 0 is assumed. 149 If the "servername" field is provided by DHCP, then that field is 151 Standards-Track iSCSI BootStrapping Draft 20 November 2001 153 used in conjunction with other associated fields to contact the boot 154 server in the Boot stage (Section 6). 156 However, if the "servername" field is not provided, then the 157 "targetname" field is then used in the Discovery Service stage 158 (Section 5). 160 5. Discovery Service stage: 162 This stage is required if the DHCP server (v4 or v6) is unaware of 163 the Service Delivery Port Name of the iSCSI boot server. The 164 implemention of the discovery service is to based on the SLP 165 protocol[1,24]. 167 The iSCSI boot client may have obtained the targetname of the iSCSI 168 boot server in the DHCP stage (Section 4). In that case, the iSCSI 169 boot client queries the Discovery Service using query string 1 as 170 specified in the iSCSI SLP interaction document[24] to resolve the 171 targetname to an IP address and port number. One this is obtained, 172 the iSCSI boot client proceeds to the Boot Stage (Section 6). 174 It is possible that the port number obtained from the Discovery 175 Service may conflict with the one obtained from the DHCP service. In 176 such a case, the implementor has the option to try both port numbers 177 in the Boot stage. 179 If the iSCSI boot client does not have any targetname information, 180 the iSCSI boot client then may query the Discovery Service with query 181 string 4 as specified in the iSCSI SLP interaction document[24]. In 182 response to this query, the discovery service provides the boot 183 client with a list of iSCSI boot servers the boot client is allowed 184 to access. 186 If the list of iSCSI boot servers is empty, subsequent actions are 187 left to the discretion of the implementor. Otherwise, the iSCSI boot 188 client may contact any iSCSI boot server in the list. Moreover, the 189 the order in which iSCSI boot servers are contacted is also left to 190 the discretion of the implementor. 192 6. Boot Stage 194 Once the iSCSI boot client has obtained the minimum information to 195 open an iSCSI session with the iSCSI boot server, the actual booting 196 process can start. 198 The actual sequence of iSCSI commands needed to complete the boot 199 process is left to the implementor. This was done because of varying 201 Standards-Track iSCSI BootStrapping Draft 20 November 2001 203 requirements from different vendors and equipments, making it 204 difficult to specify a common subset of the iSCSI standard that would 205 be acceptable to everybody. 207 However, the use of a discovery session is not recommended because at 208 this stage (i) a boot server has probably been found and (ii) the 209 response obtained from the discovery session does not qualify an 210 iSCSI boot server from an iSCSI target. 212 The iSCSI session established for boot may be taken over the booted 213 software in the iSCSI boot client. 215 7. Security 217 The security discussion is centered around each stage of the iSCSI 218 boot process. 220 The software stage can be secured by using public key encryption and 221 digitial signatures. This is the approach taken by the popular PXE 222 boot framework. 224 With regards to the DHCP stage, securing the host configuration 225 protocol is beyond the scope of this document. Authentication of DHCP 226 messages is described in [16]. 228 The security issues in the Discovery Service stage are addressed by 229 public key ciphering as stated in the the SLP version 2 document[1]. 231 For the Boot stage, the iSCSI standard supports various methods of 232 authenticated login and encrypted and authenticated connections for 233 security[12]. How to configure the security parameters of an iSCSI 234 boot client is beyond the scope of this document. 236 The iSCSI boot service may be subjected to denial of service attacks. 237 The use of IPSEC as mandated by the iSCSI standard[12] can be used to 238 protect against such attacks. However, ARP is still vulnerable to 239 such type of attacks. 241 Security in the Boot stage is also dependent on the verification of 242 the boot image being loaded. One key difference between the iSCSI 243 boot mechanism and BOOTP-based image loading is the fact that the 244 identity of a boot image may not be known when the Boot stage starts. 245 The identity of certain boot images and their locations are known 246 only after examining the contents of a boot disk exposed by the iSCSI 247 boot service. Furthermore, images themselves may recursively load 248 other images based on both hardware configurations and user input. 250 Standards-Track iSCSI BootStrapping Draft 20 November 2001 252 Consequently, a practical way to verify loaded boot images is to make 253 sure that each image loading software verify the image to be loaded 254 using a mechanism of their choice. 256 Another point to be noted is that if a boot image inherits an iSCSI 257 session from a previously loaded boot image, the boot image also 258 inherts the security properties of the iSCSI session. 260 Acknowledgments 262 We wish to thank John Hufferd for taking the initiative to form the 263 iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, 264 Bernard Aboba, David Robinson and Mark Bakke for helpful suggestions 265 and pointers regarding the draft document. 267 References 269 [1] Guttman, E., Perkins, C., Verizades, J., Day, M., "Service 270 Location Protocol v2", RFC 2608, June 1999. 272 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor 273 Extensions", RFC 2132, Lachman Technology, Inc., Bucknell 274 University, October 1993. 276 [3] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 277 Bucknell University, March 1997. 279 [4] Brownell, D, "Dynamic Reverse Address Resolution Protocol 280 (DRARP)", Work in Progress. 282 [5] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 283 Stanford and SUN Microsystems, September 1985. 285 [6] Droms, D., "Interoperation between DHCP and BOOTP" RFC 1534, 286 Bucknell University, October 1993. 288 [7] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse 289 Address Resolution Protocol", RFC 903, Stanford, June 1984. 291 [8] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, 292 USC/Information Sciences Institute, August 1993. 294 [9] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC, 295 June 1981. 297 [10] Wimer, W., "Clarifications and Extensions for the Bootstrap 298 Protocol", RFC 1532, Carnegie Mellon University, October 1993. 300 Standards-Track iSCSI BootStrapping Draft 20 November 2001 302 [11] Bradner, S., "The Internet Standards Process -- 303 Revision 3", RFC 2026, October 1996. 305 [12] Satran, J. et al., "iSCSI", Internet-Draft, July 2001. 307 [13] Bound, J., Canney, M., and Perkins, C., "Dynamic Host 308 Configuration 309 Protocol for IPv6", Internet-Draft, June 2001. 311 [14] Bakke, M. et al., "iSCSI Naming and Discovery", Internet-Draft, 312 July 2001. 314 [15] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service 315 Location Protocol", RFC 2165, June 1997. 317 [16] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 318 Internet-Draft, November 2000. 320 [17] http://developer.intel.com/ial/WfM/wfm20/design/pxedt/index.htm 322 [18] Stewart, R., et al. "Stream Control Transmission Protocol", RFC 323 2960, October 2000. 325 [19] Droms, R., "Procedures and IANA Guidelines for Approval of New 326 DHCP Options and Message Types", RFC 2939, September 2000. 328 [20] Yergeau, F., "UTF-8: A Transformation Format for ISO-10646", RFC 329 2279, January 1998. 331 [21] Hinden, R., Deering, S., "IP version 6 Addressing Architecture", 332 RFC 2273, July 1998. 334 [22] Braden, R., "Requirements for Internet Hosts - Application and 335 Support", RFC 1123, October 1989. 337 [23] Mockaopertis, P., "Domain Names - Concepts and Facilities", RFC 338 1034, November 1987. 340 [24] Bakke, M., et al. "Finding iSCSI Targets and Name Servers using 341 SLP", Internet-Draft, July 2001. 343 Author's Addresses 345 Prasenjit Sarkar 346 IBM Almaden Research Center 347 650 Harry Road 348 San Jose, CA 95120, USA 349 Phone: +1 408 927 1417 351 Standards-Track iSCSI BootStrapping Draft 20 November 2001 353 Email: psarkar@almaden.ibm.com 355 Duncan Missimer 356 Hewlett-Packard Company 357 19420 Homestead Road, M/S 43lo 358 Cupertino, CA 95014, USA 359 Phone: +1 408 447 5390 360 Email: duncan_missimer@hp.com 362 Constantine Sapuntzakis 363 Cisco Systems, Inc. 364 170 W. Tasman Drive 365 San Jose, CA 95134, USA 366 Phone: +1 650 520 0205 367 Email: csapuntz@cisco.com 369 Full Copyright Statement 371 "Copyright (C) The Internet Society (date). All Rights Reserved. This 372 document and translations of it may be copied and furnished to 373 others, and derivative works that comment on or otherwise explain it 374 or assist in its implementation may be prepared, copied, published 375 and distributed, in whole or in part, without restriction of any 376 kind, provided that the above copyright notice and this paragraph are 377 included on all such copies and derivative works. However, this 378 document itself may not be modified in any way, such as by removing 379 the copyright notice or references to the Internet Society or other 380 Internet organizations, except as needed for the purpose of 381 developing Internet standards in which case the procedures for 382 copyrights defined in the Internet Standards process must be 383 followed, or as required to translate it into languages other than 384 English. 386 The limited permissions granted above are perpetual and will not be 387 revoked by the Internet Society or its successors or assigns. 389 This document and the information contained herein is provided on an 390 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 391 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 392 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 393 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 394 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."