idnits 2.17.1 draft-ietf-dhc-isnsoption-10.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope is the entire iSNS database. If' ) ** The document seems to lack a Security Considerations 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.) ** There are 180 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (September 2003) is 7529 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) -- Missing reference section? 'RFC2026' on line 505 looks like a reference -- Missing reference section? 'RFC2119' on line 508 looks like a reference -- Missing reference section? 'ISNS' on line 482 looks like a reference -- Missing reference section? 'RFC3118' on line 511 looks like a reference -- Missing reference section? 'DHCP' on line 498 looks like a reference -- Missing reference section? 'SEC-IPS' on line 523 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 0 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Charles Monia 3 INTERNET DRAFT Josh Tseng 4 Expires: March 2004 Kevin Gibbons 5 Internet Draft 6 Document: Nishan Systems 7 Category: Standards Track September 2003 9 The IPv4 DHCP Option for the Internet Storage Name Service 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or made obsolete by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Comments 33 Comments should be sent to the DHCP mailing list (dhcwg@ietf.org) or 34 to the authors. 36 Table of Contents 38 DHCP Option Number for iSNS Revision 10 September 2003 40 Status of this Memo...................................................1 41 Comments..............................................................1 42 Abstract..............................................................3 43 Conventions used in this document.....................................3 44 1. Introduction.....................................................3 45 2. iSNS Option for DHCP.............................................4 46 2.1 iSNS Functions Field.............................................5 47 2.2 Discovery Domain Access Field....................................7 48 2.3 Administrative Flags Field.......................................8 49 2.4 iSNS Server Security Bitmap......................................9 50 3. Security Considerations.........................................10 51 4. IANA Considerations.............................................11 52 5. Normative References............................................11 53 6. Non-Normative References........................................11 54 7. Author's Addresses..............................................12 55 Full Copyright Statement.............................................13 56 DHCP Option Number for iSNS Revision 10 September 2003 58 Abstract 60 This document describes the DHCP option to allow Internet Storage 61 Name Service (iSNS) clients to automatically discover the location 62 of the iSNS server through the use of DHCP for IPv4. iSNS provides 63 discovery and management capabilities for Internet SCSI (iSCSI) and 64 Internet Fibre Channel Protocol (iFCP) storage devices in an 65 enterprise-scale IP storage network. iSNS provides intelligent 66 storage management services comparable to those found in Fibre 67 Channel networks, allowing a commodity IP network to function in a 68 similar capacity as a storage area network. 70 Conventions used in this document 72 iSNS refers to the Internet Storage Name Service framework 73 consisting of the storage network model and associated services. 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 77 this document are to be interpreted as described in [RFC2119]. 79 All frame formats are in big endian network byte order. RESERVED 80 fields SHOULD be set to zero. 82 This document uses the following terms: 84 "iSNS Client" - iSNS clients are processes resident in iSCSI and 85 iFCP devices that initiate transactions with the iSNS server using 86 the iSNS Protocol. 88 "iSNS Server" - The iSNS server responds to iSNS protocol query and 89 registration messages, and initiates asynchronous notification 90 messages. The iSNS server stores information registered by iSNS 91 clients. 93 "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a 94 new generation of storage devices interconnected with TCP/IP. 96 "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- 97 gateway protocol designed to interconnect existing Fibre Channel 98 devices using TCP/IP. iFCP maps the Fibre Channel transport and 99 fabric services to TCP/IP. 101 1. Introduction 103 The Dynamic Host Configuration Protocol for IPv4 provides a 104 framework for passing configuration information to hosts. Its 105 usefulness extends to hosts and devices using the iSCSI and iFCP 106 protocols to connect to block level storage assets over a TCP/IP 107 network. 109 The iSNS Protocol provides a framework for automated discovery, 110 management, and configuration of iSCSI and iFCP devices on a TCP/IP 111 network. It provides functionality similar to that found on Fibre 113 DHCP Option Number for iSNS Revision 10 September 2003 115 Channel networks, except that iSNS works within the context of an IP 116 network. iSNS thereby provides the requisite storage intelligence 117 to IP networks that are standard on existing Fibre Channel networks. 119 Existing DHCP options cannot be used to find iSNS servers for the 120 following reasons: 122 a) iSNS functionality is distinctly different from other protocols 123 using DHCP options. Specifically, iSNS provides a significant 124 superset of capabilities compared to typical name resolution 125 protocols such as DNS. It is designed to support client devices 126 that allow themselves to be configured and managed from a 127 central iSNS server 129 b) iSNS requires a DHCP option format that provides more than the 130 location of the iSNS server. The DHCP option needs to specify 131 the subset of iSNS services that may be actively used by the 132 iSNS client. 134 The DHCP option number for iSNS is used by iSCSI and iFCP devices to 135 discover the location and role of the iSNS server. The DHCP option 136 number assigned for iSNS by IANA is <>. 138 2. iSNS Option for DHCP 140 This option specifies the location of the primary and backup iSNS 141 servers and the iSNS services available to an iSNS client. 143 0 1 2 3 144 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Code = TBD | Length | iSNS Functions | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | DD Access | Administrative FLAGS | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | iSNS Server Security Bitmap | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | a1 | a2 | a3 | a4 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | b1 | b2 | b3 | b4 | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | . . . . | 157 | Additional Secondary iSNS Servers | 158 | . . . . | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1 -- iSNS Server Option 162 The iSNS Option specifies a list of IP addresses used by iSNS 163 servers. The option contains the following parameters: 165 Length: the number of bytes that follow the Length field. 167 DHCP Option Number for iSNS Revision 10 September 2003 169 iSNS Functions: A bitmapped field defining the functions supported 170 by the iSNS servers. The format of this field is described 171 in section 2.1. 173 Discovery Domain Access: A bit field indicating the types of iSNS 174 clients that are allowed to modify Discovery Domains. The 175 field contents are described in section 2.2. 177 Administrative Flags field: Contains the administrative settings for 178 the iSNS servers discovered through the DHCP query. The 179 contents of this field are described in section 2.3. 181 iSNS Server Security Bitmap: Contains the iSNS server security 182 settings specified in section 2.4. 184 a1...a4: Depending on the setting of the Heartbeat bit in the 185 Administrative Flags field (see section 2.3), this field 186 contains either the IP address from which the iSNS heartbeat 187 originates (see [ISNS]) or the IP address of the primary 188 iSNS server. 190 b1...b4: Depending on the setting of Heartbeat bit in the 191 Administrative Flags field (see section 2.3), this field 192 contains either the IP address of the primary iSNS server or 193 a secondary iSNS server. 195 Additional Secondary iSNS Servers: Each set of four octets specifies 196 the IP address of a secondary iSNS server. 198 The Code field through IP address field a1...a4 MUST be present in 199 every response to the iSNS query, hence the Length field has a 200 minimum value of 14. 202 If the Heartbeat bit is set in the Administrative Flags field (see 203 section 2.3), then b1...b4 MUST also be present. In this case, the 204 minimum value of the Length field is 18. 206 The inclusion of Additional Secondary iSNS Servers in the response 207 MUST be indicated by increasing the Length field accordingly. 209 2.1 iSNS Functions Field 211 The iSNS Functions Field defines the iSNS server's operational role 212 (i.e., how the iSNS server is to be used). The iSNS server's role 213 can be as basic as providing simple discovery information, or as 214 significant as providing IKE/IPSec security policies and 215 certificates for the use of iSCSI and iFCP devices. The format of 216 the iSNS Functions field is shown in Figure 2: 218 DHCP Option Number for iSNS Revision 10 September 2003 220 0 1 1 221 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Reserved |S|A|E| 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 2 -- iSNS Functions Field 227 Bit field Significance 228 --------- ------------ 229 15 Function Fields Enabled 230 14 DD-Based Authorization 231 13 Security Policy Distribution 233 iSNS Functions Field definitions: 235 Function Fields This bit specifies the validity of the 236 Enabled: remaining iSNS Function fields. If set to 237 one, then the contents of all other iSNS 238 Function fields are valid. If set to zero, 239 then the contents of all other iSNS 240 Function fields MUST be ignored. 242 DD-based Indicates whether or not devices in a 243 Authorization: common Discovery Domain (DD) are implicitly 244 authorized to access one another. Although 245 Discovery Domains control the scope of 246 device discovery, they do not necessarily 247 indicate whether or not a domain member is 248 authorized to access discovered devices. 249 If this bit is set to one, then devices in 250 a common Discovery Domain are automatically 251 allowed access to each other (if 252 successfully authenticated). If this bit 253 is set to zero, then access authorization 254 is not implied by domain membership and 255 must be explicitly performed by each 256 device. In either case, devices not in a 257 common discovery domain are not allowed to 258 access each other. 260 Security Policy Indicates whether the iSNS client is to 261 Distribution: download and use the security policy 262 configuration stored in the iSNS server. 263 If set to one, then the policy is stored in 264 the iSNS server and must be used by the 265 iSNS client for its own security policy. 266 If set to zero, then the iSNS client must 267 obtain its security policy configuration by 268 other means. 270 DHCP Option Number for iSNS Revision 10 September 2003 272 2.2 Discovery Domain Access Field 274 The format of the DD Access bit field is shown in Figure 3: 276 0 1 277 0 1 2 3 4 5 6 ... 5 278 +---+---+---+---+---+---+---+---+---+ 279 | if| tf| is| ts| C | E | Reserved | 280 +---+---+---+---+---+---+---+---+---+ 281 Figure 3 -- Discovery Domain Access Field 283 Bit field Significance 284 --------- ------------ 285 5 Enabled 286 4 Control Node 287 3 iSCSI Target 288 2 iSCSI Initiator 289 1 iFCP Target Port 290 0 iFCP Initiator Port 292 Discovery Domain Access Field Definitions: 294 Enabled: This bit specifies the validity of the 295 remaining DD Access bit fields. If this 296 bit is set to one, then the contents of 297 the remainder of the DD Access field are 298 valid. If this bit is set to zero, then 299 the contents of the remainder of this 300 field MUST be ignored. 302 Control Node: Specifies whether the iSNS server allows 303 Discovery Domains to be added, modified 304 or deleted by means of Control Nodes. If 305 set to one, then Control Nodes are 306 allowed to modify the Discovery Domain 307 configuration. If set to zero, then 308 Control Nodes are not allowed to modify 309 Discovery Domain configurations. 311 iSCSI Target, These bits determine whether the 312 iSCSI Initiator, respective registered iSNS client 313 iFCP Target Port, (determined by iSCSI Node Type or iFCP 314 iFCP Initiator Port Role) is allowed to add, delete, or 315 Port: modify Discovery Domains. If set to 316 one, then modification by the specified 317 client type is allowed. If set to zero, 318 then modification by the specified 319 client type is not allowed. 321 (A node may implement multiple node 322 types.) 324 DHCP Option Number for iSNS Revision 10 September 2003 326 2.3 Administrative Flags Field 328 The format of the Administrative Flags bit field is shown in 329 Figure 4: 331 0 1 1 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | RESERVED |D|M|H|E| 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 4 -- Administrative Flags 338 Bit Field Significance 339 --------- ------------ 340 15 Enabled 341 14 Heartbeat 342 13 Management SCNs 343 12 Default Discovery Domain 345 Administrative Flags Field definitions: 347 Enabled: Specifies the validity of the remainder 348 of the Administrative Flags field. If 349 set to one, then the contents of the 350 remaining Administrative Flags are 351 valid. If set to zero, then the 352 remaining contents MUST be ignored, 353 indicating that iSNS administrative 354 settings are obtained through means 355 other than DHCP. 357 Heartbeat: Indicates whether the first IP address 358 is the multicast address to which the 359 iSNS heartbeat message is sent. If set 360 to one, then a1-a4 contains the 361 heartbeat multicast address and b1-b4 362 contains the IP address of the primary 363 iSNS server, followed by the IP 364 address(es) of any backup servers (see 365 Figure 1). If set to zero, then a1-a4 366 contains the IP address of the primary 367 iSNS server, followed by the IP 368 address(es) of any backup servers. 370 Management SCNs: Indicates whether control nodes are 371 authorized to register to receive 372 Management State Change Notifications 373 (SCN's). Management SCN's are a special 374 class of State Change Notification whose 375 scope is the entire iSNS database. If 376 set to one, then control nodes are 377 authorized to register to receive 378 Management SCN's. If set to zero, then 380 DHCP Option Number for iSNS Revision 10 September 2003 382 control nodes are not authorized to 383 receive Management SCN's (although they 384 may receive normal SCN's). 386 Default Discovery Indicates whether a newly registered 387 Domain: device that is not explicitly placed 388 into a Discovery Domain (DD) and 389 Discovery Domain Set (DDS) should be 390 automatically placed into a default DD 391 and DDS. If set to one, then a default 392 DD shall contain all devices in the iSNS 393 database that have not been explicitly 394 placed into a DD by an iSNS client. If 395 set to zero, then devices not explicitly 396 placed into a DD are not members of any 397 DD. 399 2.4 iSNS Server Security Bitmap 401 The format of the iSNS server security Bitmap field is shown in 402 Figure 5. If valid, this field communicates to the DHCP client the 403 security settings that are required to communicate with the 404 indicated iSNS server. 406 0 1 2 3 407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Reserved |T|X|P|A|M|S|E| 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 5 -- iSNS Server Security Bitmap 413 Bit Field Significance 414 --------- ---------------- 415 31 Enabled 416 30 IKE/IPSec 417 29 Main Mode 418 28 Aggressive Mode 419 27 PFS 420 26 Transport Mode 421 25 Tunnel Mode 423 iSNS Server Security Bitmap definitions: 425 DHCP Option Number for iSNS Revision 10 September 2003 427 Enabled This bit specifies the validity of the 428 remainder of the iSNS server security 429 bitmap. If set to one, then the contents 430 of the remainder of the field are valid. 431 If set to zero, then the contents of the 432 rest of the field are undefined and MUST 433 be ignored. 435 IKE/IPSec 1 = IKE/IPSec enabled; 0 = IKE/IPSec 436 disabled. 438 Main Mode 1 = Main Mode enabled; 0 = Main Mode 439 disabled. 441 Aggressive Mode 1 = Aggressive mode enabled; 0 = 442 Aggressive mode disabled. 444 PFS 1 = PFS enabled; 0 = PFS disabled. 446 Transport Mode 1 = Transport mode preferred; 0 = No 447 preference. 449 Tunnel Mode 1 = Tunnel mode preferred; 0 = No 450 preference. 452 If IKE/IPSec is disabled, this indicates that the Internet Key 453 Exchange (IKE) Protocol is not available to configure IPSec keys for 454 iSNS sessions to this iSNS server. It does not necessarily preclude 455 other key exchange methods (e.g., manual keying) from establishing 456 an IPSec security association for the iSNS session. 458 If IKE/IPsec is enabled, an implementation SHALL enable: 460 a) One of Main Mode or Aggressive Mode but not both and 462 b) One of Transport Mode or Tunnel Mode but not both. 464 3. Security Considerations 466 DHCP security considerations are addressed in [RFC3118]. Among 467 these is the potential for a "man-in-the-middle" attack by a hostile 468 entity modifying or replacing the original iSNS option message. 469 Unless some form of authentication is implemented, an attacker may 470 trick the iSNS client into connecting into rogue iSNS servers. 472 To thwart such attacks, the DHCP response should be verified in some 473 manner. One approach is direct authentication via [RFC3118], when 474 implemented. Since this technology is not widely deployed, an 475 alternative is to authenticate the discovered iSNS server through 476 use of IPSec or the iSNS authentication block as described in 477 [ISNS]. Of course, use of iSNS Server authentication implies a site 479 DHCP Option Number for iSNS Revision 10 September 2003 481 wide policy requiring use of one of the authentication methods 482 specified in [ISNS] by all iSNS servers. 484 If no authentication is used and it is determined that the potential 485 exists for one of the attacks described in [RFC3118], then the DHCP 486 option message for iSNS should not be utilized. 488 4. IANA Considerations 490 In accordance with the policy defined in [DHCP], IANA has assigned a 491 value of TBD for this option. 493 There are no other IANA-assigned values defined by this 494 specification. 496 5. Normative References 498 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 499 2131, Bucknell University, March 1997. 501 [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name 502 Service", Internet draft (work in progress), draft-ietf- 503 ips-isns-12.txt, August 2002 505 [RFC2026] Bradner, S., "The Internet Standards Process -- 506 Revision 3", BCP 9, RFC 2026, October 1996 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, March 1997 511 [RFC3118] Arbaugh, W., Droms, R., "Authentication for DHCP 512 Messages", RFC 3118, June 2001 514 6. Non-Normative References 516 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 517 Channel Storage Networking", Internet draft (work in 518 progress), draft-ietf-ips-ifcp-13.txt, May 2002 520 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 521 progress), draft-ietf-ips-iSCSI-15.txt, August 2002 523 [SEC-IPS] Aboba, B., et al., "Securing IP Block Storage 524 Protocols", draft-ietf-ips-security-14.txt, June 2002 525 Internet Storage Name Service (iSNS) November 2001 527 7. Author's Addresses 529 Kevin Gibbons, 530 Charles Monia, 531 Josh Tseng 533 Nishan Systems 534 3850 North First Street 535 San Jose, CA 95134-1702 536 Phone: (408) 519-3700 537 Email: cmonia@nishansystems.com 538 jtseng@nishansystems.com 539 kgibbons@nishansystems.com 541 Full Copyright Statement 543 "Copyright (C) The Internet Society September 2003. All Rights 544 Reserved. This document and translations of it may be copied and 545 furnished to others, and derivative works that comment on or 546 otherwise explain it or assist in its implementation may be 547 prepared, copied, published and distributed, in whole or in part, 548 without restriction of any kind, provided that the above copyright 549 notice and this paragraph are included on all such copies and 550 derivative works. However, this document itself may not be modified 551 in any way, such as by removing the copyright notice or references 552 to the Internet Society or other Internet organizations, except as 553 needed for the purpose of developing Internet standards in which 554 case the procedures for copyrights defined in the Internet Standards 555 process must be followed, or as required to translate it into 556 languages other than English. 558 The limited permissions granted above are perpetual and will not be 559 revoked by the Internet Society or its successors or assigns. 561 This document and the information contained herein is provided on an 562 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 563 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 564 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 565 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 566 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."