Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4172


iFCP - A Protocol for Internet Fibre Channel Storage Networking

Part 4 of 4, p. 86 to 111
Prev RFC Part


prevText      Top      Up      ToC       Page 86 
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 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      Up      ToC       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      Up      ToC       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

       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      Up      ToC       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

   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      Up      ToC       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

   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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

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      Up      ToC       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      Up      ToC       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

Top      Up      ToC       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      Up      ToC       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

Top      Up      ToC       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.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      Up      ToC       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

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      Up      ToC       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      Up      ToC       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      Up      ToC       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

   [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      Up      ToC       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      Up      ToC       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

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      Up      ToC       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      Up      ToC       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

         Name         Description                    Section
         ----         -----------                    -------

         ABTX         Abort Exchange       
         ADISC        Discover Address     
         ADISC        Discover Address Accept
         FARP-        Fibre Channel Address
         REPLY        Resolution Protocol
         FARP-        Fibre Channel Address
         REQ          Resolution Protocol
         LOGO         N_PORT Logout        
         PLOGI        Port Login           
         REC          Read Exchange Concise
         REC ACC      Read Exchange Concise
         FCP REC      FCP Read Exchange   
                       Concise (see [FCP-2])
         FCP REC      FCP Read Exchange   
         ACC          Concise Accept (see
         RES          Read Exchange Status 
         RES ACC      Read Exchange Status 
                       Block Accept
         RLS          Read Link Error Status
         RRQ          Reinstate Recovery   
         RSI          Request Sequence     
         RSS          Read Sequence Status 
         SRL          Scan Remote Loop     
         TPRLO        Third Party Process  
         TPRLO        Third Party Process  
         ACC          Logout Accept

                  Table 11. Special Link Services

Top      Up      ToC       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

   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      Up      ToC       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      Up      ToC       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


   Rod Mullendore
   4555 Great America Pkwy
   Suite 301
   Santa Clara, CA 95054

   Phone: 408-519-3986

   Franco Travostino
   600 Technology Park Drive
   Billerica, MA 01821 USA

   Phone: 978-288-7708

   Wayland Jeong
   TROIKA Networks, Inc.
   2555 Townsgate Road, Suite 105
   Westlake Village, CA  91361

   Phone: 805-371-1377

   Mark Edwards
   Adaptec (UK) Ltd.
   4th Floor, Howard House
   Queens Ave, UK.  BS8 1SD

   Phone: +44 (0)117 930 9600

Top      Up      ToC       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.