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/rfc4595.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc4595.txt (limited to 'doc/rfc/rfc4595.txt') diff --git a/doc/rfc/rfc4595.txt b/doc/rfc/rfc4595.txt new file mode 100644 index 0000000..9595cdb --- /dev/null +++ b/doc/rfc/rfc4595.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group F. Maino +Request for Comments: 4595 Cisco Systems +Category: Informational D. Black + EMC Corporation + July 2006 + + + Use of IKEv2 in the + Fibre Channel Security Association Management Protocol + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes the use of IKEv2 to negotiate security + protocols and transforms for Fibre Channel as part of the Fibre + Channel Security Association Management Protocol. This usage + requires that IKEv2 be extended with Fibre-Channel-specific security + protocols, transforms, and name types. This document specifies these + IKEv2 extensions and allocates identifiers for them. Using new IKEv2 + identifiers for Fibre Channel security protocols avoids any possible + confusion between IKEv2 negotiation for IP networks and IKEv2 + negotiation for Fibre Channel. + + + + + + + + + + + + + + + + + + + + +Maino & Black Informational [Page 1] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Requirements Notation ......................................3 + 2. Overview ........................................................4 + 3. Fibre Channel Security Protocols ................................5 + 3.1. ESP_Header Protocol ........................................6 + 3.2. CT_Authentication Protocol .................................7 + 4. The FC SA Management Protocol ...................................9 + 4.1. Fibre Channel Name Identifier ..............................9 + 4.2. ESP_Header and CT_Authentication Protocol ID ...............9 + 4.3. CT_Authentication Protocol Transform Identifiers ..........10 + 4.4. Fibre Channel Traffic Selectors ...........................10 + 4.5. Negotiating Security Associations for FC and IP ...........12 + 5. Security Considerations ........................................12 + 6. IANA Considerations ............................................13 + 7. References .....................................................14 + 7.1. Normative References ......................................14 + 7.2. Informative References ....................................14 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Maino & Black Informational [Page 2] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +1. Introduction + + Fibre Channel (FC) is a gigabit-speed network technology primarily + used for Storage Networking. Fibre Channel is standardized in the + T11 [T11] Technical Committee of the InterNational Committee for + Information Technology Standards (INCITS), an American National + Standard Institute (ANSI) accredited standards committee. + + FC-SP (Fibre Channel Security Protocols) is a T11 Technical Committee + working group that has developed the "Fibre Channel Security + Protocols" standard [FC-SP], a security architecture for Fibre + Channel networks. + + The FC-SP standard defines a set of protocols for Fibre Channel + networks that provides: + + 1. device-to-device (hosts, disks, switches) authentication; + + 2. management and establishment of secrets and security + associations; + + 3. data origin authentication, integrity, anti-replay protection, + confidentiality; and + + 4. security policies distribution. + + Within this framework, a Fibre Channel device can verify the identity + of another Fibre Channel device and establish a shared secret that + will be used to negotiate security associations for security + protocols applied to Fibre Channel frames and information units. The + same framework allows for distributions within a Fibre Channel fabric + of policies that will be enforced by the fabric. + + FC-SP has adapted the IKEv2 protocol [RFC4306] to provide + authentication of Fibre Channel entities and setup of security + associations. + +1.1. Requirements Notation + + 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]. + + + + + + + + + +Maino & Black Informational [Page 3] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +2. Overview + + Fibre Channel defines two security protocols that provide security + services for different portions of Fibre Channel traffic: the + ESP_Header defined in [FC-FS] and CT_Authentication defined in + [FC-GS-4]. + + The ESP_Header protocol is a transform applied to FC-2 Fibre Channel + frames. It is based on the IP Encapsulation Security Payload + [RFC4303] to provide origin authentication, integrity, anti-replay + protection, and optional confidentiality to generic fibre channel + frames. The CT_Authentication protocol is a transform that provides + the same set of security services for Common Transport Information + Units, which are used to convey control information. As a result of + the separation of Fibre Channel data traffic from control traffic, + only one protocol (either ESP_Header or CT_Authentication) is + applicable to any FC Security Association (SA). + + Security associations for the ESP_Header and CT_Authentication + protocols between two Fibre Channel entities (hosts, disks, or + switches) are negotiated by the Fibre Channel Security Association + Management Protocol, a generic protocol based on IKEv2 [RFC4306]. + + Since IP is transported over Fibre Channel [RFC4338] and Fibre + Channel/SCSI are transported over IP [RFC3643], [RFC3821] there is + the potential for confusion when IKEv2 is used for both IP and FC + traffic. This document specifies identifiers for IKEv2 over FC in a + fashion that ensures that any mistaken usage of IKEv2/FC over IP will + result in a negotiation failure due to the absence of an acceptable + proposal (and likewise for IKEv2/IP over FC). This document gives an + overview of the security architecture defined by the FC-SP standard, + including the security protocols used to protect frames and to + negotiate SAs, and it specifies the entities for which new + identifiers have been assigned. + + + + + + + + + + + + + + + + + +Maino & Black Informational [Page 4] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +3. Fibre Channel Security Protocols + + The Fibre Channel protocol is described in [FC-FS] as a network + architecture organized in 5 levels. The FC-2 level defines the FC + frame format (shown in Figure 1), the transport services, and control + functions required for information transfer. + + +-----+-----------+-----------+--------//-------+-----+-----+ + | | | Data Field | | | + | SOF | FC Header |<--------------------------->| CRC | EOF | + | | | Optional | Frame | | | + | | | Header(s) | Payload | | | + +-----+-----------+-----------+--------//-------+-----+-----+ + + Figure 1: Fibre Channel Frame Format + + Fibre Channel Generic Services share a Common Transport (CT) at the + FC-4 level defined in [FC-GS-4]. The CT provides access to a Service + (e.g., Directory Service) with a set of service parameters that + facilitates the usage of Fibre Channel constructs. + + A Common Transport Information Unit (CT_IU) is the common Fibre + Channel Sequence used to transfer all information between a Client + and a Server. The first part of the CT_IU, shown in Figure 2, + contains a preamble with information common to all CT_IUs. An + optional Extended CT_IU Preamble carries the CT_Authentication + protocol that provides authentication and, optionally, + confidentiality to CT_IUs. The CT_IU is completed by an optional + Vendor-Specific Preamble and by additional information as defined by + the preamble. + + + + + + + + + + + + + + + + + + + + + +Maino & Black Informational [Page 5] + +RFC 4595 IKEv2 in FC-SP July 2006 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Basic CT_IU Preamble ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Extended CT_IU Preamble (optional) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Vendor Specific Preamble (optional) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Additional Information ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: CT_IU + + Two security protocols are defined for Fibre Channel: the ESP_Header + protocol that protects the FC-2 level, and the CT_Authentication + protocol that protects the Common Transport at the FC-4 level. + + Security Associations for the ESP_Header and CT_Authentication + protocols are negotiated by the Fibre Channel Security Association + Management Protocol. + +3.1. ESP_Header Protocol + + ESP_Header is a security protocol for FC-2 Fibre Channel frames that + provides origin authentication, integrity, anti-replay protection, + and confidentiality. ESP_Header is carried as the first optional + header in the FC-2 frame, and its presence is signaled by a flag in + the DF_CTL field of the FC-2 header. + + Figure 3 shows the format of an FC-2 frame encapsulated with an + ESP_Header. The encapsulation format is equivalent to the IP + Encapsulating Security Payload [RFC4303], but the scope of the + authentication covers the entire FC-2 header. The Destination and + Source Fibre Channel addresses (D_ID and S_ID) and the CS_CTL/ + Priority field are normalized before computation of the Integrity + Check value to allow for address translation. + + + + + + +Maino & Black Informational [Page 6] + +RFC 4595 IKEv2 in FC-SP July 2006 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- + | R_CTL |////////////////D_ID///////////////////////////| ^ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + |//CS_CTL/Pri.//|////////////////S_ID///////////////////////////| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | Type | F_CTL |Auth + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Cov- + | SEQ_ID | DF_CTL | SEQ_CNT |era- + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ge + | OX_ID | RX_ID | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | Parameter | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | Security Parameters Index (SPI) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | Sequence Number | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |-- + | Payload Data (variable) | |^ + ~ ~ || + ~ ~Conf + | |Cov- + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+era- + | | Padding (0-255 bytes) |ge + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || + | | Pad Length | Reserved | vv + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---- + | Integrity Check Value (variable) | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: ESP_Header Encapsulation + + All the security transforms that are defined for the IP Encapsulating + Security Payload, such as AES-CBC [RFC3602], can be applied to the + ESP_Header protocol. + +3.2. CT_Authentication Protocol + + CT_Authentication is a security protocol for Common Transport FC-4 + Information Units that provides origin authentication, integrity, and + anti-replay protection. The CT_Authentication protocol is carried in + the optional extended CT_IU preamble + + + + + + +Maino & Black Informational [Page 7] + +RFC 4595 IKEv2 in FC-SP July 2006 + + + The extended CT_IU preamble, shown in Figure 4, includes an + Authentication Security Association Identifier (SAID), a transaction + ID, the N_port name of the requesting node, a Time Stamp used to + prevent replay attacks, and an Authentication Hash Block. + + The scope of the Authentication Hash Block Covers all data words of + the CT_IU, with the exception of the frame_header, the IN_ID field in + the basic CT_IU preamble, the Authentication Hash Block itself, and + the frame CRC field. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Authentication SAID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Transaction_id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Requesting_CT N_Port Name + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Time Stamp + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Authentication Hash Block ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: Extended CT_IU Preamble + + The Authentication Hash Block is computed as an HMAC keyed hash of + the CT_IU, as defined in [RFC2104]. The entire output of the HMAC + computation is included in the Authentication Hash Block, without any + truncation. Two transforms are defined: HMAC-SHA1-160 that is based + on the cryptographic hash function SHA1 [NIST.180-1.1995], and + HMAC-MD5-128 that is based on the cryptographic hash function MD5 + [RFC1321]. + + + + + + + + + + + + +Maino & Black Informational [Page 8] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +4. The FC SA Management Protocol + + Fibre Channel entities negotiate security associations for the + protocols described above by using the Fibre Channel Security + Association Management protocol, as defined in [FC-SP]. The protocol + is a modified subset of the IKEv2 protocol [RFC4306] that performs + the same core operations, and it uses the Fibre Channel AUTH protocol + to transport IKEv2 messages. + + The protocol supports only the basic features of IKEv2: initial + exchange to create an IKE SA and the first child SA, the + CREATE_CHILD_SA exchange to negotiate additional SAs, and the + INFORMATIONAL exchange, including notification, delete, and vendor ID + payloads. IKEv2 features that are not supported for Fibre Channels + include: negotiation of multiple protocols within the same proposal, + capability to handle multiple outstanding requests, cookies, + configuration payload, and the Extended Authentication Protocol (EAP) + payload. + + The following subsections describe the additional IANA assigned + values required by the Fibre Channel Security Association Management + protocol, as defined in [FC-SP]. All the values have been allocated + from the new registries created for the IKEv2 protocol [RFC4306]. + +4.1. Fibre Channel Name Identifier + + Fibre Channels entities that negotiate security associations are + identified by an 8-byte Name. Support for this name format has been + added to the IKEv2 Identification Payload, introducing a new ID type + beyond the ones already defined in Section 3.5 of [RFC4306]. This ID + Type MUST be supported by any implementation of the Fibre Channel + Security Association Management Protocol. + + The FC_Name_Identifier is then defined as a single 8-octet Fibre + Channel Name: + + ID Type Value + ------- ----- + ID_FC_NAME 12 + +4.2. ESP_Header and CT_Authentication Protocol ID + + Security protocols negotiated by IKEv2 are identified by the Protocol + ID field contained in the proposal substructure of a Security + Association Payload, as defined in Section 3.3.1 of [RFC4306]. + + The following protocol IDs have been defined to identify the Fibre + Channel ESP_Header and the CT_Authentication security protocols: + + + +Maino & Black Informational [Page 9] + +RFC 4595 IKEv2 in FC-SP July 2006 + + + Protocol ID Value + ----------- ----- + FC_ESP_HEADER 4 + + FC_CT_AUTHENTICATION 5 + + The existing IKEv2 value for ESP (3) is deliberately not reused in + order to avoid any possibility of confusion between IKEv2 proposals + for IP security associations and IKEv2 proposals for FC security + associations. + + The number and type of transforms that accompany an SA payload are + dependent on the protocol in the SA itself. An SA payload proposing + the establishment of a Fibre Channel SA has the following mandatory + and optional transform types. + + Protocol Mandatory Types Optional Types + -------- --------------- -------------- + FC_ESP_HEADER Integrity Encryption, DH Groups + + FC_CT_AUTHENTICATION Integrity Encryption, DH Groups + +4.3. CT_Authentication Protocol Transform Identifiers + + The CT_Authentication Transform IDs defined for Transform Type 3 + (Integrity Algorithm) are: + + Name Number Defined in + ---- ------ ---------- + AUTH_HMAC_MD5_128 6 FC-SP + + AUTH_HMAC_SHA1_160 7 FC-SP + + These transforms differ from the corresponding _96 transforms used in + IPsec solely in the omission of the truncation of the HMAC output to + 96 bits; instead, the entire output (128 bits for MD5, 160 bits for + SHA-1) is transmitted. MD5 support is required due to existing usage + of MD5 in CT_Authentication; SHA-1 is RECOMMENDED in all new + implementations. + +4.4. Fibre Channel Traffic Selectors + + Fibre Channel Traffic Selectors allow peers to identify packet flows + for processing by Fibre Channel security services. A new Traffic + Selector Type has been added to the IKEv2 Traffic Selector Types + Registry defined in Section 3.13.1 of [RFC4306]. This Traffic + Selector Type MUST be supported by any implementation of the Fibre + Channel Security Association Management Protocol. + + + +Maino & Black Informational [Page 10] + +RFC 4595 IKEv2 in FC-SP July 2006 + + + Fibre Channel traffic selectors are defined in [FC-SP] as a list of + FC address and protocol ranges, as shown in Figure 5. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TS TYPE | Reserved | Selector Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Starting Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Ending Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Starting R_CTL| Ending R_CTL | Starting Type | Ending Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Fibre Channel Traffic Selector + + The following table lists the assigned value for the Fibre Channel + Traffic Selector Type field: + + TS Type Value + ------- ----- + TS_FC_ADDR_RANGE 9 + + The Starting and Ending Address fields are 24-bit addresses assigned + to Fibre Channel names as part of initializing Fibre Channel + communications (e.g., for a switched Fibre Channel Fabric, end nodes + acquire these identifiers from Fabric Login, FLOGI). + + The Starting and Ending R_CTL fields are the 8-bit Routing Control + identifiers that define the category and, in some cases, the function + of the FC frame; see [FC-FS] for details. + + As a result of the separation of Fibre Channel data traffic from + control traffic, only one protocol (either ESP_Header or + CT_Authentication) is applicable to any FC Security Association. + When the Fibre Channel Traffic Selector is defined for the ESP_Header + protocol, the Starting Type and Ending Type fields identify the range + of FC-2 protocols to be selected. When the Fibre Channel Traffic + Selector is defined for the CT_Authentication protocol, the FC-2 Type + is implicitly set to the value '20h', which identifies + CT_Authentication information units, and the Starting Type and Ending + Type fields identify the range of Generic Service subtypes + (GS_Subtype) to be selected. See [FC-FS] and [FC-GS-4] for details. + + + + + + + +Maino & Black Informational [Page 11] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +4.5. Negotiating Security Associations for FC and IP + + The ESP_header and CT_Authentication protocols are Fibre-Channel- + specific security protocols that apply to Fibre Channel frames only. + The values identifying security protocols, transforms, selectors, and + name types defined in this document MUST NOT be used during IKEv2 + negotiation for IPsec protocols. + +5. Security Considerations + + The security considerations in IKEv2 [RFC4306] apply, with the + exception of those related to NAT traversal, EAP, and IP + fragmentation. NAT traversal and EAP, in fact, are not supported by + the Fibre Channel Security Association Management Protocol (which is + based on IKEv2), and IP fragmentation cannot occur because IP is not + used to carry the Fibre Channel Security Association Management + Protocol messages. + + Fibre Channel Security Association Management Protocol messages are + mapped over Fibre Channel Sequences. A Sequence is able to carry up + to 4 GB of data; there are no theoretical limitations to the size of + IKEv2 messages. However, some Fibre Channel endpoint implementations + have limited sequencing capabilities for the particular frames used + to map IKEv2 messages over Fibre Channel. To address these + limitations, the Fibre Channel Security Association Management + Protocol supports fragmentation of IKEv2 messages (see Section 5.9 of + [FC-SP]). If the IKEv2 messages are long enough to trigger + fragmentation, it is possible that attackers could prevent the IKEv2 + exchange from completing by exhausting the reassembly buffers. The + chances of this can be minimized by using the Hash and URL encodings + instead of sending certificates (see Section 3.6 of [RFC4306]). + + + + + + + + + + + + + + + + + + + + +Maino & Black Informational [Page 12] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +6. IANA Considerations + + The standards action of this document establishes the following + values allocated by IANA in the registries created for IKEv2 + [RFC4306]. + + Allocated the following value for the IKEv2 Identification Payload ID + Types Registry (Section 3.5 of [RFC4306]): + + ID Type Value + ------- ----- + ID_FC_NAME 12 + + Allocated the following values for the IKEv2 Security Protocol + Identifiers Registry (Section 3.3.1 of [RFC4306]): + + Protocol ID Value + ----------- ----- + FC_ESP_HEADER 4 + + FC_CT_AUTHENTICATION 5 + + Allocated the following values for Transform Type 3 (Integrity + Algorithm) for the IKEv2 Integrity Algorithm Transform IDs Registry + (Section 3.3.2 of [RFC4306]): + + Name Number + ---- ------ + AUTH_HMAC_MD5_128 6 + + AUTH_HMAC_SHA1_160 7 + + Allocated the following value for the IKEv2 Traffic Selector Types + Registry (Section 3.13.1 of [RFC4306]): + + TS Type Value + ------- ----- + TS_FC_ADDR_RANGE 9 + + + + + + + + + + + + + +Maino & Black Informational [Page 13] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +7. References + +7.1. Normative References + + [NIST.180-1.1995] + National Institute of Standards and Technology, "Secure + Hash Standard", NIST 180-1, April 1995. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher + Algorithm and Its Use with IPsec", RFC 3602, + September 2003. + + [RFC3643] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., + Monia, C., and M. Merhar, "Fibre Channel (FC) Frame + Encapsulation", RFC 3643, December 2003. + + [RFC3821] Rajagopal, M., E. Rodriguez, E., and R. Weber, "Fibre + Channel Over TCP/IP (FCIP)", RFC 3602, July 2004. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC + 4303, December 2005. + + [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC + 4306, December 2005. + + [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of + IPv6, IPv4, and Address Resolution Protocol (ARP) Packets + over Fibre Channel", RFC 4338, January 2006. + +7.2. Informative References + + [FC-FS] INCITS Technical Committee T11, ANSI INCITS 373-2003, + "Fibre Channel - Framing and Signaling (FC-FS)". + + [FC-GS-4] INCITS Technical Committee T11, ANSI INCITS 387-2004, + "Fibre Channel - Generic Services 4 (FC-GS-4)". + + + + + +Maino & Black Informational [Page 14] + +RFC 4595 IKEv2 in FC-SP July 2006 + + + [FC-SP] INCITS Technical Committee T11, ANSI INCITS xxx-200x, + "Fibre Channel - Security Protocols (FC-SP)". + + [T11] INCITS Technical Commitee T11, "Home Page of the INCITS + Technical Committee T11", . + +Authors' Addresses + + Fabio Maino + Cisco Systems + 375 East Tasman Drive + San Jose, CA 95134 + US + + Phone: +1 408 853 7530 + EMail: fmaino@cisco.com + URI: http://www.cisco.com/ + + + David L. Black + EMC Corporation + 176 South Street + Hopkinton, MA 01748 + US + + Phone: +1 508 293-7953 + EMail: black_david@emc.com + URI: http://www.emc.com/ + + + + + + + + + + + + + + + + + + + + + + + +Maino & Black Informational [Page 15] + +RFC 4595 IKEv2 in FC-SP July 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Maino & Black Informational [Page 16] + -- cgit v1.2.3