RFC 4595 INFORMATIONAL SECURITY · FIBRE CHANNEL · CRYPTOGRAPHY
IKEv2 for Fibre Channel: Use of IKEv2 in the Fibre Channel Security Association Management Protocol
Adapting IKEv2 to secure Fibre Channel networks
RFC EDITOR
Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, DOI 10.17487/RFC4595, July 2006, <https://www.rfc-editor.org/info/rfc4595>.
BIBTEX
@misc{rfc4595,
series = {Request for Comments},
number = 4595,
howpublished = {RFC 4595},
publisher = {RFC Editor},
doi = {10.17487/RFC4595},
url = {https://www.rfc-editor.org/info/rfc4595},
author = {F. Maino and D. Black},
title = {{Use of IKEv2 in the Fibre Channel Security Association Management Protocol}},
pagetotal = 16,
year = 2006,
month = jul,
} RFC text
Contents
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.
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
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].
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.
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.
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.
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
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].
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:
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.
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.
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]).
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
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)".
[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 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/
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).
AI ELI5
On this page
PROBLEMFibre Channel (a high-speed storage network) needs to authenticate devices and establish security associations, similar to how IKEv2 does it for IP networks. But Fibre Channel has different security protocols and message structures than IP.
MECHANISMRFC 4595 specifies Fibre-Channel-specific extensions to IKEv2: new security protocol identifiers for Fibre Channel's ESP_Header and CT_Authentication, new transform algorithms, and a new address type for Fibre Channel names. This allows IKEv2 to negotiate security associations for FC without confusion with IP security.
WHY IT MATTERSFibre Channel networks can use a standards-based, familiar key-negotiation protocol (IKEv2) adapted for their environment, and mixing IKEv2 for IP and Fibre Channel on the same network is made impossible by using different identifiers.
§1Why Fibre Channel Needs Its Own Security
Fibre Channel (FC) is a gigabit-speed network technology standardized by the T11 committee primarily for storage networking. Unlike Ethernet, which is designed for general-purpose networks, Fibre Channel has dedicated protocols and frame formats for moving data between servers and storage arrays.
The Fibre Channel Security Protocols (FC-SP) standard defines a security architecture that provides device-to-device authentication, secret establishment, and data protection. To manage secrets and negotiate security associations, FC-SP adapted IKEv2, the Internet Key Exchange protocol used for IP networks. However, Fibre Channel's security protocols, transforms, and device identifiers differ from IP's. This document specifies those extensions so that IKEv2 can work for Fibre Channel without accidental confusion between IP-based IKEv2 negotiations and FC-based IKEv2 negotiations on the same network.
Storage networks need to verify that devices are real and set up secret conversations. IKEv2 is a standard way to do this, but storage uses different formats than the Internet, so special codes are needed so each knows what the other is talking about.
§2Fibre Channel Security Protocols
Fibre Channel defines two security protocols at different layers. ESP_Header (based on IP Encapsulating Security Payload, RFC 4303) protects FC-2 frames with origin authentication, integrity, anti-replay protection, and optional confidentiality. It is carried as an optional header in the FC-2 frame. The scope of authentication covers the entire FC-2 header and payload, with normalization of addresses (D_ID and S_ID) to allow for address translation in networks.
CT_Authentication protects Common Transport Information Units (CT_IUs) used for control traffic at the FC-4 level. It provides origin authentication, integrity, and anti-replay. The authentication uses a keyed hash (HMAC-SHA1-160 or HMAC-MD5-128) computed over the entire CT_IU except headers and CRC fields. Because data and control traffic are separate, only one protocol (either ESP_Header or CT_Authentication) applies to any single Fibre Channel Security Association.
Storage traffic comes in two kinds: data and control messages. Each kind has its own way to add security protection. The data way is like wrapping a letter in an envelope with a seal. The control way adds a signature to prove the message is real.
§3New IKEv2 Identifiers for Fibre Channel
To adapt IKEv2 for Fibre Channel, RFC 4595 allocates new identifier values in the IKEv2 registries.
ID Type: Fibre Channel entities are identified by an 8-byte Name (not IP addresses). A new ID type ID_FC_NAME (value 12) is defined to carry these names in the IKEv2 Identification Payload.
Protocol IDs: Security protocols are identified in the IKEv2 Security Association Payload. New values identify FC security protocols: FC_ESP_HEADER (value 4) and FC_CT_AUTHENTICATION (value 5). Deliberately not reusing the existing IP ESP value (3) prevents confusion and ensures negotiation failure if an IP endpoint accidentally meets an FC endpoint.
Transform IDs: For CT_Authentication, two new integrity transforms are defined: AUTH_HMAC_MD5_128 (value 6) and AUTH_HMAC_SHA1_160 (value 7). These differ from IPsec's corresponding transforms by omitting truncation of the HMAC output: MD5 produces 128 bits (not 96) and SHA-1 produces 160 bits (not 96).
Traffic Selector Type: A new value TS_FC_ADDR_RANGE (value 9) defines Fibre Channel traffic selectors as lists of FC addresses and protocol ranges, rather than IP addresses and ports.
IKEv2 uses numbered codes for different things: how to name a device, what kind of security, how to compute signatures, and what kind of traffic to protect. New numbers are assigned so Fibre Channel can use different formats without breaking IP's system.
§4Using IKEv2 for Fibre Channel Security Associations
The Fibre Channel Security Association Management Protocol is a modified subset of IKEv2 (RFC 4306). It supports the basic IKEv2 exchanges: initial exchange to establish the IKE SA and first child SA, CREATE_CHILD_SA to negotiate additional SAs, and INFORMATIONAL exchanges (for notifications, deletes, and vendor IDs). Features not supported in FC include: negotiation of multiple protocols in one proposal, multiple outstanding requests, cookies, configuration payload, and the Extensible Authentication Protocol (EAP).
IKEv2 messages are carried over Fibre Channel using the FC AUTH protocol. A Fibre Channel Sequence can carry up to 4 GB of data, so there are no theoretical message size limits. However, some FC endpoints have limited sequencing capabilities, so the FC SA Management Protocol supports fragmentation of IKEv2 messages (as defined in the FC-SP standard). To minimize denial-of-service risks from reassembly buffer exhaustion, endpoints should use Hash and URL encodings instead of sending full certificates when possible.
IKEv2 messages get packaged up and sent over Fibre Channel's wire format instead of IP. Most of IKEv2's basic features work; some advanced features that are only useful for IP networks are left out.
§5Security Implications
The security considerations of IKEv2 (RFC 4306) apply to Fibre Channel IKEv2, with exceptions for features that do not apply. NAT traversal and EAP are not supported by the Fibre Channel Security Association Management Protocol, so those IKEv2 security considerations do not apply. IP fragmentation is not a concern because Fibre Channel does not use IP.
The main security risk is denial-of-service via reassembly buffer exhaustion if an attacker sends fragmented IKEv2 messages that are not completed. Endpoints should limit reassembly resources and prefer Hash and URL encodings over certificates to keep messages short. The use of distinct protocol identifiers for Fibre Channel (4 and 5, not IP's 3) ensures that any accidental mismatch between an IP-based and FC-based IKEv2 peer will be detected as a negotiation failure, preventing subtle security issues from crossed protocols.
Fibre Channel IKEv2 follows the same security rules as IP's IKEv2. The main protection is that if an IP system tries to talk to an FC system, they will immediately recognize they are incompatible and stop, preventing confusion.
§6References
[RFC2104]RFC 2104Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.February 1997[RFC2119]RFC 2119Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.March 1997[RFC3602]RFC 3602Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.September 2003[RFC3643]RFC 3643Weber, R. et al., "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003.December 2003[RFC4303]RFC 4303Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.December 2005[RFC4306]RFC 4306Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.December 2005