--- 1/draft-ietf-dhc-isnsoption-12.txt 2006-02-04 23:04:27.000000000 +0100 +++ 2/draft-ietf-dhc-isnsoption-13.txt 2006-02-04 23:04:27.000000000 +0100 @@ -1,18 +1,17 @@ - DHC Working Group Charles Monia INTERNET DRAFT Josh Tseng - Expires: January 2005 Kevin Gibbons + Expires: May 2005 Kevin Gibbons Internet Draft McDATA Corporation - Document: - Category: Standards Track July 2004 + Document: + Category: Standards Track November 2004 The IPv4 DHCP Option for the Internet Storage Name Service Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. @@ -29,21 +28,21 @@ http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments Comments should be sent to the DHCP mailing list (dhcwg@ietf.org) or to the authors. -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 Table of Contents Status of this Memo...................................................1 Comments..............................................................1 Abstract..............................................................3 Conventions used in this document.....................................3 1. Introduction.......................................................3 2. iSNS Option for DHCP...............................................4 2.1 iSNS Functions Field..............................................5 @@ -54,21 +53,21 @@ 4. IANA Considerations...............................................11 5. Normative References..............................................12 6. Non-Normative References..........................................12 7. Author's Addresses................................................13 8. Intellectual Property.............................................13 9. Full Copyright Statement..........................................13 10. Disclaimer of Validity...........................................13 11. Acknowledgement..................................................14 12. Expiration Notice................................................14 -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 Abstract This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre @@ -107,21 +106,21 @@ fabric services to TCP/IP. 1. Introduction The Dynamic Host Configuration Protocol for IPv4 provides a framework for passing configuration information to hosts. Its usefulness extends to hosts and devices using the iSCSI and iFCP protocols to connect to block level storage assets over a TCP/IP network. -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 The iSNS Protocol provides a framework for automated discovery, management, and configuration of iSCSI and iFCP devices on a TCP/IP network. It provides functionality similar to that found on Fibre Channel networks, except that iSNS works within the context of an IP network. iSNS thereby provides the requisite storage intelligence to IP networks that are standard on existing Fibre Channel networks. Existing DHCP options cannot be used to find iSNS servers for the following reasons: @@ -162,21 +162,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . | | Additional Secondary iSNS Servers | | . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 -- iSNS Server Option The iSNS Option specifies a list of IP addresses used by iSNS servers. The option contains the following parameters: -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 Length: the number of bytes that follow the Length field. iSNS Functions: A bitmapped field defining the functions supported by the iSNS servers. The format of this field is described in section 2.1. Discovery Domain Access: A bit field indicating the types of iSNS clients that are allowed to modify Discovery Domains. The field contents are described in section 2.2. @@ -215,21 +215,21 @@ 2.1 iSNS Functions Field The iSNS Functions Field defines the iSNS server's operational role (i.e., how the iSNS server is to be used). The iSNS server's role can be as basic as providing simple discovery information, or as significant as providing IKE/IPSec security policies and certificates for the use of iSCSI and iFCP devices. The format of the iSNS Functions field is shown in Figure 2: -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RESERVED |S|A|E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 -- iSNS Functions Field Bit field Significance --------- ------------ @@ -267,21 +267,21 @@ Security Policy Indicates whether the iSNS client is to Distribution: download and use the security policy configuration stored in the iSNS server. If set to one, then the policy is stored in the iSNS server and must be used by the iSNS client for its own security policy. If set to zero, then the iSNS client must obtain its security policy configuration by other means. -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 2.2 Discovery Domain Access Field The format of the DD Access bit field is shown in Figure 3: 0 1 1 1 1 1 1 0 ... 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+ | RESERVED | if| tf| is| ts| C | E | +---+---+---+---+---+---+---+---+---+ @@ -320,21 +321,21 @@ iFCP Target Port, (determined by iSCSI Node Type or iFCP iFCP Initiator Port Role) is allowed to add, delete, or Port: modify Discovery Domains. If set to one, then modification by the specified client type is allowed. If set to zero, then modification by the specified client type is not allowed. (A node may implement multiple node -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 types.) 2.3 Administrative Flags Field The format of the Administrative Flags bit field is shown in Figure 4: 0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 @@ -372,21 +373,21 @@ address(es) of any backup servers (see Figure 1). If set to zero, then a1-a4 contains the IP address of the primary iSNS server, followed by the IP address(es) of any backup servers. Management SCNs: Indicates whether control nodes are authorized to register to receive Management State Change Notifications -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 (SCN's). Management SCN's are a special class of State Change Notification whose scope is the entire iSNS database. If set to one, then control nodes are authorized to register to receive Management SCN's. If set to zero, then control nodes are not authorized to receive Management SCN's (although they may receive normal SCN's). @@ -423,21 +424,21 @@ 31 Enabled 30 IKE/IPSec 29 Main Mode 28 Aggressive Mode 27 PFS 26 Transport Mode 25 Tunnel Mode iSNS Server Security Bitmap definitions: -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 Enabled This bit specifies the validity of the remainder of the iSNS server security bitmap. If set to one, then the contents of the remainder of the field are valid. If set to zero, then the contents of the rest of the field are undefined and MUST be ignored. IKE/IPSec 1 = IKE/IPSec enabled; 0 = IKE/IPSec @@ -456,93 +457,91 @@ Tunnel Mode 1 = Tunnel mode preferred; 0 = No preference. If IKE/IPSec is disabled, this indicates that the Internet Key Exchange (IKE) Protocol is not available to configure IPSec keys for iSNS sessions to this iSNS server. It does not necessarily preclude other key exchange methods (e.g., manual keying) from establishing an IPSec security association for the iSNS session. - If IKE/IPsec is enabled, an implementation SHALL enable: - - a) One of Main Mode or Aggressive Mode but not both and - - b) One of Transport Mode or Tunnel Mode but not both. + If IKE/IPsec is enabled, then for each of the bit pairs +
and , + one of the two bits MUST be set to 1 and the other bit + MUST be set to 0. 3. Security Considerations The DHCP Authentication security option as specified in [RFC3118] to protect the iSNS option may present a problem due to the limited implementation and deployment of the DHCP authentication option. - The IPSec security mechanisms for iSNS itself are specified in + The IPsec security mechanisms for iSNS itself are specified in [iSNS] to provide confidentiality when sensitive information is distributed via iSNS. See the Security Considerations section of [iSNS] for details and specific requirements for implementation of - IPSec. + IPsec. In addition,[iSNS] describes an authentication block that provides message integrity for multicast or broadcast iSNS messages (i.e. for -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 heartbeat/discovery messages only). See [RFC 3723] for further discussion of security for these protocols. If no sensitive information, as described in [iSNS], is being distributed via iSNS, and an Entity is discovered via iSNS, authentication and authorization are handled by the IP Storage protocols whose endpoints are discovered via iSNS, specifically iFCP [iFCP] and iSCSI [RFC 3720]. It is the responsibility of the providers of these services to ensure that an inappropriately advertised or discovered service does not compromise their security. - When no security is used, there is a risk of distribution of false - discovery information (e.g., via the iSNS DHCP option identifying a - false iSNS server that distributes the false discovery information). - The primary countermeasure for this risk is authentication. When - this risk is a significant concern, IPsec SAs SHOULD be used for IP - Storage protocol (iSCSI and iFCP) traffic subject to this risk to - ensure that such traffic only flows between endpoints that have - participated in IKE authentication. For example, if an attacker - distributes discovery information falsely identifying an iSCSI - endpoint, that endpoint will lack the secret information necessary - to successfully complete IKE authentication, and hence will be - prevented from falsely sending or receiving iSCSI traffic. When this - risk of false discovery information is a significant concern and - IPSec is implemented for iSNS, IPSec SAs SHOULD also be used for - iSNS traffic to prevent use of a false iSNS server rather than - relying only on the IP Storage protocols to detect false discovery - information. + When no DHCP security is used, there is a risk of distribution of + false discovery information (e.g., via the iSNS DHCP option + identifying a false iSNS server that distributes the false + discovery information). The primary countermeasure for this risk + is authentication by the IP storage protocols discovered through + iSNS. When this risk is a significant concern, IPsec SAs SHOULD be + used (as specified in RFC 3723). For example, if an attacker uses + DHCP and iSNS to distribute discovery information that falsely + identifies an iSCSI endpoint, that endpoint will lack the + credentials necessary to successfully complete IKE authentication, + and hence will be prevented from falsely sending or receiving iSCSI + traffic. When this risk of false discovery information is a + significant concern and IPsec is implemented for iSNS, IPsec SAs + SHOULD also be used for iSNS traffic to prevent use of a false iSNS + server; this is more robust than relying only on the IP Storage + protocols to detect false discovery information. - There remains a risk of a denial of service attack based on repeated - use of false discovery information that will cause initiation of IKE - negotiation. The countermeasures for this are administrative - configuration of each iSNS and IP Storage (iSCSI and FCIP) Entity to + When IPsec is implemented for iSNS, there is a risk of a denial of + service attack based on repeated use of false discovery information + that will cause initiation of IKE negotiation. The countermeasures + for this are administrative configuration of each iSNS Entity to limit the peers that it is willing to communicate with (i.e., by IP address range and/or DNS domain), and maintenance of a negative authentication cache to avoid repeatedly contacting an iSNS Entity that fails to authenticate. These three measures (i.e., IP address - range limits, DNS domain limits, negative authentication cache) MUST - be implemented for IP Storage (iSCSI and iFCP) protocols and iSNS - Entities. For iSNS, these requirements apply only when this DHCP - option is used, and in addition, the negative authentication cache - requirement applies only when IPSec support is implemented for iSNS, - as a negative authentication cache is of no value in the absence of - authentication. + range limits, DNS domain limits, negative authentication cache) + MUST be implemented for iSNS entities when this DHCP option is + used. An analogous argument applies to the IP storage protocols + that can be discovered via iSNS as discussed in RFC 3723. + + In addition, use of the techniques described in [RFC2827] and + [RFC3833] may also be relevant to reduce denial of service attacks. 4. IANA Considerations In accordance with the policy defined in [DHCP], IANA has assigned a value of TBD for this option. -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 There are no other IANA-assigned values defined by this specification. 5. Normative References [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name @@ -569,20 +568,27 @@ [RFC3723] Aboba, B., et al., "Securing Block Storage Protocols over IP", RFC 3723, April 2004 6. Non-Normative References [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Internet draft (work in progress), draft-ietf-ips-ifcp-13.txt, May 2002 + [RFC2827] Ferguson, P., et al., "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP + Source Address Spoofing", BCP 38, RFC 2827, May 2000 + + [RFC3833] Atkins, D., et al., "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004 + 7. Author's Addresses Kevin Gibbons, Charles Monia, Josh Tseng McDATA Corporation 3850 North First Street San Jose, CA 95134-1702 Phone: (408) 519-3700 @@ -608,33 +614,34 @@ from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 9. Full Copyright Statement - Copyright (C) The Internet Society July 2004. This document is subject to + Copyright (C) The Inter +net Society July 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 10. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL -DHCP Option Number for iSNS Revision 12 July 2004 +DHCP Option Number for iSNS Revision 13 November 2004 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be upated, replaced, or obsoleted by other documents at any time. It @@ -647,11 +654,11 @@ The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 11. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 12. Expiration Notice - This Internet-Draft expires in January 2005. + This Internet-Draft expires in May 2005.