From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4174.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc4174.txt (limited to 'doc/rfc/rfc4174.txt') diff --git a/doc/rfc/rfc4174.txt b/doc/rfc/rfc4174.txt new file mode 100644 index 0000000..4d2693f --- /dev/null +++ b/doc/rfc/rfc4174.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group C. Monia +Request for Comments: 4174 Consultant +Category: Standards Track J. Tseng + Riverbed Technology + K. Gibbons + McDATA Corporation + September 2005 + + + The IPv4 Dynamic Host Configuration Protocol (DHCP) Option + for the Internet Storage Name Service + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes the Dynamic Host Configuration Protocol + (DHCP) option to allow Internet Storage Name Service (iSNS) clients + to discover the location of the iSNS server automatically 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 Channel networks, allowing a + commodity IP network to function in a similar capacity to that of a + storage area network. + +Table of Contents + + 1. Introduction ................................................. 2 + 1.1. Conventions Used in This Document ...................... 2 + 2. iSNS Option for DHCP ......................................... 3 + 2.1. iSNS Functions Field ................................... 5 + 2.2. Discovery Domain Access Field .......................... 6 + 2.3. Administrative Flags Field ............................. 7 + 2.4. iSNS Server Security Bitmap ............................ 8 + 3. Security Considerations ...................................... 9 + 4. IANA Considerations .......................................... 11 + + + +Monia, et al. Standards Track [Page 1] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + 5. Normative References ......................................... 11 + 6. Informative References ....................................... 11 + +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. + + 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: + + a) iSNS functionality is distinctly different from other protocols + using DHCP options. Specifically, iSNS provides a significant + superset of capabilities compared to typical name resolution + protocols such as DNS. It is designed to support client devices + that allow themselves to be configured and managed from a central + iSNS server. + + b) iSNS requires a DHCP option format that provides more than the + location of the iSNS server. The DHCP option has to specify the + subset of iSNS services that may be actively used by the iSNS + client. + + The DHCP option number for iSNS is used by iSCSI and iFCP devices to + discover the location and role of the iSNS server. The DHCP option + number assigned for iSNS by IANA is 83. + +1.1. Conventions Used in This Document + + iSNS refers to the Internet Storage Name Service framework, which + consists of the storage network model and associated services. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + All frame formats are in big-endian network byte order. RESERVED + fields SHOULD be set to zero. + + + + +Monia, et al. Standards Track [Page 2] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + This document uses the following terms: + + "iSNS Client" - iSNS clients are processes resident in iSCSI and + iFCP devices that initiate transactions with the iSNS server using + the iSNS Protocol. + + "iSNS Server" - The iSNS server responds to iSNS protocol query + and registration messages and initiates asynchronous notification + messages. The iSNS server stores information registered by iSNS + clients. + + "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a + new generation of storage devices interconnected with TCP/IP. + + "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- + gateway protocol designed to interconnect existing Fibre Channel + devices using TCP/IP. iFCP maps the Fibre Channel transport and + fabric services to TCP/IP. + +2. iSNS Option for DHCP + + This option specifies the location of the primary and backup iSNS + servers and the iSNS services available to an iSNS client. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code = 83 | Length | iSNS Functions | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DD Access | Administrative FLAGS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | iSNS Server Security Bitmap | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | a1 | a2 | a3 | a4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | b1 | b2 | b3 | b4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | . . . . | + | Additional Secondary iSNS Servers | + | . . . . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1. iSNS Server Option + + + + + + + + +Monia, et al. Standards Track [Page 3] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + The iSNS Option specifies a list of IP addresses used by iSNS + servers. The option contains the following parameters: + + 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. + + Administrative Flags field: Contains the administrative settings + for the iSNS servers discovered through the DHCP query. The + contents of this field are described in section 2.3. + + iSNS Server Security Bitmap: Contains the iSNS server security + settings specified in section 2.4. + + a1...a4: Depending on the setting of the Heartbeat bit in the + Administrative Flags field (see section 2.3), this field + contains either the IP address from which the iSNS heartbeat + originates (see [iSNS]) or the IP address of the primary + iSNS server. + + b1...b4: Depending on the setting of Heartbeat bit in the + Administrative Flags field (see section 2.3), this field + contains either the IP address of the primary iSNS server or + that of a secondary iSNS server. + + Additional Secondary iSNS Servers: Each set of four octets + specifies the IP address of a secondary iSNS server. + + The Code field through IP address field a1...a4 MUST be present in + every response to the iSNS query; therefore the Length field has a + minimum value of 14. + + If the Heartbeat bit is set in the Administrative Flags field (see + section 2.3), then b1...b4 MUST also be present. In this case, the + minimum value of the Length field is 18. + + The inclusion of Additional Secondary iSNS Servers in the response + MUST be indicated by increasing the Length field accordingly. + + + + + + + +Monia, et al. Standards Track [Page 4] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + +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. + + 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 + --------- ------------ + 15 Function Fields Enabled + 14 DD-Based Authorization + 13 Security Policy Distribution + + The following are iSNS Functions Field definitions: + + Function Fields Specifies the validity of the remaining + Enabled: iSNS Function fields. If it is set to one, then + the contents of all other iSNS Function fields + are valid. If it is set to zero, then the + contents of all other iSNS Function fields MUST + be ignored. + + DD-based Indicates whether devices in a common + Authorization: Discovery Domain (DD) are implicitly authorized + to access one another. Although Discovery + Domains control the scope of device discovery, + they do not necessarily indicate whether a domain + member is authorized to access discovered + devices. If this bit is set to one, then devices + in a common Discovery Domain are automatically + allowed access to each other (if successfully + authenticated). If this bit is set to zero, then + access authorization is not implied by domain + membership and must be explicitly performed by + each device. In either case, devices not in a + common discovery domain are not allowed to access + each other. + + + + +Monia, et al. Standards Track [Page 5] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + Security Policy Indicates whether the iSNS client is to + Distribution: download and use the security policy + configuration stored in the iSNS server. If it + is 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 it is set to + zero, then the iSNS client must obtain its + security policy configuration by other means. + +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 | + +---+---+---+---+---+---+---+---+---+ + + Figure 3. Discovery Domain Access Field + + Bit Field Significance + --------- ------------ + 15 Enabled + 14 Control Node + 13 iSCSI Target + 12 iSCSI Initiator + 11 iFCP Target Port + 10 iFCP Initiator Port + + The following are Discovery Domain Access Field definitions: + + Enabled: Specifies the validity of the remaining DD + Access bit field. If it is set to one, then + the contents of the remainder of the DD Access + field are valid. If it is set to zero, then + the contents of the remainder of this field + MUST be ignored. + + Control Node: Specifies whether the iSNS server allows + Discovery Domains to be added, modified, or + deleted by means of Control Nodes. If it is + set to one, then Control Nodes are allowed to + modify the Discovery Domain configuration. If + it is set to zero, then Control Nodes are not + allowed to modify Discovery Domain + configurations. + + + + +Monia, et al. Standards Track [Page 6] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + iSCSI Target, Determine whether the respective + iSCSI Initiator, registered iSNS client (determined + iFCP Target Port, by iSCSI Node Type or iFCP Port Role) + iFCP Initiator is allowed to add, delete, or modify + Port: Discovery Domains. If they are set to one, + then modification by the specified client type + is allowed. If they are set to zero, then + modification by the specified client type is + not allowed. + + (A node may implement multiple node 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESERVED |D|M|H|E| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4. Administrative Flags + + Bit Field Significance + --------- ------------ + 15 Enabled + 14 Heartbeat + 13 Management SCNs + 12 Default Discovery Domain + + The following are Administrative Flags Field definitions: + + Enabled: Specifies the validity of the remainder of the + Administrative Flags field. If it is set to + one, then the contents of the remaining + Administrative Flags are valid. If it is set + to zero, then the remaining contents MUST be + ignored, indicating that iSNS administrative + settings are obtained through means other than + DHCP. + + Heartbeat: Indicates whether the first IP address is the + multicast address to which the iSNS heartbeat + message is sent. If it is set to one, then + a1-a4 contains the heartbeat multicast address + and b1-b4 contains the IP address of the + + + +Monia, et al. Standards Track [Page 7] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + primary iSNS server, followed by the IP + address(es) of any backup servers (see Figure + 1). If it is set to zero, then a1-a4 contain + 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 for receiving Management State + Change Notifications (SCNs). Management SCNs + are a special class of State Change + Notification whose scope is the entire iSNS + database. If this bit is set to one, then + control nodes are authorized to register for + receiving Management SCNs. If it is set to + zero, then control nodes are not authorized to + receive Management SCNs (although they may + receive normal SCNs). + + Default Discovery Indicates whether a newly registered + Domain: device that is not explicitly placed into a + Discovery Domain (DD) and Discovery Domain Set + (DDS) should be automatically placed into a + default DD and DDS. If it is set to one, then + a default DD shall contain all devices in the + iSNS database that have not been explicitly + placed into a DD by an iSNS client. If it is + set to zero, then devices not explicitly placed + into a DD are not members of any DD. + +2.4. iSNS Server Security Bitmap + + The format of the iSNS server security Bitmap field is shown in + Figure 5. If valid, this field communicates to the DHCP client the + security settings that are required to communicate with the indicated + iSNS server. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESERVED |T|X|P|A|M|S|E| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5. iSNS Server Security Bitmap + + + + + + + +Monia, et al. Standards Track [Page 8] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + Bit Field Significance + --------- ---------------- + 31 Enabled + 30 IKE/IPSec + 29 Main Mode + 28 Aggressive Mode + 27 PFS + 26 Transport Mode + 25 Tunnel Mode + + The following are iSNS Server Security Bitmap definitions: + + Enabled: Specifies the validity of the remainder of the + iSNS server security bitmap. If it is set to + one, then the contents of the remainder of the + field are valid. If it is 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 disabled. + + Main Mode: 1 = Main Mode enabled; 0 = Main Mode disabled. + + Aggressive Mode: 1 = Aggressive Mode enabled; + 0 = Aggressive Mode disabled. + + PFS: 1 = PFS enabled; 0 = PFS disabled. + + Transport Mode: 1 = Transport Mode preferred; 0 = No + preference. + + 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, then for each of the bit pairs
and , one of the two + bits MUST be set to 1, and the other MUST be set to 0. + +3. Security Considerations + + For protecting the iSNS option, the DHCP Authentication security + option as specified in [RFC3118] may present a problem due to the + limited implementation and deployment of the DHCP authentication + + + +Monia, et al. Standards Track [Page 9] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + option. 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. + + In addition, [iSNS] describes an authentication block that provides + message integrity for multicast or broadcast iSNS messages (i.e., for + heartbeat/discovery messages only). See [RFC3723] 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 [RFC3720]. 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 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 + complete IKE authentication successfully, and therefore 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. + + 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 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 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. + + + +Monia, et al. Standards Track [Page 10] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + + 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 83 for this option. + + There are no other IANA-assigned values defined by this + specification. + +5. Normative References + + [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [iSNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and + J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, + September 2005. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP + Messages", RFC 3118, June 2001. + + [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and + E. Zeidner, "Internet Small Computer Systems Interface + (iSCSI)", RFC 3720, April 2004. + + [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. + Travostino, "Securing Block Storage Protocols over IP", RFC + 3723, April 2004. + +6. Informative References + + [iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and + M. Edwards, "iFCP - A Protocol for Internet Fibre Channel + Storage Networking", RFC 4172, September 2005. + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + + + + +Monia, et al. Standards Track [Page 11] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + +Authors' Addresses + + Kevin Gibbons + McDATA Corporation + 4555 Great America Parkway + Santa Clara, CA 95054-1208 + + Phone: (408) 567-5765 + EMail: kevin.gibbons@mcdata.com + + + Charles Monia + 7553 Morevern Circle + San Jose, CA 95135 + + EMail: charles_monia@yahoo.com + + + Josh Tseng + Riverbed Technology + 501 2nd Street, Suite 410 + San Francisco, CA 94107 + + Phone: (650)274-2109 + EMail: joshtseng@yahoo.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Monia, et al. Standards Track [Page 12] + +RFC 4174 DHCP Option Number for iSNS September 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + 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. + + 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 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Monia, et al. Standards Track [Page 13] + -- cgit v1.2.3