RFC 4172
iFCP - A Protocol for Internet Fibre Channel Storage Networking
8. iFCP Error Detection
8.1. Overview
This section specifies provisions for error detection and recovery in addition to those in [FC-FS], which continue to be available in the iFCP network environment.8.2. Stale Frame Prevention
Recovery from fibre channel protocol error conditions requires that frames associated with a failed or aborted exchange drain from the fabric before exchange resources can be safely reused. Since a fibre channel fabric may not preserve frame order, there is no deterministic way to purge such frames. Instead, the fabric guarantees that frame the lifetime will not exceed a specific limit (R_A_TOV). R_A_TOV is defined in [FC-FS] as "the maximum transit time within a fabric to guarantee that a lost frame will never emerge from the fabric". For example, a value of 2 x R_A_TOV is the minimum time that the originator of an ELS request or FC-4 link service request must wait for the response to that request. The fibre channel default value for R_A_TOV is 10 seconds. An iFCP gateway SHALL actively enforce limits on R_A_TOV as described in Section 8.2.1.8.2.1. Enforcing R_A_TOV Limits
The R_A_TOV limit on frame lifetimes SHALL be enforced by means of the time stamp in the encapsulation header (see Section 5.3.1) as described in this section. The budget for R_A_TOV SHOULD include allowances for the propagation delay through the gateway regions of the sending and receiving N_PORTs, plus the propagation delay through the IP network. This latter component is referred to in this specification as IP_TOV. IP_TOV should be set well below the value of R_A_TOV specified for the iFCP fabric and should be stored in the iSNS server. IP_TOV should be set to 50 percent of R_A_TOV. The following paragraphs describe the requirements for synchronizing gateway time bases and the rules for measuring and enforcing propagation delay limits.
The protocol for synchronizing a gateway time base is SNTP [RFC2030]. In order to ensure that all gateways are time aligned, a gateway SHOULD obtain the address of an SNTP-compatible time server via an iSNS query. If multiple time server addresses are returned by the query, the servers must be synchronized and the gateway may use any server in the list. Alternatively, the server may return a multicast group address in support of operation in Anycast mode. Implementation of Anycast mode is as specified in [RFC2030], including the precautions defined in that document. Multicast mode SHOULD NOT be used. An SNTP server may use any one of the time reference sources listed in [RFC2030]. The resolution of the time reference MUST be 125 milliseconds or better. Stability of the SNTP server and gateway time bases should be 100 ppm or better. With regard to its time base, the gateway is in either the Synchronized or Unsynchronized state. When in the synchronized state, the gateway SHALL a) set the time stamp field for each outgoing frame in accordance with the gateway's internal time base; b) check the time stamp field of each incoming frame, following validation of the encapsulation header CRC, as described in Section 5.3.4; c) if the incoming frame has a time stamp of 0,0 and is not one of the session control frames that require a 0,0 time stamp (see Section 6), the frame SHALL be discarded; d) if the incoming frame has a non-zero time stamp, the receiving gateway SHALL compute the absolute value of the time in flight and SHALL compare it against the value of IP_TOV specified for the IP fabric; e) if the result in step (d) exceeds IP_TOV, the encapsulated frame shall be discarded. Otherwise, the frame shall be de-encapsulated as described in Section 5.3.4. A gateway SHALL enter the Synchronized state upon receiving a successful response to an SNTP query.
A gateway shall enter the Unsynchronized state:
a) upon power-up and before successful completion of an SNTP query,
and
b) whenever the gateway looses contact with the SNTP server, such
that the gateway's time base may no longer be in alignment with
that of the SNTP server. The criterion for determining loss of
contact is implementation specific.
Following loss of contact, it is recommended that the gateway enter
the Unsynchronized state when the estimated time base drift relative
to the SNTP reference is greater than ten percent of the IP_TOV
limit. (Assuming that all timers have an accuracy of 100 ppm and
IP_TOV equals 5 seconds, the maximum allowable loss of contact
duration would be about 42 minutes.)
As the result of a transition from the Synchronized to the
Unsynchronized state, a gateway MUST abort all iFCP sessions as
described in Section 5.2.3. While in the Unsynchronized state, a
gateway SHALL NOT permit the creation of new iFCP sessions.
9. Fabric Services Supported by an iFCP Implementation
An iFCP gateway implementation MUST support the following fabric
services:
N_PORT ID Value Description Section
--------------- ----------- -------
0xFF-FF-FE F_PORT Server 9.1
0xFF-FF-FD Fabric Controller 9.2
0xFF-FF-FC Directory/Name Server 9.3
In addition, an iFCP gateway MAY support the FC broadcast server
functionality described in Section 9.4.
9.1. F_PORT Server
The F_PORT server SHALL support the FLOGI ELS, as described in
Section 7.4, as well as the following ELSs specified in [FC-FS]:
a) Request for fabric service parameters (FDISC).
b) Request for the link error status (RLS).
c) Read Fabric Timeout Values (RTV).
9.2. Fabric Controller
The Fabric Controller SHALL support the following ELSs as specified in [FC-FS]: a) State Change Notification (SCN). b) Registered State Change Notification (RSCN). c) State Change Registration (SCR).9.3. Directory/Name Server
The Directory/Name server provides a registration service allowing an N_PORT to record or query the database for information about other N_PORTs. The services are defined in [FC-GS3]. The queries are issued as FC-4 transactions using the FC-CT command transport protocol specified in [FC-GS3]. In iFCP, each name server request MUST be translated to the appropriate iSNS query defined in [ISNS]. The definitions of name server objects are specified in [FC-GS3]. The name server SHALL support record and query operations for directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) and MAY support the FC-4 specific services as defined in [FC-GS3].9.4. Broadcast Server
Fibre channel frames are broadcast throughout the fabric by addressing them to the fibre channel broadcast server at the well- known fibre channel address 0xFF-FF-FF. The broadcast server then replicates and delivers the frame to each attached N_PORT in all zones to which the originating device belongs. Only class 3 (datagram) service is supported. In an iFCP system, the fibre channel broadcast function is emulated by means of a two-tier architecture comprising the following elements: a) A local broadcast server residing in each iFCP gateway. The local server distributes broadcast traffic within the gateway region and forwards outgoing broadcast traffic to a global server for distribution throughout the iFCP fabric. b) A global broadcast server that re-distributes broadcast traffic to the local server in each participating gateway.
c) An iSNS discovery domain defining the scope over which broadcast
traffic is propagated. The discovery domain is populated with a
global broadcast server and the set of local servers it supports.
The local and global broadcast servers are logical iFCP devices that
communicate using the iFCP protocol. The servers have an N_PORT
Network Address consisting of an iFCP portal address and an N_PORT ID
set to the well-known fibre channel address of the FC broadcast
server (0xFF-FF-FF).
As noted above, an N_PORT originates a broadcast by directing frame
traffic to the fibre channel broadcast server. The gateway-resident
local server distributes a copy of the frame locally and forwards a
copy to the global server for redistribution to the local servers on
other gateways. The global server MUST NOT echo a broadcast frame to
the originating local server.
9.4.1. Establishing the Broadcast Configuration
The broadcast configuration is managed with facilities provided by
the iSNS server by the following means:
a) An iSNS discovery domain is created and seeded with the network
address of the global broadcast server N_PORT. The global server
is identified as such by setting the appropriate N_PORT entity
attribute.
b) Using the management interface, each broadcast server is preset
with the identity of the broadcast domain.
During power up, each gateway SHALL invoke the iSNS service to
register its local broadcast server in the broadcast discovery
domain. After registration, the local server SHALL wait for the
global broadcast server to establish an iFCP session.
The global server SHALL register with the iSNS server as follows:
a) The server SHALL query the iSNS name server by attribute to obtain
the worldwide port name of the N_PORT pre-configured to provide
global broadcast services.
b) If the worldwide port name obtained above does not correspond to
that of the server issuing the query, the N_PORT SHALL NOT perform
global broadcast functions for N_PORTs in that discovery domain.
c) Otherwise, the global server N_PORT SHALL register with the
discovery domain and query the iSNS server to identify all
currently registered local servers.
d) The global broadcast server SHALL initiate an iFCP session with
each local broadcast server in the domain. When a new local
server registers, the global server SHALL receive a state change
notification and respond by initiating an iFCP session with the
newly added server. The gateway SHALL obtain these notifications
using the iSNS provisions for lossless delivery.
Upon receiving the CBIND request to initiate the iFCP session, the
local server SHALL record the worldwide port name and N_PORT network
address of the global server.
9.4.2. Broadcast Session Management
After the initial broadcast session is established, the local or
global broadcast server MAY choose to manage the session in one of
the following ways, depending on resource requirements and the
anticipated level of broadcast traffic:
a) A server MAY keep the session open continuously. Since broadcast
sessions are often quiescent for long periods of time, the server
SHOULD monitor session connectivity as described in Section
5.2.2.4.
b) A server MAY open the broadcast session on demand only when
broadcast traffic is to be sent. If the session is reopened by
the global server, the local server SHALL replace the previously
recorded network address of the global broadcast server.
9.4.3. Standby Global Broadcast Server
An implementation may designate a local server to assume the duties
of the global broadcast server in the event of a failure. The local
server may use the LTEST message to determine whether the global
server is functioning and may assume control if it is not.
When assuming control, the standby server must register with the iSNS
server as the global broadcast server in place of the failed server
and must install itself in the broadcast discovery domain as
specified in steps c) and d) of Section 9.4.1.
10. iFCP Security
10.1. Overview
iFCP relies upon the IPSec protocol suite to provide data
confidentiality and authentication services, and it relies upon IKE
as the key management protocol. Section 10.2 describes the security
requirements arising from iFCP's operating environment, and Section
10.3 describes the resulting design choices, their requirement levels, and how they apply to the iFCP protocol. Detailed considerations for use of IPsec and IKE with the iFCP protocol can be found in [SECIPS].10.2. iFCP Security Threats and Scope
10.2.1. Context
iFCP is a protocol designed for use by gateway devices deployed in enterprise data centers. Such environments typically have security gateways designed to provide network security through isolation from public networks. Furthermore, iFCP data may have to traverse security gateways in order to support SAN-to-SAN connectivity across public networks.10.2.2. Security Threats
Communicating iFCP gateways may be subjected to attacks, including attempts by an adversary to: a) acquire confidential data and identities by snooping data packets, b) modify packets containing iFCP data and control messages, c) inject new packets into the iFCP session, d) hijack the TCP connection carrying the iFCP session, e) launch denial-of-service attacks against the iFCP gateway, f) disrupt the security negotiation process, g) impersonate a legitimate security gateway, or h) compromise communication with the iSNS server. It is imperative to thwart these attacks, given that an iFCP gateway is the last line of defense for a whole fibre channel island, which may include several hosts and fibre channel switches. To do so, the iFCP gateway must implement and may use confidentiality, data origin authentication, integrity, and replay protection on a per-datagram basis. The iFCP gateway must implement and may use bi-directional authentication of the communication endpoints. Finally, it must implement and may use a scalable approach to key management.
10.2.3. Interoperability with Security Gateways
Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from all possible security threats. Such networks are usually protected by security gateways, which, at a minimum, provide a shield against denial-of- service attacks. The iFCP security architecture is capable of leveraging the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and IPSec VPN services available on existing security gateways. Considerations regarding intervening NAT and NAPT boxes along the iFCP-iSNS path can be found in [ISNS].10.2.4. Authentication
iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by either peer gateway or both. Consequently, bi-directional authentication of peer gateways must be provided in accordance with the requirement levels specified in Section 10.3.1. N_PORT identities used in the Port Login (PLOGI) process shall be considered authenticated if the PLOGI request is received from the remote gateway over a secure, IPSec-protected connection. There is no requirement that the identities used in authentication be kept confidential.10.2.5. Confidentiality
iFCP traffic may traverse insecure public networks, and therefore implementations must have per-packet encryption capabilities to provide confidentiality in accordance with the requirements specified in Section 10.3.1.10.2.6. Rekeying
Due to the high data transfer rates and the amount of data involved, an iFCP implementation must support the capability to rekey each phase 2 security association in the time intervals dictated by sequence number space exhaustion at a given link rate. In the rekeying scenario described in [SECIPS], for example, rekeying events happen as often as every 27.5 seconds at a 10 Gbps rate. The iFCP gateway must provide the capability for forward secrecy in the rekeying process.
10.2.7. Authorization
Basic access control properties stem from the requirement that two communicating iFCP gateways be known to one or more iSNS servers before they can engage in iFCP exchanges. The optional use of discovery domains [ISNS], Identity Payloads (e.g., ID_FQDNs), and certificate-based authentication (e.g., with X509v3 certificates) enables authorization schemas of increasing complexity. The definition of such schemas (e.g., role-based access control) is outside of the scope of this specification.10.2.8. Policy Control
This specification allows any and all security mechanisms in an iFCP gateway to be administratively disabled. Security policies MUST have, at most, iFCP Portal resolution. Administrators may gain control over security policies through an adequately secured interaction with a management interface or with iSNS.10.2.9. iSNS Role
iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways MUST use iSNS for discovery services and MAY use security policies configured in the iSNS database as the basis for algorithm negotiation in IKE. The iSNS specification defines mechanisms for securing communication between an iFCP gateway and iSNS server(s). Additionally, the specification indicates how elements of security policy concerning individual iFCP sessions can be retrieved from iSNS server(s).10.3. iFCP Security Design
10.3.1. Enabling Technologies
Applicable technology from IPsec and IKE is defined in the following suite of specifications: [RFC2401] Security Architecture for the Internet Protocol [RFC2402] IP Authentication Header [RFC2404] The Use of HMAC-SHA-1-96 within ESP and AH [RFC2405] The ESP DES-CBC Cipher Algorithm with Explicit IV [RFC2406] IP Encapsulating Security Payload
[RFC2407] The Internet IP Security Domain of Interpretation for
ISAKMP
[RFC2408] Internet Security Association and Key Management
Protocol (ISAKMP)
[RFC2409] The Internet Key Exchange (IKE)
[RFC2410] The NULL Encryption Algorithm and Its Use With IPSEC
[RFC2451] The ESP CBC-Mode Cipher Algorithms
[RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains
The implementation of IPsec and IKE is required according to the
following guidelines.
Support for the IP Encapsulating Security Payload (ESP) [RFC2406] is
MANDATORY to implement. When ESP is used, per-packet data origin
authentication, integrity, and replay protection MUST be used.
For data origin authentication and integrity with ESP, HMAC with SHA1
[RFC2404] MUST be implemented, and the Advanced Encryption Standard
[AES] in CBC MAC mode with Extended Cipher Block Chaining SHOULD be
implemented in accordance with [AESCBC].
For confidentiality with ESP, 3DES in CBC mode [RFC2451] MUST be
implemented, and AES counter mode encryption [AESCTR] SHOULD be
implemented. NULL encryption MUST be supported as well, as defined
in [RFC2410]. DES in CBC mode SHOULD NOT be used due to its inherent
weakness. Since it is known to be crackable with modest computation
resources, it is inappropriate for use in any iFCP deployment
scenario.
A conforming iFCP protocol implementation MUST implement IPsec ESP
[RFC2406] in tunnel mode [RFC2401] and MAY implement IPsec ESP in
transport mode.
Regarding key management, iFCP implementations MUST support IKE
[RFC2409] for bi-directional peer authentication, negotiation of
security associations, and key management, using the IPsec DOI.
There is no requirement that the identities used in authentication be
kept confidential. Manual keying MUST NOT be used since it does not
provide the necessary keying support. According to [RFC2409], pre-
shared secret key authentication is MANDATORY to implement, whereas
certificate-based peer authentication using digital signatures MAY be
implemented (see Section 10.3.3 regarding the use of certificates).
[RFC2409] defines the following requirement levels for IKE Modes:
Phase-1 Main Mode MUST be implemented.
Phase-1 Aggressive Mode SHOULD be implemented.
Phase-2 Quick Mode MUST be implemented.
Phase-2 Quick Mode with key exchange payload MUST be implemented.
With iFCP, Phase-1 Main Mode SHOULD NOT be used in conjunction with
pre-shared keys, due to Main Mode's vulnerability to man-in-the-
middle-attackers when group pre-shared keys are used. In this
scenario, Aggressive Mode SHOULD be used instead. Peer
authentication using the public key encryption methods outlined in
[RFC2409] SHOULD NOT be used.
The DOI [RFC2407] provides for several types of Identification
Payloads.
When used for iFCP, IKE Phase 1 exchanges MUST explicitly carry the
Identification Payload fields (IDii and IDir). Conforming iFCP
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,
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 [RFC2407], the port and protocol fields in the Identification
Payload MUST be set to zero or UDP port 500.
When used for iFCP, IKE Phase 2 exchanges MUST explicitly carry the
Identification Payload fields (IDci and IDcr). Conforming iFCP
implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR
Identification Type values (according to the version of IP
supported). Other Identification Type values MUST NOT be used. As
described in Section 5.2.2, the gateway creating the iFCP session
must query the iSNS server to determine the appropriate port on which
to initiate the associated TCP connection. Upon a successful IKE
Phase 2 exchange, the IKE responder enforces the negotiated selectors
on the IPsec SAs. Any subsequent iFCP session creation requires the
iFCP peer to query its iSNS server for access control (in accordance
with the session creation requirements specified in Section 5.2.2.1).
10.3.2. Use of IKE and IPsec
A conforming iFCP Portal is capable of establishing one or more IKE
Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase-1
SA may be established when an iFCP Portal is initialized or may be
deferred until the first TCP connection with security requirements is
established.
An IKE Phase-2 SA protects one or more TCP connections within the
same iFCP Portal. More specifically, the successful establishment of
an IKE Phase-2 SA results in the creation of two uni-directional
IPsec SAs fully qualified by the tuple <SPI, destination IP address,
ESP>.
These SAs protect the setup process of the underlying TCP connections
and all their subsequent TCP traffic. The number of TCP connections
in an IPsec SA, as well as the number of SAs, is practically driven
by security policy considerations (i.e., security services are
defined at the granularity of an IPsec SA only), QoS considerations
(e.g., multiple QoS classes within the same IPsec SA increase odds of
packet reordering, possibly falling outside the replay window), and
failure compartmentalization considerations. Each of the TCP
connections protected by an IPsec SA is either in the unbound state,
or bound to a specific iFCP session.
In summary, at any point in time:
-- there exist 0..M IKE Phase-1 SAs between peer iFCP portals,
-- each IKE Phase-1 SA has 0..N IKE Phase-2 SAs, and
-- each IKE Phase-2 SA protects 0..Z TCP connections.
The creation of an IKE Phase-2 SA may be triggered by a policy rule
supplied through a management interface or by iFCP Portal properties
registered with the iSNS server. Similarly, the use of a Key
Exchange payload in Quick Mode for perfect forward secrecy may be
dictated through a management interface or by an iFCP Portal policy
rule registered with the iSNS server.
If an iFCP implementation makes use of unbound TCP connections, and
such connections belong to an iFCP Portal with security requirements,
then the unbound connections MUST be protected by an SA at all times
just like bound connections.
Upon receipt of an IKE Phase-2 delete message, there is no
requirement to terminate the protected TCP connections or delete the
associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be associated
with multiple TCP connections, terminating these connections might in
fact be inappropriate and untimely.
To minimize the number of active Phase-2 SAs, IKE Phase-2 delete
messages may be sent for Phase-2 SAs whose TCP connections have not
handled data traffic for a while. To minimize the use of SA
resources while the associated TCP connections are idle, creation of a new SA should be deferred until new data are to be sent over the connections.10.3.3. Signatures and Certificate-Based Authentication
Conforming iFCP implementations MAY support peer authentication via digital signatures and certificates. When certificate authentication is chosen within IKE, each iFCP gateway needs the certificate credentials of each peer iFCP gateway in order to establish a security association with that peer. Certificate credentials used by iFCP gateways MUST be those of the machine. Certificate credentials MAY be bound to the interface (IP Address or FQDN) of the iFCP gateway used for the iFCP session, or to the fabric WWN of the iFCP gateway itself. Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate. User certificates SHOULD NOT be used by iFCP gateways for establishment of SAs protecting iFCP sessions. If the gateway does not have the peer iFCP gateway's certificate credentials, then it can obtain them: a) by using the iSNS protocol to query for the peer gateway's certificate(s) stored in a trusted iSNS server, or b) through use of the ISAKMP Certificate Request Payload (CRP) [RFC2408] to request the certificate(s) directly from the peer iFCP gateway. When certificate chains are long enough, IKE exchanges using UDP as the underlying transport may yield IP fragments, which are known to work poorly across some intervening routers, firewalls, and NA(P)T boxes. As a result, the endpoints may be unable to establish an IPsec security association. Due to these fragmentation shortcomings, IKE is most appropriate for intra-domain usage. Known solutions to the fragmentation problem include sending the end-entry machine certificate rather than the chain, reducing the size of the certificate chain, using IKE implementations over a reliable transport protocol (e.g., TCP) assisted by Path MTU discovery and code against black-holing as per [RFC2923], or installing network components that can properly handle fragments.
IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) [RFC2408] before accepting a certificate for use in IKE's authentication procedures.10.4. iSNS and iFCP Security
iFCP implementations MUST use iSNS for discovery and management services. Consequently, the security of the iSNS protocol has an impact on the security of iFCP gateways. For a discussion of potential threats to iFCP gateways through use of iSNS, see [ISNS]. To provide security for iFCP gateways using the iSNS protocol for discovery and management services, the IPSec ESP protocol in tunnel mode MUST be supported for iFCP gateways. Further discussion of iSNS security implementation requirements is found in [ISNS]. Note that iSNS security requirements match those for iFCP described in Section 10.3.10.5. Use of iSNS to Distribute Security Policy
Once communication between iFCP gateways and the iSNS server has been secured through use of IPSec, the iFCP gateways have the capability to discover the security settings that they need to use (or not use) to protect iFCP traffic. This provides a potential scaling advantage over device-by-device configuration of individual security policies for each iFCP gateway. It also provides an efficient means for each iFCP gateway to discover the use or non-use of specific security capabilities by peer gateways. Further discussion on use of iSNS to distribute security policies is found in [ISNS].10.6. Minimal Security Policy for an iFCP Gateway
An iFCP implementation may be able to disable security mechanisms for an iFCP Portal administratively through a management interface or through security policy elements set in the iSNS server. As a consequence, IKE or IPsec security associations will not be established for any iFCP sessions that traverse the portal. For most IP networks, it is inappropriate to assume physical security, administrative security, and correct configuration of the network and all attached nodes (a physically isolated network in a test lab may be an exception). Therefore, authentication SHOULD be used in order to provide minimal assurance that connections have initially been opened with the intended counterpart. The minimal iFCP security policy only states that an iFCP gateway SHOULD authenticate its iSNS server(s) as described in [ISNS].
11. Quality of Service Considerations
11.1. Minimal Requirements
Conforming iFCP protocol implementations SHALL correctly communicate gateway-to-gateway, even across one or more intervening best-effort IP regions. The timings with which such gateway-to gateway communication is performed, however, will greatly depend upon BER, packet losses, latency, and jitter experienced throughout the best- effort IP regions. The higher these parameters, the higher the gap measured between iFCP observed behaviors and baseline iFCP behaviors (i.e., as produced by two iFCP gateways directly connected to one another).11.2. High Assurance
It is expected that many iFCP deployments will benefit from a high degree of assurance regarding the behavior of intervening IP regions, with resulting high assurance on the overall end-to-end path, as directly experienced by fibre channel applications. Such assurance on the IP behaviors stems from the intervening IP regions supporting standard Quality-of-Service (QoS) techniques that are fully complementary to iFCP, such as: a) congestion avoidance by over-provisioning of the network, b) integrated Services [RFC1633] QoS, c) differentiated Services [RFC2475] QoS, and d) Multi-Protocol Label Switching [RFC3031]. One may load an MPLS forwarding equivalence class (FEC) with QoS class significance, in addition to other considerations such as protection and diversity for the given path. The complementarity and compatibility of MPLS with Differentiated Services is explored in [MPSLDS], wherein the PHB bits are copied to the EXP bits of the MPLS shim header. In the most general definition, two iFCP gateways are separated by one or more independently managed IP regions that implement some of the QoS solutions mentioned above. A QoS-capable IP region supports the negotiation and establishment of a service contract specifying the forwarding service through the region. Such contract and negotiation rules are outside the scope of this document. In the case of IP regions with DiffServ QoS, the reader should refer to Service Level Specifications (SLS) and Traffic Conditioning Specifications (TCS) (as defined in [DIFTERM]). Other aspects of a
service contract are expected to be non-technical and thus are outside of the IETF scope. Because fibre channel Class 2 and Class 3 do not currently support fractional bandwidth guarantees, and because iFCP is committed to supporting fibre channel semantics, it is impossible for an iFCP gateway to infer bandwidth requirements autonomously from streaming fibre channel traffic. Rather, the requirements on bandwidth or other network parameters need to be administratively set into an iFCP gateway, or into the entity that will actually negotiate the forwarding service on the gateway's behalf. Depending on the QoS techniques available, the stipulation of a forwarding service may require interaction with network ancillary functions, such as admission control and bandwidth brokers (via RSVP or other signaling protocols that an IP region may accept). The administrator of a iFCP gateway may negotiate a forwarding service with IP region(s) for one, several, or all of an iFCP gateway's TCP sessions used by an iFCP gateway. Alternately, this responsibility may be delegated to a node downstream. Since one TCP connection is dedicated to each iFCP session, the traffic in an individual N_PORT to N_PORT session can be singled out by iFCP- unaware network equipment as well. For rendering the best emulation of fibre channel possible over IP, it is anticipated that typical forwarding services will specify a fixed amount of bandwidth, null losses, and, to a lesser degree of relevance, low latency and low jitter. For example, an IP region using DiffServ QoS may support SLSes of this nature by applying EF DSCPs to the iFCP traffic.12. IANA Considerations
The IANA-assigned port for iFCP traffic is port number 3420. An iFCP Portal may initiate a connection using any TCP port number consistent with its implementation of the TCP/IP stack, provided each port number is unique. To prevent the receipt of stale data associated with a previous connection using a given port number, the provisions of [RFC1323], Appendix B, SHOULD be observed.13. Normative References
[AESCBC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[AESCTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [ENCAP] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C., and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003. [FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling (FC-FS), Rev 1.70, INCITS Project 1331D, February 2002 [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC- GS3)", revision 7.01, INCITS Project 1356-D, November 2000 [FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC- SW2)", revision 5.2, INCITS Project 1305-D, May 2001 [FCP-2] dpANS T10, "Fibre Channel Protocol for SCSI, Second Version", revision 8, INCITS Project 1144D, September 2002 [ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, N. [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [SECIPS] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols Over IP", RFC 3723, April 2004.14. Informative References
[AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)", Draft, 2001, Available from http://csrc.nist.gov/publications/drafts/dfips-AES.pdf [DIFTERM] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL- 2)", revision 7.0, NCITS Project 1133D, April 1999 [FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC- FLA)", revision 2.7, NCITS Project 1235-D, August 1997 [FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface Architecture Mapping Protocol (FC-VI)", NCITS Project 1332-D, July 2000. [KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated Loop", Robert W. Kembel, Northwest Learning Associates, 2000, ISBN 0-931836-84-0 [KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction", Northwest Learning Associates Inc., 2000, ISBN 0-931836-84-0 [MPSLDS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999. [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999. [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
Appendix A. iFCP Support for Fibre Channel Link Services
For reference purposes, this appendix enumerates all the fibre channel link services and the manner in which each shall be processed by an iFCP implementation. The iFCP processing policies are defined in Section 7. In the following sections, the name of a link service specific to a particular FC-4 protocol is prefaced by a mnemonic identifying the protocol.A.1. Basic Link Services
The basic link services are shown in the following table: Basic Link Services Name Description iFCP Policy ---- ----------- ---------- ABTS Abort Sequence Transparent BA_ACC Basic Accept Transparent BA_RJT Basic Reject Transparent NOP No Operation Transparent PRMT Preempted Rejected (Applies to Class 1 only) RMC Remove Connection Rejected (Applies to Class 1 only)A.2. Pass-Through Link Services
As specified in Section 7, the link service requests of Table 10 and the associated ACC response frames MUST be passed to the receiving N_PORT without altering the payload. Name Description ---- ----------- ADVC Advise Credit CSR Clock Synchronization Request CSU Clock Synchronization Update ECHO Echo ESTC Estimate Credit ESTS Establish Streaming FACT Fabric Activate Alias_ID FAN Fabric Address Notification
FCP_RJT FCP FC-4 Link Service Reject
FCP SRR FCP Sequence Retransmission
Request
FDACT Fabric Deactivate Alias_ID
FDISC Discover F_Port Service
Parameters
FLOGI F_Port Login
GAID Get Alias_ID
LCLM Login Control List Management
LINIT Loop Initialize
LIRR Link Incident Record
Registration
LPC Loop Port Control
LS_RJT Link Service Reject
LSTS Loop Status
NACT N_Port Activate Alias_ID
NDACT N_Port Deactivate Alias_ID
PDISC Discover N_Port Service
Parameters
PRLI Process Login
PRLO Process Logout
QoSR Quality of Service Request
RCS Read Connection Status
RLIR Registered Link Incident
Report
RNC Report Node Capability
RNFT Report Node FC-4 Types
RNID Request Node Identification
Data
RPL Read Port List
RPS Read Port Status Block
RPSC Report Port Speed
Capabilities
RSCN Registered State Change
Notification
RTV Read Timeout Value
RVCS Read Virtual Circuit Status
SBRP Set Bit-Error Reporting
Parameters
SCN State Change Notification
SCR State Change Registration
TEST Test
TPLS Test Process Login State
Table 10. Pass-Through Link Services
A.3. Special Link Services
The extended and FC-4 link services of Table 11 are processed by an iFCP implementation as described in the sections referenced in the table. Name Description Section ---- ----------- ------- ABTX Abort Exchange 7.3.1.1 ADISC Discover Address 7.3.1.2 ADISC Discover Address Accept 7.3.1.3 ACC FARP- Fibre Channel Address 7.3.1.4 REPLY Resolution Protocol Reply FARP- Fibre Channel Address 7.3.1.5 REQ Resolution Protocol Request LOGO N_PORT Logout 7.3.1.6 PLOGI Port Login 7.3.1.7 REC Read Exchange Concise 7.3.1.8 REC ACC Read Exchange Concise 7.3.1.9 Accept FCP REC FCP Read Exchange 7.3.2.1.1 Concise (see [FCP-2]) FCP REC FCP Read Exchange 7.3.2.1.2 ACC Concise Accept (see [FCP-2]) RES Read Exchange Status 7.3.1.10 Block RES ACC Read Exchange Status 7.3.1.11 Block Accept RLS Read Link Error Status 7.3.1.12 Block RRQ Reinstate Recovery 7.3.1.14 Qualifier RSI Request Sequence 7.3.1.15 Initiative RSS Read Sequence Status 7.3.1.13 Block SRL Scan Remote Loop 7.3.1.16 TPRLO Third Party Process 7.3.1.17 Logout TPRLO Third Party Process 7.3.1.18 ACC Logout Accept Table 11. Special Link Services
Appendix B. Supporting the Fibre Channel Loop Topology
A loop topology may be optionally supported by a gateway implementation in one of the following ways: a) By implementing the FL_PORT public loop interface specified in [FC-FLA]. b) By emulating the private loop environment specified in [FC-AL2]. Private loop emulation allows the attachment of fibre channel devices that do not support fabrics or public loops. The gateway presents such devices to the fabric as though they were fabric-attached. Conversely, the gateway presents devices on the fabric, whether they are locally or remotely attached, as though they were connected to the private loop. Private loop support requires gateway emulation of the loop primitives and control frames specified in [FC-AL2]. These frames and primitives MUST be locally emulated by the gateway. Loop control frames MUST NOT be sent over an iFCP session.B.1. Remote Control of a Public Loop
A gateway MAY disclose that a remotely attached device is connected to a public loop. If it does, it MUST also provide aliases representing the corresponding Loop Fabric Address (LFA), DOMAIN_ID, and FL_PORT Address Identifier through which the public loop may be remotely controlled. The LFA and FL_PORT address identifier both represent an N_PORT that services remote loop management requests contained in the LINIT and SRL extended link service messages. To support these messages, the gateway MUST allocate an NL_PORT alias so that the corresponding alias for the LFA or FL_PORT address identifier can be derived by setting the Port ID component of the NL_PORT alias to zero.
Acknowledgements
The authors are indebted to those who contributed material and who took the time to carefully review and critique this specification including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members of the IPS working group. For review of the iFCP security policy, the authors are further indebted to the authors of the IPS security document [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), and Jesse Walker (Intel).
Author's Addresses
Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the authors. Charles Monia 7553 Morevern Circle San Jose, CA 95135 EMail: charles_monia@yahoo.com Rod Mullendore McDATA 4555 Great America Pkwy Suite 301 Santa Clara, CA 95054 Phone: 408-519-3986 EMail: Rod.Mullendore@MCDATA.com Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA Phone: 978-288-7708 EMail: travos@nortel.com Wayland Jeong TROIKA Networks, Inc. 2555 Townsgate Road, Suite 105 Westlake Village, CA 91361 Phone: 805-371-1377 EMail: wayland@TroikaNetworks.com Mark Edwards Adaptec (UK) Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD Phone: +44 (0)117 930 9600 EMail: mark_edwards@adaptec.com
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.