+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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).