Skip to main content

Use of IKEv2 in the Fibre Channel Security Association Management Protocol
draft-maino-fcsp-02

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4595.
Authors David L. Black , Fabio Maino
Last updated 2015-10-14 (Latest revision 2005-09-15)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4595 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Russ Housley
Send notices to (None)
draft-maino-fcsp-02
Network Working Group                                           F. Maino
Internet-Draft                                             Cisco Systems
Expires: March 18, 2006                                         D. Black
                                                         EMC Corporation
                                                      September 14, 2005

   Use of IKEv2 in The Fibre Channel Security Association Management
                                Protocol
                        draft-maino-fcsp-02.txt

Status of this Memo

   By 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 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 updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   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.

   This Internet-Draft will expire on March 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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

Maino & Black            Expires March 18, 2006                 [Page 1]
Internet-Draft               IKEv2 in FC-SP               September 2005

   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.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Fibre Channel Security Protocols . . . . . . . . . . . . . . .  6
     4.1.  ESP_Header Protocol  . . . . . . . . . . . . . . . . . . .  7
     4.2.  CT_Authentication Protocol . . . . . . . . . . . . . . . .  8
   5.  The FC SA Management Protocol  . . . . . . . . . . . . . . . . 10
     5.1.  Fibre Channel Name Identifier  . . . . . . . . . . . . . . 10
     5.2.  ESP_Header and CT_AUthentication Protocol ID . . . . . . . 10
     5.3.  CT_Authentication Protocol Transform Identifiers . . . . . 11
     5.4.  Fibre Channel Traffic Selectors  . . . . . . . . . . . . . 11
     5.5.  Negotiating Security Associations for FC and IP  . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     8.1.  Informative References . . . . . . . . . . . . . . . . . . 16
     8.2.  References . . . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

Maino & Black            Expires March 18, 2006                 [Page 2]
Internet-Draft               IKEv2 in FC-SP               September 2005

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            Expires March 18, 2006                 [Page 3]
Internet-Draft               IKEv2 in FC-SP               September 2005

2.  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 working group of the
   T11 Technical Committee that is developing 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;

   4.  security policies distribution.

   Within this framework a fibre channel device can verify the identity
   of another fibre channel device, establish a shared secret that will
   be used to negotiate security associations for security protocols
   applied to fibre channel frames and information unit.  The same
   framework allows for distributions within a fibre channel fabric of
   policies that will be enforced by the fabric.

   FC-SP is adapting the IKEv2 protocol [I-D.ietf-ipsec-ikev2-17] to
   provide authentication of Fibre Channel entities and setup of
   security associations.

Maino & Black            Expires March 18, 2006                 [Page 4]
Internet-Draft               IKEv2 in FC-SP               September 2005

3.  Overview

   Fibre Channel defines two security protocols that provide security
   services for different portions of Fibre Channel traffic: ESP_Header
   is defined in [FC-FS], while CT_Authentication is defined in [FC-GS].

   The ESP_Header protocol is a transform applied to FC-2 fibre channel
   frames, and is based on the IP Encapsulation Security Payload
   [RFC2406], to provide origin authentication, integrity, anti-replay
   protection and optionally confidentiality to generic fibre channel
   frames.  The CT_Authentication protocol is a transform that provides
   the same set of security services, but is applied to Common Transport
   Information Units, a protocol used for control information.  The
   separation of Fibre Channel data traffic from control traffic results
   in only one protocol (either ESP_Header or CT_Authentication) being
   applicable to any FC Security Associaton.

   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 [I-D.ietf-
   ipsec-ikev2-17].

   Since IP is transported over Fibre Channel [RFC2625] 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 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 specifies the entities for which new identifiers
   are to be assigned.

Maino & Black            Expires March 18, 2006                 [Page 5]
Internet-Draft               IKEv2 in FC-SP               September 2005

4.  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].  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 IU (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 Preambol, and by
   additional information as defined by the preamble.

Maino & Black            Expires March 18, 2006                 [Page 6]
Internet-Draft               IKEv2 in FC-SP               September 2005

    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 Association for the ESP_Header and CT_Authentication
   protocols are negotiated by the Fibre Channel Security Association
   Management Protocol.

4.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 [RFC2406], 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            Expires March 18, 2006                 [Page 7]
Internet-Draft               IKEv2 in FC-SP               September 2005

    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.  CT_Authentication Protocol

   CT_Authentication is a security protocol for Common Transport FC-4
   Information Units that provides origin authentication, integrity,
   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

Maino & Black            Expires March 18, 2006                 [Page 8]
Internet-Draft               IKEv2 in FC-SP               September 2005

   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 hashing,
   as defined in [RFC2104], of the CT_IU.  The entire output of the HMAC
   computation is included in the Authentication Hash Block, without any
   truncation.  Two transforms are defined: HMAC-SHA1-160 based on the
   cryptographic hash function SHA1[NIST.180-1.1995], and HMAC-MD5-128
   based on the cryptographic hash function MD5 [RFC1321].

Maino & Black            Expires March 18, 2006                 [Page 9]
Internet-Draft               IKEv2 in FC-SP               September 2005

5.  The FC SA Management Protocol

   Fibre Channel entities negotiate security associations for the
   protocols described above 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]
   that performs the same core operations, and 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 are to be allocated
   from the new registries created for the IKEv2 protocol [I-D.ietf-
   ipsec-ikev2-17].

