in Index   Prev   Next

RFC 4172

iFCP - A Protocol for Internet Fibre Channel Storage Networking

Pages: 111
Proposed Standard
Updated by:  61727146
Part 4 of 4 – Pages 86 to 111
First   Prev   None

Top   ToC   RFC4172 - Page 86   prevText

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.
Top   ToC   RFC4172 - Page 87
   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

   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.
Top   ToC   RFC4172 - Page 88
   A gateway shall enter the Unsynchronized state:

   a) upon power-up and before successful completion of an SNTP query,

   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).
Top   ToC   RFC4172 - Page 89

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.
Top   ToC   RFC4172 - Page 90
   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.
Top   ToC   RFC4172 - Page 91
   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 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
Top   ToC   RFC4172 - Page 92
   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.
Top   ToC   RFC4172 - Page 93

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.
Top   ToC   RFC4172 - Page 94

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
Top   ToC   RFC4172 - Page 95
      [RFC2407] The Internet IP Security Domain of Interpretation for

      [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

   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:
Top   ToC   RFC4172 - Page 96
      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

   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

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.
Top   ToC   RFC4172 - Page 97
   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,

   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
Top   ToC   RFC4172 - Page 98
   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

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.
Top   ToC   RFC4172 - Page 99
   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].
Top   ToC   RFC4172 - Page 100

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
Top   ToC   RFC4172 - Page 101
   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.
Top   ToC   RFC4172 - Page 102
   [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.
Top   ToC   RFC4172 - Page 103
   [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 [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.
Top   ToC   RFC4172 - Page 104
   [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

   [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.
Top   ToC   RFC4172 - Page 105

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
Top   ToC   RFC4172 - Page 106
               FCP_RJT      FCP FC-4 Link Service Reject
               FCP SRR      FCP Sequence Retransmission
               FDACT        Fabric Deactivate Alias_ID
               FDISC        Discover F_Port Service
               FLOGI        F_Port Login
               GAID         Get Alias_ID
               LCLM         Login Control List Management
               LINIT        Loop Initialize
               LIRR         Link Incident Record
               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
               PRLI         Process Login
               PRLO         Process Logout
               QoSR         Quality of Service Request
               RCS          Read Connection Status
               RLIR         Registered Link Incident
               RNC          Report Node Capability
               RNFT         Report Node FC-4 Types
               RNID         Request Node Identification
               RPL          Read Port List
               RPS          Read Port Status Block
               RPSC         Report Port Speed
               RSCN         Registered State Change
               RTV          Read Timeout Value
               RVCS         Read Virtual Circuit Status
               SBRP         Set Bit-Error Reporting
               SCN          State Change Notification
               SCR          State Change Registration
               TEST         Test
               TPLS         Test Process Login State

               Table 10. Pass-Through Link Services
Top   ToC   RFC4172 - Page 107

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 ADISC Discover Address ADISC Discover Address Accept ACC FARP- Fibre Channel Address REPLY Resolution Protocol Reply FARP- Fibre Channel Address REQ Resolution Protocol Request LOGO N_PORT Logout PLOGI Port Login REC Read Exchange Concise REC ACC Read Exchange Concise Accept FCP REC FCP Read Exchange Concise (see [FCP-2]) FCP REC FCP Read Exchange ACC Concise Accept (see [FCP-2]) RES Read Exchange Status Block RES ACC Read Exchange Status Block Accept RLS Read Link Error Status Block RRQ Reinstate Recovery Qualifier RSI Request Sequence Initiative RSS Read Sequence Status Block SRL Scan Remote Loop TPRLO Third Party Process Logout TPRLO Third Party Process ACC Logout Accept Table 11. Special Link Services
Top   ToC   RFC4172 - Page 108

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.
Top   ToC   RFC4172 - Page 109


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).
Top   ToC   RFC4172 - Page 110

Author's Addresses

Comments should be sent to the ips mailing list ( or to the authors. Charles Monia 7553 Morevern Circle San Jose, CA 95135 EMail: Rod Mullendore McDATA 4555 Great America Pkwy Suite 301 Santa Clara, CA 95054 Phone: 408-519-3986 EMail: Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA Phone: 978-288-7708 EMail: Wayland Jeong TROIKA Networks, Inc. 2555 Townsgate Road, Suite 105 Westlake Village, CA 91361 Phone: 805-371-1377 EMail: Mark Edwards Adaptec (UK) Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD Phone: +44 (0)117 930 9600 EMail:
Top   ToC   RFC4172 - Page 111
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

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

   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-


   Funding for the RFC Editor function is currently provided by the
   Internet Society.