idnits 2.17.1 draft-ietf-ips-iscsi-boot-03.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 (27 August 2001) is 8275 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 312, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 323, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 326, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 329, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 332, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 335, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 338, 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-03.txt Duncan Missimer 5 Category: Informational HP 6 Constantin Sapuntzakis 7 Cisco 8 27 August 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 27 August 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 27 August 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 "wwwui". 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 27 August 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 "wwui" 157 field is then used in the Discovery Service stage (Section 5). 159 5. Discovery Service stage: 161 This stage is required if the DHCP server (v4 or v6) is unaware of 162 the Service Delivery Port Name of the iSCSI boot server. The 163 implemention of the discovery service is to based on the SLP 164 protocol[1,24]. 166 The iSCSI boot client may have obtained the WWUI of the iSCSI boot 167 server in the DHCP stage (Section 4). In that case, the iSCSI boot 168 client queries the Discovery Service using query string 1 as 169 specified in the iSCSI SLP interaction document[24] to resolve the 170 WWUI to an IP address and port number. One this is obtained, the 171 iSCSI boot client proceeds to the Boot Stage (Section 6). 173 It is possible that the port number obtained from the Discovery 174 Service may conflict with the one obtained from the DHCP service. In 175 such a case, the implementor has the option to try both port numbers 176 in the Boot stage. 178 If the iSCSI boot client does not have any WWUI information, the 179 iSCSI boot client then may query the Discovery Service with query 180 string 4 as specified in the iSCSI SLP interaction document[24]. In 181 response to this query, the discovery service provides the boot 182 client with a list of iSCSI boot servers the boot client is allowed 183 to access. 185 If the list of iSCSI boot servers is empty, subsequent actions are 186 left to the discretion of the implementor. Otherwise, the iSCSI boot 187 client may contact any iSCSI boot server in the list. Moreover, the 188 the order in which iSCSI boot servers are contacted is also left to 189 the discretion of the implementor. 191 6. Boot Stage 193 Once the iSCSI boot client has obtained the minimum information to 194 open an iSCSI session with the iSCSI boot server, the actual booting 195 process can start. 197 The actual sequence of iSCSI commands needed to complete the boot 198 process is left to the implementor. This was done because of varying 199 requirements from different vendors and equipments, making it 201 Standards-Track iSCSI BootStrapping Draft 27 August 2001 203 difficult to specify a common subset of the iSCSI standard that would 204 be acceptable to everybody. 206 However, the use of a discovery session is not recommended because at 207 this stage (i) a boot server has probably been found and (ii) the 208 response obtained from the discovery session does not qualify an 209 iSCSI boot server from an iSCSI target. 211 The iSCSI session established for boot may be taken over the booted 212 software in the iSCSI boot client. 214 7. Security 216 The security discussion is centered around each stage of the iSCSI 217 boot process. 219 The software stage can be secured by using public key encryption and 220 digitial signatures. This is the approach taken by the popular PXE 221 boot framework. 223 With regards to the DHCP stage, securing the host configuration 224 protocol is beyond the scope of this document. Authentication of DHCP 225 messages is described in [16]. 227 The security issues in the Discovery Service stage are addressed by 228 public key ciphering as stated in the the SLP version 2 document[1]. 230 For the Boot stage, the iSCSI standard supports various methods of 231 authenticated login and encrypted and authenticated connections for 232 security[12]. How to configure the security parameters of an iSCSI 233 boot client is beyond the scope of this document. 235 The iSCSI boot service may be subjected to denial of service attacks. 236 The use of IPSEC as mandated by the iSCSI standard[12] can be used to 237 protect against such attacks. However, ARP is still vulnerable to 238 such type of attacks. 240 Security in the Boot stage is also dependent on the verification of 241 the boot image being loaded. One key difference between the iSCSI 242 boot mechanism and BOOTP-based image loading is the fact that the 243 identity of a boot image may not be known when the Boot stage starts. 244 The identity of certain boot images and their locations are known 245 only after examining the contents of a boot disk exposed by the iSCSI 246 boot service. Furthermore, images themselves may recursively load 247 other images based on both hardware configurations and user input. 249 Consequently, a practical way to verify loaded boot images is to make 251 Standards-Track iSCSI BootStrapping Draft 27 August 2001 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 [11] Bradner, S., "The Internet Standards Process -- 302 Standards-Track iSCSI BootStrapping Draft 27 August 2001 304 Revision 3", RFC 2026, October 1996. 306 [12] Satran, J. et al., "iSCSI", Internet-Draft, July 2001. 308 [13] Bound, J., Canney, M., and Perkins, C., "Dynamic Host 309 Configuration 310 Protocol for IPv6", Internet-Draft, June 2001. 312 [14] Bakke, M. et al., "iSCSI Naming and Discovery", Internet-Draft, 313 July 2001. 315 [15] Veizades, J., Guttman, E., Perkins, C., Kaplan, S., "Service 316 Location Protocol", RFC 2165, June 1997. 318 [16] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 319 Internet-Draft, November 2000. 321 [17] http://developer.intel.com/ial/WfM/wfm20/design/pxedt/index.htm 323 [18] Stewart, R., et al. "Stream Control Transmission Protocol", RFC 324 2960, October 2000. 326 [19] Droms, R., "Procedures and IANA Guidelines for Approval of New 327 DHCP Options and Message Types", RFC 2939, September 2000. 329 [20] Yergeau, F., "UTF-8: A Transformation Format for ISO-10646", RFC 330 2279, January 1998. 332 [21] Hinden, R., Deering, S., "IP version 6 Addressing Architecture", 333 RFC 2273, July 1998. 335 [22] Braden, R., "Requirements for Internet Hosts - Application and 336 Support", RFC 1123, October 1989. 338 [23] Mockaopertis, P., "Domain Names - Concepts and Facilities", RFC 339 1034, November 1987. 341 [24] Bakke, M., et al. "Finding iSCSI Targets and Name Servers using 342 SLP", Internet-Draft, July 2001. 344 Author's Addresses 346 Prasenjit Sarkar 347 IBM Almaden Research Center 348 650 Harry Road 349 San Jose, CA 95120, USA 350 Phone: +1 408 927 1417 351 Email: psarkar@almaden.ibm.com 353 Standards-Track iSCSI BootStrapping Draft 27 August 2001 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."