5.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 [I-D.ietf-ipsec-
   ikev2-17].  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 eight (8) octets
   Fibre Channel Name:

           ID Type                       value
           -------                       -----
           ID_FC_NAME                    To be assigned by IANA

5.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 [I-D.ietf-ipsec-
   ikev2-17].

Maino & Black            Expires March 18, 2006                [Page 10]
Internet-Draft               IKEv2 in FC-SP               September 2005

   The following protocol ID have been defined to identify the Fibre
   Channel ESP_Header and the CT_Authentication security protocols:

           Protocol ID             value
           -----------             -----
           FC_ESP_HEADER           To be assigned by IANA

           FC_CT_AUTHENTICATION    To be assigned by IANA

   The existing IKEv2 value for ESP (3) is deliberately not reused 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            Encryption     Integrity, DH Groups

           FC_CT_AUTHENTICATION     Integrity      Encryption, DH Groups

5.3.  CT_Authentication Protocol Transform Identifiers

   The CT_Authentication transform ID defined for Transform Type 3
   (Integrity Algorithm), are:

           Name                   Number                    Defined in
           ----                   ------                    ----------
           AUTH_HMAC_MD5_128      To be assigned by IANA    FC-SP

           AUTH_HMAC_SHA1_160     To be assigned by IANA    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.

5.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

Maino & Black            Expires March 18, 2006                [Page 11]
Internet-Draft               IKEv2 in FC-SP               September 2005

   Registry defined in section 3.13.1 of [I-D.ietf-ipsec-ikev2-17].
   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 Figure 9.

    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 9: 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       To be assigned by IANA

   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
   aquire 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 he function of
   the FC frame; see [FC-FS] for details.

   The separation of Fibre Channel data traffic from control traffic
   results in only one protocol (either ESP_Header or CT_Authentication)
   being applicable to any FC Security Associaton.  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 CT_Authentication
   information units, and the Starting Type and Ending Type fields
   identify the range of Generic Service subtypes (GS_Subtype) to be

Maino & Black            Expires March 18, 2006                [Page 12]
Internet-Draft               IKEv2 in FC-SP               September 2005

   selected.  See [FC-FS] and [FC-GS] for details.

5.5.  Negotiating Security Associations for FC and IP

   The ESP_header and CT_Authentication protocols are Fibre-Channel-
   specific security protocols that applies 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.

Maino & Black            Expires March 18, 2006                [Page 13]
Internet-Draft               IKEv2 in FC-SP               September 2005

6.  Security Considerations

   The security considerations in IKEv2 [I-D.ietf-ipsec-ikev2-17] 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 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, then there are no theoretical limitations to the
   size of IKEv2 messages.  However, some Fibre Channel end point
   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]).  In those cases where 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 [I-D.ietf-ipsec-ikev2-17]).

Maino & Black            Expires March 18, 2006                [Page 14]
Internet-Draft               IKEv2 in FC-SP               September 2005

7.  IANA Considerations

   The standards action of this document establishes the following
   values to be allocated by IANAin the registries created for the
   [I-D.ietf-ipsec-ikev2-17].

   Allocate the following value for the IKEv2 Identification Payload ID
   Types Registry (section 3.5 of [I-D.ietf-ipsec-ikev2-17]):

           ID Type                 value
           -------                 -----
           ID_FC_NAME              To be assigned by IANA

   Allocate the following values for the IKEv2 Security Protocol
   Identifiers Registry (section 3.3.1 of [I-D.ietf-ipsec-ikev2-17]):

           Protocol ID             value
           -----------             -----
           FC_ESP_HEADER           To be assigned by IANA

           FC_CT_AUTHENTICATION    To be assigned by IANA

   Allocate the following values for Transform Type 3 (Integrity
   Algorithm) for the IKEv2 Integrity Algorithm Transform IDs Registry
   (section 3.3.2 of [I-D.ietf-ipsec-ikev2-17]):

           Name                    Number
           ----                    ------
           AUTH_HMAC_MD5_128        To be assigned by IANA

           AUTH_HMAC_SHA1_160      To be assigned by IANA

   Allocate the following value for the IKEv2 Traffic Selector Types
   Registry (section 3.13.1 of [I-D.ietf-ipsec-ikev2-17]):

           TS Type                 value
           -------                 -----
           TS_FC_ADDR_RANGE        To be assigned by IANA

Maino & Black            Expires March 18, 2006                [Page 15]
Internet-Draft               IKEv2 in FC-SP               September 2005

8.  References

8.1.  Informative 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 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.,

Maino & Black            Expires March 18, 2006                [Page 16]
Internet-Draft               IKEv2 in FC-SP               September 2005

              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.

Maino & Black            Expires March 18, 2006                [Page 17]
Internet-Draft               IKEv2 in FC-SP               September 2005

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 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            Expires March 18, 2006                [Page 18]
Internet-Draft               IKEv2 in FC-SP               September 2005

Intellectual Property Statement

   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.

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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Maino & Black            Expires March 18, 2006                [Page 19]