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