Network Working Group F. MainoInternet-DraftRequest for Comments: 4595 Cisco SystemsExpires: March 18, 2006Category: Informational D. Black EMC CorporationSeptember 14, 2005July 2006 Use of IKEv2 inThethe Fibre Channel Security Association Management Protocoldraft-maino-fcsp-02.txtStatus ofthisThis MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents ofThis memo provides information for the InternetEngineering 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 updated, replaced, or obsoleted by other documents at any time.community. Itis inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listdoes not specify an Internet standard ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The listany kind. Distribution ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 18, 2006.this memo is unlimited. Copyright Notice Copyright (C) The Internet Society(2005).(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,transformstransforms, 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. Table of Contents 1. Introduction ....................................................3 1.1. Requirementsnotation . . . . . . . . . . . . . . . . . . . . 3Notation ......................................3 2.Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.........................................................4 3. Fibre Channel Security Protocols. . . . . . . . . . . . . . . 6 4.1.................................5 3.1. ESP_Header Protocol. . . . . . . . . . . . . . . . . . . 7 4.2.........................................6 3.2. CT_Authentication Protocol. . . . . . . . . . . . . . . . 8 5..................................7 4. The FC SA Management Protocol. . . . . . . . . . . . . . . . 10 5.1....................................9 4.1. Fibre Channel Name Identifier. . . . . . . . . . . . . . 10 5.2...............................9 4.2. ESP_Header andCT_AUthenticationCT_Authentication Protocol ID. . . . . . . 10 5.3................9 4.3. CT_Authentication Protocol Transform Identifiers. . . . . 11 5.4...........10 4.4. Fibre Channel Traffic Selectors. . . . . . . . . . . . . 11 5.5............................10 4.5. Negotiating Security Associations for FC and IP. . . . . 13 6............12 5. Security Considerations. . . . . . . . . . . . . . . . . . . 14 7.........................................12 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 15 8.............................................13 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Informative.....................................................14 7.1. Normative References. . . . . . . . . . . . . . . . . . 16 8.2.......................................14 7.2. Informative References. . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19....................................14 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]. 2.Introduction Fibre Channel (FC) is agigabit speedgigabit-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 aworking group of theT11 Technical Committee working group thatis developinghas 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 forfibre channelFibre Channel networks that provides: 1.device to devicedevice-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 thisframeworkframework, afibre channelFibre Channel device can verify the identity of anotherfibre channel device,Fibre Channel device and establish a shared secret that will be used to negotiate security associations for security protocols applied tofibre channelFibre Channel frames and informationunit.units. The same framework allows for distributions within afibre channelFibre Channel fabric of policies that will be enforced by the fabric. FC-SPis adaptinghas adapted the IKEv2 protocol[I-D.ietf-ipsec-ikev2-17][RFC4306] to provide authentication of Fibre Channel entities and setup of security associations.3.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]. 2. Overview Fibre Channel defines two security protocols that provide security services for different portions of Fibre Channel traffic: the ESP_Headerisdefined in[FC-FS], while[FC-FS] and CT_Authenticationisdefined in[FC-GS].[FC-GS-4]. The ESP_Header protocol is a transform applied to FC-2fibre channel frames, andFibre Channel frames. It is based on the IP Encapsulation Security Payload[RFC2406],[RFC4303] to provide origin authentication, integrity, anti-replayprotectionprotection, andoptionallyoptional confidentiality to generic fibre channel frames. The CT_Authentication protocol is a transform that provides the same set of securityservices, but is applied toservices for Common Transport Information Units,a protocolwhich are usedforto convey control information.TheAs a result of the separation of Fibre Channel data traffic from controltraffic results intraffic, only one protocol (either ESP_Header or CT_Authentication)beingis applicable to any FC SecurityAssociaton.Association (SA). Security associations for the ESP_Header and CT_Authentication protocols between twofibre channelFibre Channel entities (hosts, disks, or switches) are negotiated by the Fibre Channel Security Association Management Protocol, a generic protocol based on IKEv2[I-D.ietf- ipsec-ikev2-17].[RFC4306]. Since IP is transported over Fibre Channel[RFC2625][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 identifiersare to behave been assigned.4.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].[FC-GS-4]. The CT provides access to a Service(e.g.(e.g., Directory Service) with a set of service parameters that facilitates the usage of Fibre Channel constructs. A Common TransportIUInformation 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 authenticationand optionallyand, optionally, confidentiality to CT_IUs. The CT_IU is completed by an optionalVendor Specific Preambol,Vendor-Specific Preamble and by additional information as defined by the preamble. 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. SecurityAssociationAssociations for the ESP_Header and CT_Authentication protocols are negotiated by the Fibre Channel Security Association Management Protocol.4.1.3.1. ESP_Header ProtocolESP_headerESP_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[RFC2406],[RFC4303], but the scope of the authentication covers the entire FC-2 header. The Destination and Sourcefibre channelFibre 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. 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.4.2.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 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 keyedhashing,hash of the CT_IU, as defined in[RFC2104], of the CT_IU.[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 functionSHA1[NIST.180-1.1995],SHA1 [NIST.180-1.1995], and HMAC-MD5-128 that is based on the cryptographic hash function MD5 [RFC1321].5.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[I-D.ietf-ipsec-ikev2-17][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 INFORMATIONALexchangeexchange, including notification,deletedelete, 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 valuesare to behave been allocated from the new registries created for the IKEv2 protocol[I-D.ietf- ipsec-ikev2-17]. 5.1.[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 insectionSection 3.5 of[I-D.ietf-ipsec- ikev2-17].[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 singleeight (8) octets8-octet Fibre Channel Name: ID TypevalueValue ------- ----- ID_FC_NAMETo be assigned by IANA 5.2.12 4.2. ESP_Header andCT_AUthenticationCT_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 insectionSection 3.3.1 of[I-D.ietf-ipsec- ikev2-17].[RFC4306]. The following protocolIDIDs have been defined to identify the Fibre Channel ESP_Header and the CT_Authentication security protocols: Protocol IDvalueValue ----------- ----- FC_ESP_HEADERTo be assigned by IANA4 FC_CT_AUTHENTICATIONTo be assigned by IANA5 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_HEADEREncryption Integrity,Integrity Encryption, DH Groups FC_CT_AUTHENTICATION Integrity Encryption, DH Groups5.3.4.3. CT_Authentication Protocol Transform Identifiers The CT_Authenticationtransform IDTransform IDs defined for Transform Type 3 (IntegrityAlgorithm),Algorithm) are: Name Number Defined in ---- ------ ---------- AUTH_HMAC_MD5_128To be assigned by IANA6 FC-SP AUTH_HMAC_SHA1_160To be assigned by IANA7 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;insteadinstead, 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.5.4.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 insectionSection 3.13.1 of[I-D.ietf-ipsec-ikev2-17].[RFC4306]. This Traffic Selector Type MUST be supported by any implementation of the Fibre Channel Security Association Management Protocol. Fibre Channel traffic selectors are defined in [FC-SP] as a list of FC address and protocol ranges, as shown in Figure9.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure9:5: Fibre Channel Traffic Selector The following table lists the assigned value for the Fibre Channel Traffic Selector Type field: TS TypevalueValue ------- ----- TS_FC_ADDR_RANGETo be assigned by IANA9 The Starting and Ending Address fields are24 bit24-bit addresses assigned to Fibre Channel names as part of initializing Fibre Channel communications (e.g., for a switched Fibre Channel Fabric, end nodesaquireacquire these identifiers from Fabric Login, FLOGI). The Starting and Ending R_CTL fields are the 8-bit Routing Control identifiers that define the categoryandand, in somecases hecases, the function of the FC frame; see [FC-FS] for details.TheAs a result of the separation of Fibre Channel data traffic from controltraffic results intraffic, only one protocol (either ESP_Header or CT_Authentication)beingis applicable to any FC SecurityAssociaton.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' that idenitifies'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][FC-GS-4] for details.5.5.4.5. Negotiating Security Associations for FC and IP The ESP_header and CT_Authentication protocols are Fibre-Channel- specific security protocols thatappliesapply to Fibre Channel frames only. The values identifying security protocols, transforms,selectorsselectors, and name types defined in this document MUST NOT be used during IKEv2 negotiation for IPsec protocols.6.5. Security Considerations The security considerations in IKEv2[I-D.ietf-ipsec-ikev2-17] apply[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(based(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 ofdata, thendata; there are no theoretical limitations to the size of IKEv2 messages. However, some Fibre Channelend pointendpoint implementations have limited sequencing capabilities for the particular frames used to map IKEv2 messages over Fibre Channel. To address theselimitationslimitations, the Fibre Channel Security Association Management Protocol supports fragmentation of IKEv2 messages (seesectionSection 5.9 of [FC-SP]).In those cases whereIf the IKEv2 messages are long enough to triggerfragmentationfragmentation, 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 (seesectionSection 3.6 of[I-D.ietf-ipsec-ikev2-17]). 7.[RFC4306]). 6. IANA Considerations The standards action of this document establishes the following valuesto beallocated byIANAinIANA in the registries created forthe [I-D.ietf-ipsec-ikev2-17]. AllocateIKEv2 [RFC4306]. Allocated the following value for the IKEv2 Identification Payload ID Types Registry(section(Section 3.5 of[I-D.ietf-ipsec-ikev2-17]):[RFC4306]): ID TypevalueValue ------- ----- ID_FC_NAMETo be assigned by IANA Allocate12 Allocated the following values for the IKEv2 Security Protocol Identifiers Registry(section(Section 3.3.1 of[I-D.ietf-ipsec-ikev2-17]):[RFC4306]): Protocol IDvalueValue ----------- ----- FC_ESP_HEADERTo be assigned by IANA4 FC_CT_AUTHENTICATIONTo be assigned by IANA Allocate5 Allocated the following values for Transform Type 3 (Integrity Algorithm) for the IKEv2 Integrity Algorithm Transform IDs Registry(section(Section 3.3.2 of[I-D.ietf-ipsec-ikev2-17]):[RFC4306]): Name Number ---- ------ AUTH_HMAC_MD5_128To be assigned by IANA6 AUTH_HMAC_SHA1_160To be assigned by IANA Allocate7 Allocated the following value for the IKEv2 Traffic Selector Types Registry(section(Section 3.13.1 of[I-D.ietf-ipsec-ikev2-17]):[RFC4306]): TS TypevalueValue ------- ----- TS_FC_ADDR_RANGETo be assigned by IANA 8.9 7. References8.1. Informative7.1. Normative References[FC-FS] INCITS Technical Commitee T11, "ANSI INCITS 373-2003, "Fibre Channel - Framing and Signaling (FC-FS)". [FC-GS] INCITS Technical Commitee T11, "ANSI INCITS xxx-200x, "Fibre Channel - Generic Services (FC-GS)". [FC-SP] INCITS Technical Commitee T11, "ANSI INCITS xxx-200x, "Fibre Channel - Security Protocols (FC-SP)". [T11] INCITS Technical Commitee T11, "Home Page of the INCITS Technical Commitee T11". 8.2. References [I-D.ietf-ipsec-ikev2-17] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17 (work in progress), September 2004. [NIST.180-1.1995] National Institute[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.[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.[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)". [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", <http://www.t11.org>. Authors' Addresses Fabio Maino Cisco Systems 375 East Tasman Drive San Jose, CA 95134 US Phone: +1 408 853 7530Email: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-7953Email:EMail: black_david@emc.com URI: http://www.emc.com/ 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 PropertyStatementThe 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.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 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. 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. AcknowledgmentAcknowledgement Funding for the RFC Editor function iscurrentlyprovided by theInternet Society.IETF Administrative Support Activity (IASA).