idnits 2.17.1 draft-ietf-dhc-isnsoption-08.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 166 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 (July 2003) is 7590 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 463 looks like a reference -- Missing reference section? 'RFC2119' on line 466 looks like a reference -- Missing reference section? 'ISNS' on line 178 looks like a reference -- Missing reference section? 'RFC3118' on line 469 looks like a reference -- Missing reference section? 'SEC-IPS' on line 485 looks like a reference -- Missing reference section? 'DHCP' on line 460 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: January 2004 Kevin Gibbons 5 Internet Draft 6 Document: Nishan Systems 7 Category: Standards Track July 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 Status of this Memo...................................................1 39 Comments..............................................................1 40 Abstract..............................................................3 41 Conventions used in this document.....................................3 42 1.Introduction.......................................................3 43 2.iSNS Option for DHCP...............................................4 44 2.1 iSNS Functions Field.............................................5 45 2.2 Discovery Domain Access Field....................................7 46 2.3 Administrative Flags Field.......................................8 47 2.4 iSNS Server Security Bitmap......................................9 48 3.Security Considerations...........................................10 49 4.IANA Considerations...............................................10 50 5.Normative References..............................................10 51 6.Non-Normative References..........................................11 52 7.Author's Addresses................................................11 53 Full Copyright Statement.............................................12 54 Abstract 56 This document describes the DHCP option to allow Internet Storage 57 Name Service (iSNS) clients to automatically discover the location 58 of the iSNS server through the use of DHCP for IPv4. iSNS provides 59 discovery and management capabilities for Internet SCSI (iSCSI) and 60 Internet Fibre Channel Protocol (iFCP) storage devices in an 61 enterprise-scale IP storage network. iSNS provides intelligent 62 storage management services comparable to those found in Fibre 63 Channel networks, allowing a commodity IP network to function in a 64 similar capacity as a storage area network. 66 Conventions used in this document 68 iSNS refers to the Internet Storage Name Service framework 69 consisting of the storage network model and associated services. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 73 this document are to be interpreted as described in [RFC2119]. 75 All frame formats are in big endian network byte order. RESERVED 76 fields SHOULD be set to zero. 78 This document uses the following terms: 80 "iSNS Client" - iSNS clients are processes resident in iSCSI and 81 iFCP devices that initiate transactions with the iSNS server using 82 the iSNS Protocol. 84 "iSNS Server" - The iSNS server responds to iSNS protocol query and 85 registration messages, and initiates asynchronous notification 86 messages. The iSNS server stores information registered by iSNS 87 clients. 89 "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a 90 new generation of storage devices interconnected with TCP/IP. 92 "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- 93 gateway protocol designed to interconnect existing Fibre Channel 94 devices using TCP/IP. iFCP maps the Fibre Channel transport and 95 fabric services to TCP/IP. 97 1. Introduction 99 The Dynamic Host Configuration Protocol for IPv4 provides a 100 framework for passing configuration information to hosts. Its 101 usefulness extends to hosts and devices using the iSCSI and iFCP 102 protocols to connect to block level storage assets over a TCP/IP 103 network. 105 The iSNS Protocol provides a framework for automated discovery, 106 management, and configuration of iSCSI and iFCP devices on a TCP/IP 107 network. It provides functionality similar to that found on Fibre 108 Channel networks, except that iSNS works within the context of an IP 109 network. iSNS thereby provides the requisite storage intelligence 110 to IP networks that are standard on existing Fibre Channel networks. 112 Existing DHCP options cannot be used to find iSNS servers for the 113 following reasons: 115 a) iSNS functionality is distinctly different from other protocols 116 using DHCP options. Specifically, iSNS provides a significant 117 superset of capabilities compared to typical name resolution 118 protocols such as DNS. It is designed to support client devices 119 that allow themselves to be configured and managed from a 120 central iSNS server 122 b) iSNS requires a DHCP option format that provides more than the 123 location of the iSNS server. The DHCP option needs to specify 124 the subset of iSNS services that may be actively used by the 125 iSNS client. 127 The DHCP option number for iSNS is used by iSCSI and iFCP devices to 128 discover the location and role of the iSNS server. The DHCP option 129 number assigned for iSNS by IANA is <>. 131 2. iSNS Option for DHCP 133 This option specifies the location of the primary and backup iSNS 134 servers and the iSNS services available to an iSNS client. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Code = TBD | Length | iSNS Functions | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | DD Access | Administrative FLAGS | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | iSNS Server Security Bitmap | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | a1 | a2 | a3 | a4 | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | b1 | b2 | b3 | b4 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | . . . . | 150 | Additional Secondary iSNS Servers | 151 | . . . . | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 1 -- iSNS Server Option 155 The iSNS Option specifies a list of IP addresses used by iSNS 156 servers. The option contains the following parameters: 158 Length: the number of bytes that follow the Length field. 160 iSNS Functions: A bitmapped field defining the functions supported 161 by the iSNS servers. The format of this field is described 162 in section 2.1. 164 Discovery Domain Access: A bit field indicating the types of iSNS 165 clients that are allowed to modify Discovery Domains. The 166 field contents are described in section 2.2. 168 Administrative Flags field: Contains the administrative settings for 169 the iSNS servers discovered through the DHCP query. The 170 contents of this field are described in section 2.3. 172 iSNS Server Security Bitmap: Contains the iSNS server security 173 settings specified in section 2.4. 175 a1...a4: Depending on the setting of the Heartbeat bit in the 176 Administrative Flags field (see section 2.3), this field 177 contains either the IP address from which the iSNS heartbeat 178 originates (see [ISNS]) or the IP address of the primary 179 iSNS server. 181 b1...b4: Depending on the setting of Heartbeat bit in the 182 Administrative Flags field (see section 2.3), this field 183 contains either the IP address of the primary iSNS server or 184 a secondary iSNS server. 186 Additional Secondary iSNS Servers: Each set of four octets specifies 187 the IP address of a secondary iSNS server. 189 The Code field through IP address field a1...a4 MUST be present in 190 every response to the iSNS query, hence the Length field has a 191 minimum value of 14. 193 If the Heartbeat bit is set in the Administrative Flags field (see 194 section 2.3), then b1...b4 MUST also be present. In this case, the 195 minimum value of the Length field is 18. 197 The inclusion of Additional Secondary iSNS Servers in the response 198 MUST be indicated by increasing the Length field accordingly. 200 2.1 iSNS Functions Field 202 The iSNS Functions Field defines the iSNS server's operational role 203 (i.e., how the iSNS server is to be used). The iSNS server's role 204 can be as basic as providing simple discovery information, or as 205 significant as providing IKE/IPSec security policies and 206 certificates for the use of iSCSI and iFCP devices. The format of 207 the iSNS Functions field is shown in Figure 2: 209 0 1 1 210 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Reserved |S|A|E| 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 2 -- iSNS Functions Field 216 Bit field Significance 217 --------- ------------ 218 15 Function Fields Enabled 219 14 DD-Based Authorization 220 13 Security Policy Distribution 222 iSNS Functions Field definitions: 224 Function Fields This bit specifies the validity of the 225 Enabled: remaining iSNS Function fields. If set to 226 one, then the contents of all other iSNS 227 Function fields are valid. If set to zero, 228 then the contents of all other iSNS 229 Function fields MUST be ignored. 231 DD-based Indicates whether or not devices in a 232 Authorization: common Discovery Domain (DD) are implicitly 233 authorized to access one another. Although 234 Discovery Domains control the scope of 235 device discovery, they do not necessarily 236 indicate whether or not a domain member is 237 authorized to access discovered devices. 238 If this bit is set to one, then devices in 239 a common Discovery Domain are automatically 240 allowed access to each other (if 241 successfully authenticated). If this bit 242 is set to zero, then access authorization 243 is not implied by domain membership and 244 must be explicitly performed by each 245 device. In either case, devices not in a 246 common discovery domain are not allowed to 247 access each other. 249 Security Policy Indicates whether the iSNS client is to 250 Distribution: download and use the security policy 251 configuration stored in the iSNS server. 252 If set to one, then the policy is stored in 253 the iSNS server and must be used by the 254 iSNS client for its own security policy. 255 If set to zero, then the iSNS client must 256 obtain its security policy configuration by 257 other means. 259 2.2 Discovery Domain Access Field 261 The format of the DD Access bit field is shown in Figure 3: 263 0 1 264 0 1 2 3 4 5 6 ... 5 265 +---+---+---+---+---+---+---+---+---+ 266 | if| tf| is| ts| C | E | Reserved | 267 +---+---+---+---+---+---+---+---+---+ 268 Figure 3 -- Discovery Domain Access Field 270 Bit field Significance 271 --------- ------------ 272 5 Enabled 273 4 Control Node 274 3 iSCSI Target 275 2 iSCSI Initiator 276 1 iFCP Target Port 277 0 iFCP Initiator Port 279 Discovery Domain Access Field Definitions: 281 Enabled: This bit specifies the validity of the 282 remaining DD Access bit fields. If this 283 bit is set to one, then the contents of 284 the remainder of the DD Access field are 285 valid. If this bit is set to zero, then 286 the contents of the remainder of this 287 field MUST be ignored. 289 Control Node: Specifies whether the iSNS server allows 290 Discovery Domains to be added, modified 291 or deleted by means of Control Nodes. If 292 set to one, then Control Nodes are 293 allowed to modify the Discovery Domain 294 configuration. If set to zero, then 295 Control Nodes are not allowed to modify 296 Discovery Domain configurations. 298 iSCSI Target, These bits determine whether the 299 iSCSI Initiator, respective registered iSNS client 300 iFCP Target Port, (determined by iSCSI Node Type or iFCP 301 iFCP Initiator Port Role) is allowed to add, delete, or 302 Port: modify Discovery Domains. If set to 303 one, then modification by the specified 304 client type is allowed. If set to zero, 305 then modification by the specified 306 client type is not allowed. 308 (A node may implement multiple node 309 types.) 311 2.3 Administrative Flags Field 313 The format of the Administrative Flags bit field is shown in 314 Figure 4: 316 0 1 1 317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | RESERVED |D|M|H|E| 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 4 -- Administrative Flags 323 Bit Field Significance 324 --------- ------------ 325 15 Enabled 326 14 Heartbeat 327 13 Management SCNs 328 12 Default Discovery Domain 330 Administrative Flags Field definitions: 332 Enabled: Specifies the validity of the remainder 333 of the Administrative Flags field. If 334 set to one, then the contents of the 335 remaining Administrative Flags are 336 valid. If set to zero, then the 337 remaining contents MUST be ignored, 338 indicating that iSNS administrative 339 settings are obtained through means 340 other than DHCP. 342 Heartbeat: Indicates whether the first IP address 343 is the multicast address to which the 344 iSNS heartbeat message is sent. If set 345 to one, then a1-a4 contains the 346 heartbeat multicast address and b1-b4 347 contains the IP address of the primary 348 iSNS server, followed by the IP 349 address(es) of any backup servers (see 350 Figure 1). If set to zero, then a1-a4 351 contains the IP address of the primary 352 iSNS server, followed by the IP 353 address(es) of any backup servers. 355 Management SCNs: Indicates whether control nodes are 356 authorized to register to receive 357 Management State Change Notifications 358 (SCN's). Management SCN's are a special 359 class of State Change Notification whose 360 scope is the entire iSNS database. If 361 set to one, then control nodes are 362 authorized to register to receive 363 Management SCN's. If set to zero, then 364 control nodes are not authorized to 365 receive Management SCN's (although they 366 may receive normal SCN's). 368 Default Discovery Indicates whether a newly registered 369 Domain: device that is not explicitly placed 370 into a Discovery Domain (DD) and 371 Discovery Domain Set (DDS) should be 372 automatically placed into a default DD 373 and DDS. If set to one, then a default 374 DD shall contain all devices in the iSNS 375 database that have not been explicitly 376 placed into a DD by an iSNS client. If 377 set to zero, then devices not explicitly 378 placed into a DD are not members of any 379 DD. 381 2.4 iSNS Server Security Bitmap 383 The format of the iSNS server security Bitmap field is shown in 384 Figure 5. If valid, this field communicates to the DHCP client the 385 security settings that are required to communicate with the 386 indicated iSNS server. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Reserved |T|X|P|A|M|S|E| 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 5 -- iSNS Server Security Bitmap 395 Bit Field Significance 396 --------- ---------------- 397 31 Enabled 398 30 IKE/IPSec 399 29 Main Mode 400 28 Aggressive Mode 401 27 PFS 402 26 Transport Mode 403 25 Tunnel Mode 405 iSNS Server Security Bitmap definitions: 407 Enabled This bit specifies the validity of the 408 remainder of the iSNS server security 409 bitmap. If set to one, then the contents 410 of the remainder of the field are valid. 411 If set to zero, then the contents of the 412 rest of the field are undefined and MUST 413 be ignored. 415 IKE/IPSec 1 = IKE/IPSec enabled; 0 = IKE/IPSec 416 disabled. 418 Main Mode 1 = Main Mode enabled; 0 = Main Mode 419 disabled. 421 Aggressive Mode 1 = Aggressive mode enabled; 0 = 422 Aggressive mode disabled. 424 PFS 1 = PFS enabled; 0 = PFS disabled. 426 Transport Mode 1 = Transport mode preferred; 0 = No 427 preference. 429 Tunnel Mode 1 = Tunnel mode preferred; 0 = No 430 preference. 432 3. Security Considerations 434 [RFC3118] should be consulted to determine the requirements for 435 additional security measures to authenticate the iSNS option message 436 received by the DHCP client. If necessary, the authentication 437 option described in [RFC3118] should be utilized. 439 With regard to security considerations specific to the use of this 440 DHCP option for iSNS server discovery, exposure to a "man-in-the- 441 middle" attack by a hostile entity modifying or replacing the 442 original iSNS option message should be considered a potential 443 security exposure. If the authentication option in [RFC3118] is not 444 implemented, then an attacker may trick the iSNS client into 445 connecting into rogue iSNS servers. 447 If the authentication option for DHCP is not implemented and it is 448 determined that the potential exists for a "man-in-the-middle" 449 attack, then the DHCP option message for iSNS should not be 450 utilized. 452 iSNS security considerations are discussed in [iSNS] and [SEC-IPS]. 454 4. IANA Considerations 456 IANA has assigned an option code of TBD for the iSNS option. 458 5. Normative References 460 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 461 2131, Bucknell University, March 1997. 463 [RFC2026] Bradner, S., "The Internet Standards Process -- 464 Revision 3", BCP 9, RFC 2026, October 1996 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997 469 [RFC3118] Arbaugh, W., Droms, R., "Authentication for DHCP 470 Messages", RFC 3118, June 2001 472 6. Non-Normative References 474 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 475 Channel Storage Networking", Internet draft (work in 476 progress), draft-ietf-ips-ifcp-13.txt, May 2002 478 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 479 progress), draft-ietf-ips-iSCSI-15.txt, August 2002 481 [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name 482 Service", Internet draft (work in progress), draft-ietf- 483 ips-isns-12.txt, August 2002 485 [SEC-IPS] Aboba, B., et al., "Securing IP Block Storage 486 Protocols", draft-ietf-ips-security-14.txt, June 2002 488 7. Author's Addresses 490 Kevin Gibbons, 491 Charles Monia, 492 Josh Tseng 494 Nishan Systems 495 3850 North First Street 496 San Jose, CA 95134-1702 497 Phone: (408) 519-3700 498 Email: cmonia@nishansystems.com 499 jtseng@nishansystems.com 500 kgibbons@nishansystems.com 502 Full Copyright Statement 504 "Copyright (C) The Internet Society July 2003. All Rights Reserved. 505 This document and translations of it may be copied and furnished to 506 others, and derivative works that comment on or otherwise explain it 507 or assist in its implementation may be prepared, copied, published 508 and distributed, in whole or in part, without restriction of any 509 kind, provided that the above copyright notice and this paragraph 510 are included on all such copies and derivative works. However, this 511 document itself may not be modified in any way, such as by removing 512 the copyright notice or references to the Internet Society or other 513 Internet organizations, except as needed for the purpose of 514 developing Internet standards in which case the procedures for 515 copyrights defined in the Internet Standards process must be 516 followed, or as required to translate it into languages other than 517 English. 519 The limited permissions granted above are perpetual and will not be 520 revoked by the Internet Society or its successors or assigns. 522 This document and the information contained herein is provided on an 523 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 524 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 525 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 526 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 527 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."