authentication using digital certificates. Peer authentication using
public key encryption methods outlined in IKE [14] sections 5.2 and
5.3 SHOULD NOT be used.
IKE Phase 1 establishes a secure, MAC-authenticated channel for
communications for use by IKE Phase 2. FCIP implementations MUST
support IKE Main Mode and SHOULD support Aggressive Mode.
IKE Phase 1 exchanges MUST explicitly carry the Identification
Payload fields (IDii and IDir). Conformant FCIP implementations MUST
use ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6),
or ID_FQDN Identification Type values. The ID_USER_FQDN, IP Subnet,
IP Address Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification
Type values SHOULD NOT be used. The ID_KEY_ID Identification Type
values MUST NOT be used. As described in [13], the port and protocol
fields in the Identification Payload MUST be set to zero or UDP port
500.
FCIP Entities negotiate parameters for SA during IKE Phase 2 only
using "Quick Mode". For FCIP Entities engaged in IKE "Quick Mode",
there is no requirement for PFS (Perfect Forward Secrecy). FCIP
implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR
Identification Type values (based on the version of IP supported).
Other Identification Type values MUST NOT be used.
Since the number of Phase 2 SAs may be limited, Phase 2 delete
messages may be sent for idle SAs. The receipt of a Phase 2 delete
message SHOULD NOT be interpreted as a reason for tearing down an
FCIP Link or any of its TCP connections. When there is new activity
on that idle link, a new Phase 2 SA MUST be re-established.
For a given pair of FCIP Entities, the same IKE Phase 1 negotiation
can be used for all Phase 2 negotiations; i.e., all TCP Connections
that are bundled into the single FCIP Link can share the same Phase 1
results.
Repeated rekeying using "Quick Mode" on the same shared secret will
reduce the cryptographic properties of that secret over time. To
overcome this, Phase 1 SHOULD be invoked periodically to create a new
set of IKE shared secrets and related security parameters.
IKE Phase 1 establishment requires the following key distribution and
FCIP Entities:
- MUST support pre-shared IKE keys.
- MAY support certificate-based peer authentication using digital
signatures.
- SHOULD NOT use peer authentication using the public key encryption
methods outlined in sections 5.2 and 5.3 of [14].
When pre-shared keys are used, IKE Main Mode is usable only when both
peers of an FCIP Link use statically assigned IP addresses. When
support for dynamically assigned IP Addresses is attempted in
conjunction with Main Mode, use of group pre-shared keys would be
forced, and the use of group pre-shared keys in combination with Main
Mode is not recommended as it exposes the deployed environment to
man-in-the-middle attacks. Therefore, if either peer of an FCIP Link
uses dynamically assigned addresses, Aggressive Mode SHOULD be used
and Main Mode SHOULD NOT be used.
When Digital Signatures are used, either IKE Main Mode or IKE
Aggressive Mode may be used. In all cases, access to locally stored
secret information (pre-shared key, or private key for digital
signing) MUST be suitably restricted, since compromise of secret
information nullifies the security properties of IKE/IPsec protocols.
Such mechanisms are outside the scope of this document. Support for
IKE Oakley Groups [27] is not required.
For the purpose of establishing a secure FCIP Link, the two
participating FCIP Entities consult a Security Policy Database (SPD).
The SPD is described in IPsec [10] Section 4.4.1. FCIP Entities may
have more than one interface and IP Address, and it is possible for
an FCIP Link to contain multiple TCP connections whose FCIP endpoint
IP Addresses are different. In this case, an IKE Phase 1 SA is
established for each FCIP endpoint IP Address pair. Within IKE Phase
1, FCIP implementations must support the ID_IPV4_ADDR, ID_IPV6_ADDR
(if the protocol stack supports IPv6), and ID_FQDN Identity Payloads.
If FCIP Endpoint addresses are dynamically assigned, it may be
beneficial to use ID_FQDN, and for this reason, IP_FQDN Identity
Payload MUST be supported. Other identity payloads (ID_USER_FQDN,
ID_DER_ASN1_GN, ID_KEY_ID) SHOULD NOT be used.
At the end of successful IKE negotiations both FCIP Entities store
the SA parameters in their SA database (SAD). The SAD is described
in IPsec [10] Section 4.4.3. The SAD contains the set of active SA
entries, each entry containing Sequence Counter Overflow, Sequence
Number Counter, Anti-replay Window, and the Lifetime of the SA. FCIP
Entities SHALL employ a default SA Lifetime of one hour and a default
Anti-replay window of 32 sequence numbers.
When a TCP Connection is established between two FCIP_DEs, two
unidirectional SAs are created for that connection and each SA is
identified in the form of a Security Parameter Index (SPI). One SA
is associated with the incoming traffic flow and the other SA is
associated with the outgoing traffic flow. The FCIP_DEs at each end
of the TCP connection MUST maintain the SPIs for both its incoming
and outgoing FCIP Encapsulated Frames.
FCIP Entities MAY provide administrative management of
Confidentiality usage. These management interfaces SHOULD be
provided in a secure manner, so as to prevent an attacker from
subverting the security process by attacking the management
interface.
9.3.3. ESP Replay Protection and Rekeying Issues
FCIP Entities MUST implement Replay Protection against ESP Sequence
Number wrap, as described in [14]. In addition, based on the cipher
algorithm and the number of bits in the cipher block size, the
validity of the key may become compromised. In both cases, the SA
needs to be re-established.
FCIP Entities MUST use the results of IKE Phase 1 negotiation for
initiating an IKE Phase 2 "Quick Mode" exchange and establish new
SAs.
To enable smooth transition of SAs, it is RECOMMENDED that both FCIP
Entities refresh the SPI when the sequence number counter reaches
2^31 (i.e., half the sequence number space). It also is RECOMMENDED
that the receiver operate with multiple SPIs for the same TCP
Connection for a period of 2^31 sequence number packets before aging
out an SPI.
When a new SPI is created for the outgoing direction, the sending
side SHALL begin using it for all new FCIP Encapsulated Frames.
Frames that are either in-flight, or re-sent due to TCP
retransmissions, etc. MAY use either the new SPI or the one being
replaced.
9.4. Secure FCIP Link Operation
9.4.1. FCIP Link Initialization Steps
FCIP implementations may allow enabling and disabling security
mechanisms at the granularity of an FCIP Link. If enabled, the
following FCIP Link Initialization steps MUST be followed.
When an FCIP Link is initialized, before any FCIP TCP Connections are
established, the local SPD is consulted to determine if IKE Phase 1
has been completed with the FCIP Entity in the peer FCIP Entity, as
identified by the WWN.
If Phase 1 is already completed, IKE Phase 2 proceeds. Otherwise,
IKE Phase 1 MUST be completed before IKE Phase 2 can start. Both IKE
Phase 1 and Phase 2 transactions use UDP Port 500. If IKE Phase 1
fails, the FCIP Link initialization terminates and notifies the FC
entity with the reason for the termination. Otherwise, the FCIP Link
initialization moves to TCP Connection Initialization.
As described in section 8.1, FCIP Entities exchange an FSF for
forming an FCIP Link. The use of ESP Confidentiality is an effective
countermeasure against any perceived security risks of FSF.
9.4.2. TCP Connection Security Associations (SAs)
Each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic
from one or more than one TCP connection may flow within each IPsec
Phase 2 SA. While it is possible for an IKE Phase 2 SA to protect
multiple TCP connections, all packets of a TCP connection are
protected using only one IKE Phase 2 SA.
If different Quality of Service settings are applied to TCP
connections, it is advisable to use a different IPsec SA for these
connections. Attempting to apply a different quality of service to
connections handled by the same IPsec SA can result in reordering,
and falling outside the replay window. For additional details, see
[21].
FCIP implementations need not verify that the IP addresses and port
numbers in the packet match any locally stored per-connection values,
leaving this check to be performed by the IPsec layer.
An implementation is free to perform several IKE Phase 2 negotiations
and cache them in its local SPIs, although entries in such a cache
can be flushed per current SA Lifetime settings.
9.4.3. Handling Data Integrity and Confidentiality Violations
Upon datagram reception, when the ESP packet fails an integrity
check, the receiver MUST drop the datagram, which will trigger TCP
retransmission. If many such datagrams are dropped, a receiving FCIP
Entity MAY close the TCP Connection and notify the FC Entity with the
reason for the closure.
An implementation SHOULD follow guidelines for auditing all auditable
ESP events per IPsec [10] Section 7.
Integrity checks MUST be performed if Confidentiality is enabled.
10. Performance
10.1. Performance Considerations
Traditionally, the links between FC Fabric components have been
characterized by low latency and high throughput. The purpose of
FCIP is to provide functionality equivalent to these links using an
IP Network, where low latency and high throughput are not as certain.
It follows that FCIP Entities and their counterpart FC Entities
probably will be interested in optimal use of the IP Network.
Many options exist for ensuring high throughput and low latency
appropriate for the distances involved in an IP Network. For
example, a private IP Network might be constructed for the sole use
of FCIP Entities. The options that are within the scope of this
specification are discussed here.
One option for increasing the probability that FCIP data streams will
experience low latency and high throughput is the IP QoS techniques
discussed in section 10.2. This option can have value when applied
to a single TCP Connection. Depending on the sophistication of the
FC Entity, further value may be obtained by having multiple TCP
Connections with differing QoS characteristics.
There are many reasons why an FC Entity might request the creation of
multiple TCP Connections within an FCIP_LEP. These reasons include a
desire to provide differentiated services for different TCP data
connections between FCIP_LEPs, or a preference to separately queue
different streams of traffic not having a common in-order delivery
requirement.
At the time a new TCP Connection is created, the FC Entity SHALL
specify to the FCIP Entity the QoS characteristics (including but not
limited to IP per-hop-behavior) to be used for the lifetime of that
connection. This MAY be achieved by having:
a) only one set of QoS characteristics for all TCP Connections;
b) a default set of QoS characteristics that the FCIP Entity applies
in the absence of differing instructions from the FC Entity; or
c) a sophisticated mechanism for exchanging QoS requirements
information between the FC Entity and FCIP Entity each time a new
TCP Connection is created.
Once established, the QoS characteristics of a TCP Connection SHALL
NOT be changed, since this specification provides no mechanism for
the FC Entity to control such changes. The mechanism for providing
different QoS characteristics in FCIP is the establishment of a
different TCP Connections and associated FCIP_DEs.
When FCIP is used with a network with a large (bandwidth*delay)
product, it is RECOMMENDED that FCIP_LEPs use the TCP mechanisms
(window scaling and wrapped sequence protection) for Long Fat
Networks (LFNs) as defined in RFC 1323 [24].
10.2. IP Quality of Service (QoS) Support
Many methods of providing QoS have been devised or proposed. These
include (but are not limited to) the following:
- Multi-Protocol Label Switching (MPLS) -- RFC 3031 [32]
- Differentiated Services Architecture (diffserv) -- RFC 2474 [28],
RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31] -- and other forms
of per-hop-behavior (PHB)
- Integrated Services, RFC 1633 [25]
- IEEE 802.1p
The purpose of this specification is not to specify any particular
form of IP QoS, but rather to specify only those issues that must be
addressed in order to maximize interoperability between FCIP
equipment that has been manufactured by different vendors.
It is RECOMMENDED that some form of preferential QoS be used for FCIP
traffic to minimize latency and packet drops. No particular form of
QoS is recommended.
If a PHB IP QoS is implemented, it is RECOMMENDED that it
interoperate with diffserv (see RFC 2474 [28], RFC 2475 [29], RFC
2597 [30], and RFC 2598 [31]).
If no form of preferential QoS is implemented, the DSCP field SHOULD
be set to ’000000’ to avoid negative impacts on other network
components and services that may be caused by uncontrolled usage of
non-zero values of the DSCP field.
11. References
11.1. Normative References
The references in this section were current as of the time this
specification was approved. This specification is intended to
operate with newer versions of the referenced documents and looking
for newer reference documents is recommended.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Fibre Channel Backbone (FC-BB), ANSI INCITS.342:2001, December
12, 2001.
[3] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July
25, 2003.
[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI INCITS.355:2001,
December 12, 2001.
[5] Fibre Channel Framing and Signaling (FC-FS), ANSI
INCITS.373:2003, October 27, 2003.
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[7] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, October 1989.
[8] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[10] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing
for Message Authentication", RFC 2104, February 1997.
[12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[13] Piper, D., "The Internet IP Security Domain of Interpretation of
ISAKMP", RFC 2407, November 1998.
[14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
Use With IPsec", RFC 2410, November 1998.
[16] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms",
RFC 2451, November 1998.
[17] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, version 2", RFC 2608, July 1999.
[18] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "SACK
Extension", RFC 2883, July 2000.
[19] Weber, R., Rajagopal, M., Travostino, F., O’Donnell, M., Monia,
C. and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC
3643, December 2003.
[20] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities
Using Service Location Protocol version 2 (SLPv2)", RFC 3822,
July 2004.
[21] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino,
"Securing Block Storage Protocols over IP", RFC 3723, April
2004.
[22] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[23] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and
Its Use With IPsec", RFC 3566, September 2003.
11.2. Informative References
[24] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[25] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[26] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 2030, October 1996.
[27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412,
November 1998.
[28] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
Ipv6 Headers", RFC 2474, December 1998.
[29] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[30] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "An
Assured Forwarding PHB", RFC 2597, June 1999.
[31] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
Forwarding PHB Group", RFC 2598, June 1999.
[32] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January, 2001.
[33] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host
Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel
Mode", RFC 3456, January 2003.
[34] Kembel, R., "The Fibre Channel Consultant: A Comprehensive
Introduction", Northwest Learning Associates, 1998.
12. Acknowledgments
The developers of this specification thank Mr. Jim Nelson for his
assistance with FC-FS related issues.
The developers of this specification express their appreciation to
Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed
and helpful reviews.
Appendix A - Fibre Channel Bit and Byte Numbering Guidance
Both Fibre Channel and IETF standards use the same byte transmission
order. However, the bit and byte numbering is different.
Fibre Channel bit and byte numbering can be observed if the data
structure heading, shown in figure 11, is cut and pasted at the top
of figure 7, figure 9, and figure 17.
W|------------------------------Bit------------------------------|
o| |
r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 |
d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
Figure 11: Fibre Channel Data Structure Bit and Byte Numbering
Fibre Channel bit numbering for the pFlags field can be observed if
the data structure heading, shown in figure 12, is cut and pasted at
the top of figure 8.
|----------------Bit--------------------|
| |
| 31 30 29 28 27 26 25 24 |
Figure 12: Fibre Channel pFlags Bit Numbering
Fibre Channel bit numbering for the Connection Usage Flags field can
be observed if the data structure heading, shown in figure 13, is cut
and pasted at the top of figure 10.
|------------------------------Bit------------------------------|
| |
| 31 30 29 28 27 26 25 24 |
Figure 13: Fibre Channel Connection Usage Flags Bit Numbering
Appendix B - IANA Considerations
IANA has made the following port assignments to FCIP:
- fcip-port 3225/tcp FCIP
- fcip-port 3225/udp FCIP
IANA has changed the authority for these port allocations to
reference this RFC.
Use of UDP with FCIP is prohibited even though IANA has allocated a
port.
The FC Frame encapsulation used by this specification employs
Protocol# value 1, as described in the IANA Considerations appendix
of the FC Frame Encapsulation [19] specification.
Appendix C - FCIP Usage of Addresses and Identifiers
In support of network address translators, FCIP does not use IP
Addresses to identify FCIP Entities or FCIP_LEPs. The only use of IP
Addresses for identification occurs when initiating new TCP connect
requests (see section 8.1.2.3) where the IP Address destination of
the TCP connect request is used to answer the question: "Have
previous TCP connect requests been made to the same destination FCIP
Entity?" The correctness of this assumption is further checked by
sending the Destination FC Fabric Entity World Wide Name in the FCIP
Special Frame (FSF) and having the value checked by the FCIP Entity
that receives the TCP connect request and FSF (see section 8.1.3).
For the purposes of processing incoming TCP connect requests, the
source FCIP Entity is identified by the Source FC Fabric Entity World
Wide Name and Source FC/FCIP Entity Identifier fields in the FSF sent
from the TCP connect requestor to the TCP connect recipient as the
first bytes following the TCP connect request (see section 8.1.2.3
and section 8.1.3).
FC-BB-2 [3] provides the definitions for each of the following FSF
fields:
- Source FC Fabric Entity World Wide Name,
- Source FC/FCIP Entity Identifier, and
- Destination FC Fabric Entity World Wide Name.
As described in section 8.1.3, FCIP Entities segregate their
FCIP_LEPs between:
- Connections resulting from TCP connect requests initiated by the
FCIP Entity, and
- Connections resulting from TCP connect requests received by the
FCIP Entity.
Within each of these two groups, the following information is used to
further identify each FCIP_LEP:
- Source FC Fabric Entity World Wide Name,
- Source FC/FCIP Entity Identifier, and
- Destination FC Fabric Entity World Wide Name.
Appendix D - Example of Synchronization Recovery Algorithm
The contents of this annex are informative.
Synchronization may be recovered as specified in section 5.6.2.3. An
example of an algorithm for searching the bytes delivered to the
Encapsulated Frame Receiver Portal for a valid FCIP Frame header is
provided in this annex.
This resynchronization uses the principle that a valid FCIP data
stream must contain at least one valid header every 2176 bytes (the
maximum length of an encapsulated FC Frame). Although other data
patterns containing apparently valid headers may be contained in the
stream, the FC CRC or FCIP Frame validity of the data patterns
contained in the data stream will always be either interrupted by or
resynchronized with the valid FCIP Frame headers.
Consider the case shown in figure 14. A series of short FCIP Frames,
perhaps from a trace, are embedded in larger FCIP Frames, say as a
result of a trace file being transferred from one disk to another.
The headers for the short FCIP Frames are denoted SFH and the long
FCIP Frame headers are marked as LFH.
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
|L| |S| |S| |S| |S| |L| |S|
|F| |F| |F| |F| |F| |F| |F|...
|H| |H| |H| |H| |H| |H| |H|
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
| |
|<---------2176 bytes-------->|
Figure 14: Example of resynchronization data stream