RFC 3821
Fibre Channel Over TCP/IP (FCIP)
6. Checking FC Frame Transit Times in the IP Network
FC-BB-2 [3] defines how the measurement of IP Network transit time is performed, based on the requirements stated in the FC Frame Encapsulation [19] specification. The choice to place this implementation requirement on the FC Entity is based on a desire to include the transit time through the FCIP Entities when computing the IP Network transit time experienced by the FC Frames. Each FC Frame that enters the FCIP_DE through the FC Frame Receiver Portal SHALL be accompanied by a time stamp value that the FCIP_DE SHALL place in the Time Stamp [integer] and Time Stamp [fraction] fields of the encapsulation header of the FCIP Frame that contains the FC Frame. If no synchronized time stamp value is available to accompany the entering FC Frame, a value of zero SHALL be used. Each FC Frame that exits the FCIP_DE through the FC Frame Transmitter Portal SHALL be accompanied by the time stamp value taken from the FCIP Frame that encapsulated the FC Frame. The FC Entity SHALL use suitable internal clocks and either Fibre Channel services or an SNTP Version 4 server [26] to establish and maintain the required synchronized time value. The FC Entity SHALL verify that the FC Entity it is communicating with on an FCIP Link is using the same synchronized time source, either Fibre Channel services or SNTP server. Note that since the FC Fabric is expected to have a single synchronized time value throughout, reliance on the Fibre Channel services means that only one synchronized time value is needed for all FCIP_DEs regardless of their connection characteristics.
7. The FCIP Special Frame (FSF)
7.1. FCIP Special Frame Format
Figure 9 shows the FSF format. W|------------------------------Bit------------------------------| o| | r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3| d|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| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 1| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 2| pFlags | Reserved | -pFlags | -Reserved | | | (0x00) | | (0xFF) | +-----------+---+---------------+-----------+---+---------------+ 3| Flags | Frame Length | -Flags | -Frame Length | | (0b000000)| (0b0000010011) | (0b111111)| (0b1111101100) | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC (Reserved in FCIP) | | (0x00-00-00-00) | +-------------------------------+-------------------------------+ 7| Reserved | -Reserved | | (0x00-00) | (0xFF-FF) | +-------------------------------+-------------------------------+ 8| | +----- Source FC Fabric Entity World Wide Name -----+ 9| | +---------------------------------------------------------------+ 10| | +----- Source FC/FCIP Entity Identifier -----+ 11| | +---------------------------------------------------------------+ 12| | +----- Connection Nonce -----+ 13| | +---------------+---------------+-------------------------------+ (Continued) Figure 9: FSF Format (part 1 of 2)
W|------------------------------Bit------------------------------| o| | r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3| d|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| | | | (Concluded) | +---------------------------------------------------------------+ 14| Connection | Reserved | Connection Usage Code | | Usage Flags | (0x00) | <defined in FC-BB-2> | +---------------+---------------+-------------------------------+ 15| | +----- Destination FC Fabric Entity World Wide Name -----+ 16| | +---------------------------------------------------------------+ 17| K_A_TOV | +-------------------------------+-------------------------------+ 18| Reserved | -Reserved | | (0x00-00) | (0xFF-FF) | +-------------------------------+-------------------------------+ Figure 9: FSF Format (part 2 of 2) The FSF SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection, and only one FSF SHALL be transmitted in each direction. The contents of the FSF SHALL be as described for encapsulated FC Frames, except for the fields described in this section. All FSFs SHALL have the pFlags SF bit set to 1 (see section 5.6.1). The Source FC Fabric Entity World Wide Name field SHALL contain the Fibre Channel Name_Identifier [5] for the FC Fabric entity associated with the FC/FCIP Entity pair that generates (as opposed to echoes) the FSF. For example, if the FC Fabric entity is a FC Switch, the FC Fabric Entity World Wide Name field SHALL contain the Switch_Name [4]. The Source FC Fabric Entity World Wide Name SHALL be world wide unique. The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier for the FC/FCIP Entity pair that generates (as opposed to echoes) the FSF. The value is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field. Note: The combination of the Source FC Entity World Wide Name and Source FC/FCIP Entity Identifier fields uniquely identifies every FC/FCIP Entity pair in the IP Network.
The Connection Nonce field shall contain a 64-bit random number generated to uniquely identify a single TCP connect request. In order to provide sufficient security for the connection nonce, the Randomness Recommendations for Security [9] SHOULD be followed. The Connection Usage Flags field identifies the types of SOF values [19] to be carried on the connection as shown in figure 10. |------------------------------Bit------------------------------| | | | 0 1 2 3 4 5 6 7 | +-------+-------+-------+-------+-------------------------------+ | SOFf | SOF?2 | SOF?3 | SOF?4 | Reserved | +-------+-------+-------+-------+-------------------------------+ Figure 10: Connection Usage Flags Field Format If the SOFf bit is one, then FC Frames containing SOFf are intended to be carried on the connection. If the SOF?2 bit is one, then FC Frames containing SOFi2 and SOFn2 are intended to be carried on the connection. If the SOF?3 bit is one, then FC Frames containing SOFi3 and SOFn3 are intended to be carried on the connection. If the SOF?4 bit is one, then FC Frames containing SOFi4, SOFn4, and SOFc4 are intended to be carried on the connection. All or none of the SOFf, SOF?2, SOF?3, and SOF?4 bits MAY be set to one. If all of the SOFf, SOF?2, SOF?3, and SOF?4 bits are zero, then the types of FC Frames intended to be carried on the connection have no specific relationship to the SOF code. The FCIP Entity SHALL NOT enforce the SOF usage described by the Connection Usage Flags field and SHALL only use the contents of the field as described below. The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2 [3].
The FCIP Entity SHALL use the contents of the Connection Usage Flags and Connection Usage Code fields to locate appropriate QoS settings in the "shared" database of TCP Connection information (see section 8.1.1) and apply those settings to a newly formed connection. The Destination FC Fabric Entity World Wide Name field MAY contain the Fibre Channel Name_Identifier [5] for the FC Fabric entity associated with the FC/FCIP Entity pair that echoes (as opposed to generates) the Special Frame. The K_A_TOV field SHALL contain the FC Keep Alive Timeout value to be applied to the new TCP Connection as specified in FC-BB-2 [3]. For each new incoming TCP connect request and subsequent FSF received, the FCIP Entity SHALL send the contents of the Source FC Fabric Entity World Wide Name, Source FC/FCIP Identifier, Connection Usage Flags and Connection Usage Code fields to the FC Entity along with the other connection information (e.g., FCIP_LEP and FCIP_DE information).7.2. Overview of FSF Usage in Connection Establishment
When a new TCP Connection is established, an FCIP Special Frame makes one round trip from the FCIP Entity initiating the TCP connect operation to the FCIP Entity receiving the TCP connect request and back. This FSF usage serves three functions: - Identification of the FCIP Link endpoints - Conveyance of a few critical parameters shared by the FC/FCIP Entity pairs involved in the FCIP Link - Configuration discovery (used in place of SLP only when allowed by site security policies) The specific format and protocol requirements for this usage of the FSF are found in sections 7.1 and 8.1.2.3. This section provides an overview of the FSF usage without stating requirements. Because FCIP is only a tunnel for a Fibre Channel Fabric and because the Fabric has its own complex link setup algorithm that can be employed for many FCIP link setup needs, it is desirable to minimize the complexity of the FSF usage during TCP Connection setup. With this in mind, this FSF usage is not a login or parameter negotiation mechanism. A single FSF transits each newly established TCP connection as the first bytes sent in each direction.
Note: This usage of the FSF cannot be eliminated entirely because a newly created TCP Connection must be associated with the correct FCIP Link before FC Fabric initialization of the connection can commence. The first bytes sent from the TCP connect request initiator to the receiver are an FSF identifying both the sender and who the sender thinks is the receiver. If the contents of this FSF are correct and acceptable to the receiver, the unchanged FSF is echoed back to the sender. This send/echo process is the only set of actions that allows the TCP Connection to be used to carry FC Fabric traffic. If the send and unchanged echo process does not occur, the algorithm followed at one or both ends of the TCP Connection results in the closure of the TCP Connection (see section 8.1 for specific algorithm requirements). Note: Owing to the limited manner in which the FSF is used and the requirement that the FSF be echoed without changes before a TCP Connection is allowed to carry user data, no error checking beyond that provided by TCP is deemed necessary. As described above, the primary purpose of the FSF usage during TCP Connection setup is identifying the FCIP Link to which the new TCP Connection belongs. From these beginnings, it is only a small stretch to envision using the FSF as a simplified configuration discovery tool, and the mechanics of such a usage are described in section 8.1. However, use of the FSF for configuration discovery lacks the broad range of capabilities provided by SLPv2 and most particularly lacks the security capabilities of SLPv2. For these reasons, using the FSF for configuration discovery is not appropriate for all environments. Thus the choice to use the FSF for discovery purposes is a policy choice to be included in the TCP Connection Establishment "shared" database described in section 8.1.1. When FSF-based configuration discovery is enabled, the normal TCP Connection setup rules outlined above are modified as follows. Normally, the algorithm executed by an FCIP Entity receiving an FSF includes verifying that its own identification information in the arriving FSF is correct and closing the TCP Connection if it is not. This can be viewed as requiring the initiator of a TCP connect request to know in advance the identity of the FCIP Entity that is the target of that request (using SLP, for example), and through the FSF effectively saying, "I think I'm talking to X." If the party at the other end of the TCP connect request is really Y, then it simply hangs up.
FSF-based discovery allows the "I think I'm talking to X" to be replaced with "Please tell me who I am talking to?", which is accomplished by replacing an explicit value in the Destination FC Fabric Entity World Wide Name field with zero. If the policy at the receiving FCIP Entity allows FSF-based discovery, the zero is replaced with the correct Destination FC Fabric Entity World Wide Name value in the echoed FSF. This is still subject to the rules of sending with unchanged echo, and so closure of TCP Connection occurs after the echoed FSF is received by the TCP connect initiator. Despite the TCP Connection closure, however, the TCP connect initiator now knows the correct Destination FC Fabric Entity World Wide Name identity of the FCIP Entity at a given IP Address and a subsequent TCP Connection setup sequence probably will be successful. The Ch bit in the pFlags field (see section 5.6.1) allows for differentiation between changes in the FSF resulting from transmission errors and changes resulting from intentional acts by the FSF recipient.8. TCP Connection Management
8.1. TCP Connection Establishment
8.1.1. Connection Establishment Model
The description of the connection establishment process is a model for the interactions between an FC Entity and an FCIP Entity during TCP Connection establishment. The model is written in terms of a "shared" database that the FCIP Entity consults to determine the properties of the TCP Connections to be formed combined with routine calls to the FC Entity when connections are successfully established. Whether the FC Entity contributes information to the "shared" database is not critical to this model. However, the fact that the FCIP Entity MAY consult the database at any time to determine its actions relative to TCP Connection establishment is important. It is important to remember that this description is only a model for the interactions between an FC Entity and an FCIP Entity. Any implementation that has the same effects on the FC Fabric and IP Network as those described using the model meets the requirements of this specification. For example, an implementation might replace the "shared" database with a routine interface between the FC and FCIP Entities.
8.1.2. Creating New TCP Connections
8.1.2.1. Non-Dynamic Creation of New TCP Connections
When an FCIP Entity discovers that a new TCP Connection needs to be established, it SHALL determine the IP Address to which the TCP Connection is to be made and establish all enabled IP security features for that IP Address as described in section 9. Then the FCIP Entity SHALL determine the following information about the new connection in addition to the IP Address: - The expected Destination FC Fabric Entity World Wide Name of the FC/FCIP Entity pair to which the TCP Connection is being made - TCP Connection Parameters (see section 8.3) - Quality of Service Information (see section 10) Based on this information, the FCIP Entity SHALL generate a TCP connect request [6] to the FCIP Well-Known Port of 3225 (or other configuration specific port number) at the specified IP Address. If the TCP connect request is rejected, the FCIP Entity SHALL act to limit unnecessary repetition of attempts to establish similar connections. For example, the FCIP Entity might wait 60 seconds before trying to re-establish the connection. If the TCP connect request is accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2.3 to complete the establishment of a new FCIP_DE. It is RECOMMENDED that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted.8.1.2.2. Dynamic Creation of New TCP Connections
If dynamic discovery of participating FCIP Entities is supported, the function SHALL be performed using the Service Location Protocol (SLPv2) [17] in the manner defined for FCIP usage [20]. Upon discovering that dynamic discovery is to be used, the FCIP Entity SHALL enable IP security features for the SLP discovery process as described in [20] and then: 1) Determine the one or more FCIP Discovery Domain(s) to be used in the dynamic discovery process;
2) Establish an SLPv2 Service Agent to advertise the availability of
this FCIP Entity to peer FCIP Entities in the identified FCIP
Discovery Domain(s); and
3) Establish an SLPv2 User Agent to locate service advertisements for
peer FCIP Entities in the identified FCIP Discovery Domain(s).
For each peer FCIP Entity dynamically discovered through the SLPv2
User Agent, the FCIP Entity SHALL establish all enabled IP security
features for the discovered IP Address as described in section 9 and
then determine the following information about the new connection:
- The expected Destination FC Fabric Entity World Wide Name of the
FC/FCIP Entity pair to which the TCP Connection is being made
- TCP Connection Parameters (see section 8.3)
- Quality of Service Information (see section 10)
Based on this information, the FCIP Entity SHALL generate a TCP
connect request [6] to the FCIP Well-Known Port of 3225 (or other
configuration specific port number) at the IP Address specified by
the service advertisement. If the TCP connect request is rejected,
act to limit unnecessary repetition of attempts to establish similar
connections. If the TCP connect request is accepted, the FCIP Entity
SHALL follow the steps described in section 8.1.2.3 to complete the
establishment of a new FCIP_DE.
It is recommended that an FCIP Entity not initiate TCP connect
requests to another FCIP Entity if incoming TCP connect requests from
that FCIP Entity have already been accepted.
8.1.2.3. Connection Setup After a Successful TCP Connect Request
Whether Non-Dynamic TCP Connection creation (see section 8.1.2.1) or
Dynamic TCP Connection creation (see section 8.1.2.2) is used, the
steps described in this section SHALL be followed to take the TCP
Connection setup process to completion.
After the TCP connect request has been accepted, the FCIP Entity
SHALL send an FCIP Special Frame (FSF, see section 7) as the first
bytes transmitted on the newly formed connection, and retain a copy
of those bytes for later comparisons. All fields in the FSF SHALL be
filled in as described in section 7, particularly:
- The Source FC Fabric Entity World Wide Name field SHALL contain
the FC Fabric Entity World Wide Name for the FC/FCIP Entity pair
that is originating the TCP connect request;
- The Source FC/FCIP Entity Identifier field SHALL contain a unique
identifier that is assigned by the FC Fabric entity whose world
wide name appears in the Source FC Fabric Entity World Wide Name
field;
- The Connection Nonce field SHALL contain a 64-bit random number
that differs in value from any recently used Connection Nonce
value. In order to provide sufficient security for the connection
nonce, the Randomness Recommendations for Security [9] SHOULD be
followed; and
- The Destination FC Fabric Entity World Wide Name field SHALL
contain 0 or the expected FC Fabric Entity World Wide Name for the
FC/FCIP Entity pair whose destination is the TCP connect request.
After the FSF is sent on the newly formed connection, the FCIP Entity
SHALL wait for the FSF to be echoed as the first bytes received on
the newly formed connection.
The FCIP Entity MAY apply a timeout of not less than 90 seconds while
waiting for the echoed FSF bytes. If the timeout expires, the FCIP
Entity SHALL close the TCP Connection and notify the FC Entity with
the reason for the closure.
If the echoed FSF bytes do not exactly match the FSF bytes sent
(words 7 through 17 inclusive) or if the echoed Destination FC Fabric
Entity World Wide Name field contains zero, the FCIP Entity SHALL
close the TCP Connection and notify the FC Entity with the reason for
the closure.
The FCIP Entity SHALL only perform the following steps if the echoed
FSF bytes exactly match the FSF bytes sent (words 7 through 17
inclusive).
1) Instantiate the appropriate Quality of Service (see section 10)
conditions on the newly created TCP Connection,
2) If the IP Address and TCP Port to which the TCP Connection was
made is not associated with any other FCIP_LEP, create a new
FCIP_LEP for the new FCIP Link,
3) Create a new FCIP_DE within the newly created FCIP_LEP to service
the new TCP Connection, and
4) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Destination FC
Fabric Entity World Wide Name, Connection Usage Flags, and
Connection Usage Code.
8.1.3. Processing Incoming TCP Connect Requests
The FCIP Entity SHALL listen for new TCP Connection requests [6] on the FCIP Well-Known Port (3225). An FCIP Entity MAY also accept and establish TCP Connections to a TCP port number other than the FCIP Well-Known Port, as configured by the network administrator in a manner outside the scope of this specification. The FCIP Entity SHALL determine the following information about the requested connection: - Whether the "shared" database (see section 8.1.1) allows the requested connection - Whether IP security setup has been performed for the IP security features enabled on the connection (see section 9) If the requested connection is not allowed, the FCIP Entity SHALL reject the connect request using appropriate TCP means. If the requested connection is allowed, the FC Entity SHALL ensure that required IP security features are enabled and accept the TCP connect request. After the TCP connect request has been accepted, the FCIP Entity SHALL wait for the FSF sent by the originator of the TCP connect request (see section 8.1.2) as the first bytes received on the accepted connection. The FCIP Entity MAY apply a timeout of no less than 90 seconds while waiting for the FSF bytes. If the timeout expires, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure. Note: One method for attacking the security of the FCIP Link formation process (detailed in section 9.1) depends on keeping a TCP connect request open without sending an FSF. Implementations should bear this in mind in the handling of TCP connect requests where the FSF is not sent in a timely manner. Upon receipt of the FSF sent by the originator of the TCP connect request, the FCIP Entity SHALL inspect the contents of the following fields: - Connection Nonce, - Destination FC Fabric Entity World Wide Name, - Connection Usage Flags, and - Connection Usage Code.
If the Connection Nonce field contains a value identical to the most
recently received Connection Nonce from the same IP Address, the FCIP
Entity SHALL close the TCP Connection and notify the FC Entity with
the reason for the closure.
If an FCIP Entity receives a duplicate FSF during the FCIP Link
formation process, it SHALL close that TCP Connection and notify the
FC Entity with the reason for the closure.
If the Destination FC Fabric Entity World Wide Name contains 0, the
FCIP Entity SHALL take one of the following three actions:
1) Leave the Destination FC Fabric Entity World Wide Name field and
Ch bit both 0;
2) Change the Destination FC Fabric Entity World Wide Name field to
match FC Fabric Entity World Wide Name associated with the FCIP
Entity that received the TCP connect request and change the Ch bit
to 1; or
3) Close the TCP Connection without sending any response.
The choice between the above actions depends on the anticipated usage
of the FCIP Entity. The FCIP Entity may consult the "shared"
database when choosing between the above actions.
If:
a) The Destination FC Fabric Entity World Wide Name contains a non-
zero value that does not match the FC Fabric Entity World Wide
Name associated with the FCIP Entity that received the TCP connect
request, or
b) The contents of the Connection Usage Flags and Connection Usage
Code fields is not acceptable to the FCIP Entity that received the
TCP connect request, then the FCIP Entity SHALL take one of the
following two actions:
1) Change the contents of the unacceptable fields to correct/
acceptable values and set the Ch bit to 1; or
2) Close the TCP Connection without sending any response.
If the FCIP Entity makes any changes in the content of the FSF, it
SHALL also set the Ch bit to 1.
If any changes have been made in the received FSF during the
processing described above, the following steps SHALL be performed:
1) The changed FSF SHALL be echoed to the originator of the TCP
connect request as the only bytes transmitted on the accepted
connection;
2) The TCP Connection SHALL be closed (the FC Entity need not be
notified of the TCP Connection closure in this case because it is
not indicative of an error); and
3) All of the additional processing described in this section SHALL
be skipped.
The remaining steps in this section SHALL be performed only if the
FCIP Entity has not changed the contents of the above mentioned
fields to correct/acceptable values.
If the Source FC Fabric Entity World Wide Name and Source FC/FCIP
Entity Identifier field values in the FSF do not match the Source FC
Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier
associated with any other FCIP_LEP, the FCIP Entity SHALL:
1) Echo the unchanged FSF to the originator of the TCP connect
request as the first bytes transmitted on the accepted connection;
2) Instantiate the appropriate Quality of Service (see section 10.2)
conditions on the newly created TCP Connection, considering the
Connection Usage Flags and Connection Usage Code fields, and
"shared" database information (see section 8.1.1) as appropriate,
3) Create a new FCIP_LEP for the new FCIP Link,
4) Create a new FCIP_DE within the newly created FCIP_LEP to service
the new TCP Connection, and
5) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Source FC
Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier,
Connection Usage Flags, and Connection Usage Code.
If the Source FC Fabric Entity World Wide Name and Source FC/FCIP
Entity Identifier field values in the FCIP Special Frame match the
Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity
Identifier associated with an existing FCIP_LEP, the FCIP Entity
SHALL:
1) Request that the FC Entity authenticate the source of the TCP
connect request (see FC-BB-2 [3]), providing the following
information to the FC Entity for authentication purposes:
a) Source FC Fabric Entity World Wide Name,
b) Source FC/FCIP Entity Identifier, and
c) Connection Nonce.
The FCIP Entity SHALL NOT use the new TCP Connection for any
purpose until the FC Entity authenticates the source of the TCP
connect request. If the FC Entity indicates that the TCP connect
request cannot be properly authenticated, the FCIP Entity SHALL
close the TCP Connection and skip all of the remaining steps in
this section.
The definition of the FC Entity SHALL include an authentication
mechanism for use in response to a TCP connect request source that
communicates with the partner FC/FCIP Entity pair on an existing
FCIP Link. This authentication mechanism should use a previously
authenticated TCP Connection in the existing FCIP Link to
authenticate the Connection Nonce sent in the new TCP Connection
setup process. The FCIP Entity SHALL treat failure of this
authentication as an authentication failure for the new TCP
Connection setup process.
2) Echo the unchanged FSF to the originator of the TCP connect
request as the first bytes transmitted on the accepted connection;
3) Instantiate the appropriate Quality of Service (see section 10.2)
conditions on the newly created TCP Connection, considering the
Connection Usage Flags and Connection Usage Code fields, and
"shared" database information (see section 8.1.1) as appropriate,
4) Create a new FCIP_DE within the existing FCIP_LEP to service the
new TCP Connection, and
5) Inform the FC Entity of the FCIP_LEP, Source FC Fabric Entity
World Wide Name, Source FC/FCIP Entity Identifier, Connection
Usage Flags, Connection Usage Code, and new FCIP_DE.
Note that the originator of TCP connect requests uses the IP Address
and TCP Port to identify which TCP Connections belong to which
FCIP_LEPs while the recipient of TCP connect requests uses the Source
FC Fabric Entity World Wide Name, and Source FC/FCIP Entity
Identifier fields from the FSF to identify which TCP Connection
belong to which FCIP_LEPs. For this reason, an FCIP Entity that both
originates and receives TCP connect requests is unable to match the
FCIP_LEPs associated with originated TCP connect requests to the
FCIP_LEPs associated with received TCP connect requests.
8.1.4. Simultaneous Connection Establishment
If two FCIP Entities perform simultaneous open operations, then two TCP Connections are formed and the SF originates at one end on one connection and at the other end on the other. Connection setup proceeds as described above on both connections, and the steps described above properly result in the formation of two FCIP Links between the same FCIP Entities. This is not an error. Fibre Channel is perfectly capable of handling two approximately equal connections between FC Fabric elements. The decision to setup pairs of FCIP Links in this manner is considered to be a site policy decision that can be covered in the "shared" database described in section 8.1.1.8.2. Closing TCP Connections
The FCIP Entity SHALL provide a mechanism with acknowledgement by which the FC Entity is able to cause the closing of an existing TCP Connection at any time. This allows the FC Entity to close TCP Connections that are producing too many errors, etc.8.3. TCP Connection Parameters
In order to provide efficient management of FCIP_LEP resources as well as FCIP Link resources, consideration of certain TCP Connection parameters is recommended.8.3.1. TCP Selective Acknowledgement Option
The Selective Acknowledgement option RFC 2883 [18] allows the receiver to acknowledge multiple lost packets in a single ACK, enabling faster recovery. An FCIP Entity MAY negotiate use of TCP SACK and use it for faster recovery from lost packets and holes in TCP sequence number space.8.3.2. TCP Window Scale Option
The TCP Window Scale option [8] allows TCP window sizes larger than 16-bit limits to be advertised by the receiver. It is necessary to allow data in long fat networks to fill the available pipe. This also implies buffering on the TCP sender that matches the (bandwidth*delay) product of the TCP Connection. An FCIP_LEP uses locally available mechanisms to set a window size that matches the available local buffer resources and the desired throughput.
8.3.3. Protection Against Sequence Number Wrap
It is RECOMMENDED that FCIP Entities implement protection against wrapped sequence numbers PAWS [8]. It is quite possible that within a single connection, TCP sequence numbers wrap within a timeout window.8.3.4. TCP_NODELAY Option
FCIP Entities should disable the Nagle Algorithm as described in RFC 1122 [7] section 4.2.3.4. By tradition, this can be accomplished by setting the TCP_NODELAY option to one at the local TCP interface.8.4. TCP Connection Considerations
In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [3]). When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure.8.5. Flow Control Mapping between TCP and FC
The FCIP Entity and FC Entity are connected to the IP Network and FC Fabric, respectively, and they need to follow the flow control mechanisms of both TCP and FC, which work independently of each other. This section provides guidelines as to how the FCIP Entity can map TCP flow control to status notifications to the FC Entity. There are two scenarios in which the flow control management becomes crucial: 1) When there is line speed mismatch between the FC and IP interfaces. Even though it is RECOMMENDED that both of the FC and IP interfaces to the FC Entity and FCIP Entity, respectively, be of comparable speeds, it is possible to carry FC traffic over an IP Network that has a different line speed and bit error rate.
2) When the FC Fabric or IP Network encounters congestion.
Even when both the FC Fabric or IP network are of comparable
speeds, during the course of operation, the FC Fabric or the IP
Network could encounter congestion due to transient conditions.
The FC Entity uses Fibre Channel mechanisms for flow control at the
FC Frame Receiver Portal based on information supplied by the FCIP
Entity regarding flow constraints at the Encapsulated Frame
Transmitter Portal. The FCIP Entity uses TCP mechanisms for flow
control at the Encapsulated Frame Receiver Portal based on
information supplied by the FC Entity regarding flow constraints at
the FC Frame Transmitter Portal.
Coordination of these flow control mechanisms, one of which is credit
based and the other of which is window based, depends on a
painstaking design that is outside the scope of this specification.
9. Security
FCIP utilizes the IPsec protocol suite to provide data
confidentiality and authentication services, and IKE as the key
management protocol. This section describes the requirements for
various components of these protocols as used by FCIP, based on FCIP
operating environments. Additional consideration for use of IPsec
and IKE with the FCIP protocol can be found in [21]. In the event
that requirements in [21] conflict with requirements stated in this
document, the requirements in this document SHALL prevail.
9.1. Threat Models
Using a general purpose, wide-area network, such as an IP Network, as
a functional replacement for physical cabling introduces some
security problems not normally encountered in Fibre Channel Fabrics.
FC interconnect cabling is typically protected physically from
outside access. Public IP Networks allow hostile parties to impact
the security of the transport infrastructure.
The general effect is that the security of an FC Fabric is only as
good as the security of the entire IP Network that carries the FCIP
Links used by that FC Fabric. The following broad classes of attacks
are possible:
1) Unauthorized Fibre Channel elements can gain access to resources
through normal Fibre Channel Fabric and processes. Although this
is a valid threat, securing the Fibre Channel Fabrics is outside
the scope of this document. Securing the IP Network is the issue
considered in this specification.
2) Unauthorized agents can monitor and manipulate Fibre Channel
traffic flowing over physical media used by the IP Network and
accessible to the agent.
3) TCP Connections may be hijacked and used to instantiate an invalid
FCIP Link between two peer FCIP Entities.
4) Valid and invalid FCIP Frames may be injected on the TCP
Connections.
5) The payload of an FCIP Frame may be altered or transformed. The
TCP checksum, FCIP ones complement checks, and FC frame CRC do not
protect against this because all of them can be modified or
regenerated by a malicious and determined adversary.
6) Unauthorized agents can masquerade as valid FCIP Entities and
disturb proper operation of the Fibre Channel Fabric.
7) Denial of Service attacks can be mounted by injecting TCP
Connection requests and other resource exhaustion operations.
8) An adversary may launch a variety of attacks against the discovery
process [17].
9) An attacker may exploit the FSF authentication mechanism of the
FCIP Link formation process (see section 8.1.3). The attacker
could observe the FSF contents sent on an initial connection of an
FCIP Link and use the observed nonce, Source FC/FCIP Entity
Identifier, and other FSF contents to form an FCIP Link using the
attacker's own previously established connection, while
resetting/blocking the observed connection. Although the use of
timeout for reception of FSF reduces the risk of this attack, such
an attack is possible. See section 9.3.1 to protect against this
specific attack.
The existing IPsec Security Architecture and protocol suite [10]
offers protection from these threats. An FCIP Entity MUST implement
portions of the IPsec protocol suite as described in this section.
9.2. FC Fabric and IP Network Deployment Models
In the context of enabling a secure FCIP tunnel between FC SANs, the following characteristics of the IP Network deployment are useful to note. 1) The FCIP Entities share a peer-to-peer relationship. Therefore, the administration of security policies applies to all FCIP Entities in an equal manner. This differs from a true Client- Server relationship, where there is an inherent difference in how security policies are administered. 2) Policy administration as well as security deployment and configuration are constrained to the set of FCIP Entities, thereby posing less of a requirement on a scalable mechanism. For example, the validation of credentials can be relaxed to the point where deploying a set of pre-shared keys is a viable technique. 3) TCP Connections and the IP Network are terminated at the FCIP Entity. The granularity of security implementation is at the level of the FCIP tunnel endpoint (or FCIP Entity), unlike other applications where there is a user-level termination of TCP Connections. User-level objects are not controllable by or visible to FCIP Entities. All user-level security related to FCIP is the responsibility of the Fibre Channel standards and is outside the scope of this specification. 4) When an FCIP Entity is deployed, its IP addresses will typically be statically assigned. However, support for dynamic IP address assignment, as described in [33], while typically not required, cannot be ruled out.9.3. FCIP Security Components
FCIP Security compliant implementations MUST implement ESP and the IPsec protocol suite based cryptographic authentication and data integrity [10], as well as confidentiality using algorithms and transforms as described in this section. Also, FCIP implementations MUST meet the secure key management requirements of IPsec protocol suite.9.3.1. IPsec ESP Authentication and Confidentiality
FCIP Entities MUST implement IPsec ESP [12] in Tunnel Mode for providing Data Integrity and Confidentiality. FCIP Entities MAY implement IPsec ESP in Transport Mode, if deployment considerations require use of Transport Mode. When ESP is utilized, per-packet data origin authentication, integrity, and replay protection MUST be used.
If Confidentiality is not enabled but Data Integrity is enabled, ESP with NULL Encryption [15] MUST be used. IPsec ESP for message authentication computes a cryptographic hash over the payload that is protected. While IPsec ESP mandates compliant implementations to support certain algorithms for deriving this hash, FCIP implementations: - MUST implement HMAC with SHA-1 [11] - SHOULD implement AES in CBC MAC mode with XCBC extensions [23] - DES in CBC mode SHOULD NOT be used due to inherent weaknesses For ESP Confidentiality, FCIP Entities: - MUST implement 3DES in CBC mode [16] - SHOULD implement AES in CTR mode [22] - MUST implement NULL Encryption [15]9.3.2. Key Management
FCIP Entities MUST support IKE [14] for peer authentication, negotiation of Security Associations (SA), and Key Management using the IPsec DOI [13]. Manual keying SHALL NOT be used for establishing an SA since it does not provide the necessary elements for rekeying (see section 9.3.3). Conformant FCIP implementations MUST support peer authentication using pre-shared keys and MAY support peer 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.
(page 47 continued on part 3)
