idnits 2.17.1 draft-ietf-dhc-isnsoption-05.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 171 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 (February 2003) is 7733 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 462 looks like a reference -- Missing reference section? 'RFC2119' on line 465 looks like a reference -- Missing reference section? 'ISNS' on line 188 looks like a reference -- Missing reference section? 'DHCP' on line 459 looks like a reference -- Missing reference section? 'SEC-IPS' on line 483 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 0 warnings (==), 7 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: August 2003 Kevin Gibbons 5 Internet Draft 6 Document: Nishan Systems 7 Category: Standards Track February 2003 9 DHCP Options for 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 IPS mailing list (ips@ece.cmu.edu) or 34 to the authors. 36 Table of Contents 38 DHCP Option Number for iSNS Revision 5 February 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....................................6 48 2.3 Administrative Flags Field.......................................7 49 2.4 iSNS Server Security Bitmap......................................9 50 3.Security Considerations...........................................10 51 4.Normative References..............................................10 52 5.Non-Normative References..........................................11 53 6.Author's Addresses................................................11 54 Full Copyright Statement.............................................12 55 DHCP Option Number for iSNS Revision 5 February 2003 57 Abstract 59 This document describes the DHCP option to allow iSNS clients using 60 DHCP for IPv4 to automatically discover the location of the iSNS 61 server. iSNS provides discovery and management capabilities for 62 iSCSI and Fibre Channel storage devices in an enterprise-scale IP 63 storage network. iSNS provides intelligent storage management 64 services comparable to those found in Fibre Channel networks, 65 allowing a commodity IP network to function in a similar capacity as 66 a storage area network. 68 Conventions used in this document 70 iSNS refers to the framework consisting of the storage network model 71 and associated services. 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 75 this document are to be interpreted as described in [RFC2119]. 77 All frame formats are in big endian network byte order. RESERVED 78 fields SHOULD be set to zero. 80 This document uses the following terms: 82 "iSNS Client" - iSNS clients are processes resident in iSCSI and 83 iFCP devices that initiate transactions with the iSNS server using 84 the iSNS Protocol. 86 "iSNS Server" - The iSNS server responds to iSNS protocol query and 87 registration messages, and initiates asynchronous notification 88 messages. The iSNS server stores information registered by iSNS 89 clients. 91 "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a 92 new generation of storage devices interconnected with TCP/IP. 94 "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- 95 gateway protocol designed to interconnect existing Fibre Channel 96 devices using TCP/IP. iFCP maps the Fibre Channel transport and 97 fabric services to TCP/IP. 99 1. Introduction 101 The Dynamic Host Configuration Protocol for Ipv4 provides a 102 framework for passing configuration information to hosts. Its 103 usefulness extends to hosts and devices using the iSCSI and iFCP 104 protocols to connect to block level storage assets over a TCP/IP 105 network. 107 The iSNS Protocol provides a framework for automated discovery, 108 management, and configuration of iSCSI and iFCP devices on a TCP/IP 109 network. It provides functionality similar to that found on Fibre 110 Channel networks, except that iSNS works within the context of an IP 112 DHCP Option Number for iSNS Revision 5 February 2003 114 network. iSNS thereby provides the requisite storage intelligence 115 to IP networks that are standard on existing Fibre Channel networks. 117 Existing DHCP option numbers are not plausible due to the following 118 reasons: 120 a) iSNS functionality is distinctly different from other protocols 121 using existing DHCP option numbers. Specifically, iSNS provides 122 a significant superset of capabilities compared to typical name 123 resolution protocols such as DNS. It is designed to support 124 client devices that allow themselves to be configured and 125 managed from a central iSNS server 127 b) iSNS requires a DHCP option format that provides more than the 128 location of the iSNS server. The DHCP option number needs to 129 specify the subset of iSNS services that will be actively used 130 by the iSNS client. 132 The DHCP option number for iSNS is used by iSCSI and iFCP devices to 133 discover the location and role of the iSNS server. The DHCP option 134 number assigned for iSNS by IANA is <>. 136 2. iSNS Option for DHCP 138 This option specifies the location of the primary and backup iSNS 139 servers and the iSNS services available to an iSNS client. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Code = TBD | Length | iSNS Functions | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | DD Access | Administrative FLAGS | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | iSNS Server Security Bitmap | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | a1 | a2 | a3 | a4 | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | b1 | b2 | b3 | b4 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | . . . . | 155 | Additional Secondary iSNS Servers | 156 | . . . . | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 1 -- iSNS Server Option 160 The iSNS Option specifies a list of IP addresses used by iSNS 161 servers. The option contains the following parameters: 163 Length: the number of bytes that follow the Length field. The 164 minimum value for the Length field is 6 in order to account 165 for the iSNS Functions, Discovery Domain Access, and 166 Administrative Flags fields. 168 DHCP Option Number for iSNS Revision 5 February 2003 170 iSNS Functions: A bitmapped field defining the functions supported 171 by the iSNS servers. The format of this field is described 172 in section 2.1. 174 Discovery Domain Access: A bit field indicating the types of iSNS 175 clients that are allowed to modify Discovery Domains. The 176 field contents are described in section 2.2. 178 Administrative Flags field: Contains the administrative settings for 179 the iSNS servers discovered through the DHCP query. The 180 contents of this field are described in section 2.3. 182 iSNS Server Security Bitmap: Contains the iSNS server security 183 settings specified in section 2.4. 185 a1...a4: Depending on the setting of the Heartbeat bit in the 186 Administrative Flags field (see section 2.3), this field 187 contains either the IP address from which the iSNS heartbeat 188 originates (see [ISNS]) or the IP address of the primary 189 iSNS server. 191 b1...b4: Depending on the setting of Heartbeat bit in the 192 Administrative Flags field (see section 2.3), this field 193 contains either the IP address of the primary iSNS server or 194 a secondary iSNS server. 196 Additional Secondary iSNS Servers: Each set of four octets specifies 197 the IP address of a secondary iSNS server. 199 2.1 iSNS Functions Field 201 The iSNS Functions Field defines the iSNS server's operational role 202 (i.e., how the iSNS server is to be used). The iSNS server's role 203 can be as basic as providing simple discovery information, or as 204 significant as providing IKE/IPSec security policies and 205 certificates for the use of iSCSI and iFCP devices. The format of 206 the iSNS Role bit field is shown in Figure 2: 208 1 2 3 209 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 |Vendor-Specific |RESERVED |S|A|E| 212 +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 2 -- iSNS Functions 215 DHCP Option Number for iSNS Revision 5 February 2003 217 Bit field Significance 218 --------- ------------ 219 31 Function Fields Enabled 220 30 DD-Based Authorization 221 29 Security policy distribution 222 28 - 24 Reserved 223 23 - 16 Vendor-specific 225 Enabled: This bit specifies the validity of the 226 remaining iSNS Function fields. If set to 227 one, then the contents of all other iSNS 228 Function fields are valid. If set to zero, 229 then the contents of all other iSNS 230 Function fields MUST be ignored. 232 DD-based Indicates whether or not devices in a 233 Authorization: common Discovery Domain (DD) are implicitly 234 authorized to access one another. Although 235 Discovery Domains control the scope of 236 device discovery, they do not necessarily 237 indicate whether or not a domain member is 238 authorized to access discovered devices. 239 If this bit is set to one, then devices in 240 a common Discovery Domain are automatically 241 allowed access to each other (if 242 successfully authenticated). If this bit 243 is set to zero, then access authorization 244 is not implied by domain membership and 245 must be explicitly performed by each 246 device. In either case, devices not in a 247 common discovery domain are not allowed to 248 access each other. 250 Security: Indicates whether the iSNS client is to 251 download and use the security policy 252 configuration stored in the iSNS server. 253 If set to one, then the policy is stored in 254 the iSNS server and must be used by the 255 iSNS client for its own security policy. 256 If set to zero, then the iSNS client must 257 obtain its security policy configuration by 258 other means. 260 Vendor- These bits are used to indicate the vendor- 261 Specific: specific capabilities supported by the 262 indicated iSNS server. 264 2.2 Discovery Domain Access Field 266 The format of the DD Access bit field is shown in Figure 3: 268 DHCP Option Number for iSNS Revision 5 February 2003 270 0 1 2 3 4 5 6 ... 15 271 +---+---+---+---+---+---+---+---+---+ 272 | if| tf| is| ts| C | E | Reserved | 273 +---+---+---+---+---+---+---+---+---+ 274 Figure 3 -- Discovery Domain Access 276 Bit field Significance 277 --------- ------------ 278 0 iFCP Initiator Port 279 1 iFCP Target Port 280 2 iSCSI Initiator 281 3 iSCSI Target 282 4 Control Node 283 5 Enabled 284 6 ... 15 Reserved 286 Enabled: This bit specifies the validity of the 287 remaining DD Access bit fields. If this 288 bit is set to one, then the contents of 289 the remainder of the DD Access field are 290 valid. If this bit is set to zero, then 291 the contents of the remainder of this 292 field MUST be ignored. 294 Control Node: Specifies whether the iSNS server allows 295 Discovery Domains to be added, modified 296 or deleted by means of Control Nodes. If 297 set to one, then Control Nodes are 298 allowed to modify the Discovery Domain 299 configuration. If set to zero, then 300 Control Nodes are not allowed to modify 301 Discovery Domain configurations. 303 iSCSI Target, These bits determine whether the 304 iSCSI Initiator, respective registered iSNS client 305 iFCP Target Port, (determined by iSCSI Node Type or iFCP 306 iFCP Initiator Port Role) is allowed to add, delete, or 307 Port: modify Discovery Domains. If set to 308 one, then modification by the specified 309 client type is allowed. If set to zero, 310 then modification by the specified 311 client type is not allowed. 313 (A node may implement multiple node 314 types.) 316 2.3 Administrative Flags Field 318 The format of the Administrative Flags bit field is shown in 319 Figure 4: 321 DHCP Option Number for iSNS Revision 5 February 2003 323 1 2 3 324 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | RESERVED |D|M|H|E| 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 4 -- Administrative Flags 330 Bit Field Significance 331 --------- ------------ 332 31 Enabled 333 30 Heartbeat 334 29 Management SCNs 335 28 Default Discovery Domain 336 27 - 16 RESERVED 338 Enabled: Specifies the validity of the remainder 339 of the Administrative Flags field. If 340 set to one, then the contents of the 341 remaining Administrative Flags are 342 valid. If set to zero, then the 343 remaining contents MUST be ignored, 344 indicating that iSNS administrative 345 settings are obtained through means 346 other than DHCP. 348 Heartbeat: Indicates whether the first IP address 349 is the multicast address to which the 350 iSNS heartbeat message is sent. If set 351 to one, then a1-a4 contains the 352 heartbeat multicast address and b1-b4 353 contains the IP address of the primary 354 iSNS server, followed by the IP 355 address(es) of any backup servers. If 356 set to zero, then a1-a4 contains the IP 357 address of the primary iSNS server, 358 followed by the IP address(es) of any 359 backup servers. 361 Management SCNs: Indicates whether control nodes are 362 authorized to register to receive 363 Management State Change Notifications 364 (SCN's). Management SCN's are a special 365 class of State Change Notification whose 366 scope is the entire iSNS database. If 367 set to one, then control nodes are 368 authorized to register to receive 369 Management SCN's. If set to zero, then 370 control nodes are not authorized to 371 receive Management SCN's (although they 372 may receive normal SCN's). 374 DHCP Option Number for iSNS Revision 5 February 2003 376 Default Discovery Indicates whether a newly registered 377 Domain: device that is not explicitly placed 378 into a Discovery Domain (DD) and 379 Discovery Domain Set (DDS) should be 380 automatically placed into a default DD 381 and DDS. If set to one, then a default 382 DD shall contain all devices in the iSNS 383 database that have not been explicitly 384 placed into a DD by an iSNS client. If 385 set to zero, then devices not explicitly 386 placed into a DD are not members of any 387 DD. 389 2.4 iSNS Server Security Bitmap 391 The format of the iSNS server security Bitmap field is shown in 392 Figure 5. If valid, this field communicates to the DHCP client the 393 security settings that are required to communicate with the 394 indicated iSNS server. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Reserved |T|X|P|A|M|S|E| 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Figure 5 -- iSNS Server Security Bitmap 403 Bit Field Significance 404 --------- ---------------- 405 31 Enabled 406 30 IKE/IPSec 407 29 Main Mode 408 28 Aggressive Mode 409 27 PFS 410 26 Transport Mode 411 25 Tunnel Mode 412 24 -- 0 Reserved 414 DHCP Option Number for iSNS Revision 5 February 2003 416 Enabled This bit specifies the validity of the 417 remainder of the iSNS server security 418 bitmap. If set to one, then the contents 419 of the remainder of the field are valid. 420 If set to zero, then the contents of the 421 rest of the field are undefined and MUST 422 be ignored. 424 IKE/IPSec 1 = IKE/IPSec enabled; 0 = IKE/IPSec 425 disabled. 427 Main Mode 1 = Main Mode enabled; 0 = Main Mode 428 disabled. 430 Aggressive Mode 1 = Aggressive mode enabled; 0 = 431 Aggressive mode disabled. 433 PFS 1 = PFS enabled; 0 = PFS disabled. 435 Transport Mode 1 = Transport mode preferred; 0 = No 436 preference. 438 Tunnel Mode 1 = Tunnel mode preferred; 0 = No 439 preference. 441 3. Security Considerations 443 DHCP currently provides no authentication or security mechanisms. 444 Potential exposures to attack are discussed in section 7 of the DHCP 445 protocol specification [DHCP]. 447 iSNS security considerations are discussed in [iSNS] and [SEC-IPS]. 448 With regard to security considerations specific to the use of this 449 DHCP option to discover the location of the iSNS server, exposure to 450 a "man-in-the-middle" attack by an hostile entity modifying or 451 replacing the original iSNS option message should be considered a 452 potential security exposure. To prevent an attacker from weakening 453 the required security and potentially tricking the iSNS client into 454 connecting into rogue iSNS servers, reliance on local security 455 policy configuration is an appropriate countermeasure. 457 4. Normative References 459 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 460 2131, Bucknell University, March 1997. 462 [RFC2026] Bradner, S., "The Internet Standards Process -- 463 Revision 3", BCP 9, RFC 2026, October 1996 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, March 1997 468 DHCP Option Number for iSNS Revision 5 February 2003 470 5. Non-Normative References 472 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 473 Channel Storage Networking", Internet draft (work in 474 progress), draft-ietf-ips-ifcp-13.txt, May 2002 476 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 477 progress), draft-ietf-ips-iSCSI-15.txt, August 2002 479 [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name 480 Service", Internet draft (work in progress), draft-ietf- 481 ips-isns-12.txt, August 2002 483 [SEC-IPS] Aboba, B., et al., "Securing IP Block Storage 484 Protocols", draft-ietf-ips-security-14.txt, June 2002 486 6. Author's Addresses 488 Kevin Gibbons, 489 Charles Monia, 490 Josh Tseng 492 Nishan Systems 493 3850 North First Street 494 San Jose, CA 95134-1702 495 Phone: (408) 519-3700 496 Email: cmonia@nishansystems.com 497 jtseng@nishansystems.com 498 kgibbons@nishansystems.com 500 Full Copyright Statement 502 "Copyright (C) The Internet Society February 2003. All Rights 503 Reserved. This document and translations of it may be copied and 504 furnished to others, and derivative works that comment on or 505 otherwise explain it or assist in its implementation may be 506 prepared, copied, published and distributed, in whole or in part, 507 without restriction of any kind, provided that the above copyright 508 notice and this paragraph are included on all such copies and 509 derivative works. However, this document itself may not be modified 510 in any way, such as by removing the copyright notice or references 511 to the Internet Society or other Internet organizations, except as 512 needed for the purpose of developing Internet standards in which 513 case the procedures for copyrights defined in the Internet Standards 514 process must be followed, or as required to translate it into 515 languages other than English. 517 The limited permissions granted above are perpetual and will not be 518 revoked by the Internet Society or its successors or assigns. 520 This document and the information contained herein is provided on an 521 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 522 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 523 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 524 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 525 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."