Tech-invite   3GPPspecs   RFCs   Search in Tech-invite

in Index   Prev   Next

RFC 5324

MIB for Fibre-Channel Security Protocols (FC-SP)

Pages: 216
Group: IMSS
Proposed STD
Part 1 of 7 – Pages 1 to 19
None   None   Next

Top   ToC   RFC5324 - Page 1
Network Working Group                                       C. DeSanti
Request for Comments: 5324                                    F. Maino
Category: Standards Track                                K. McCloghrie
                                                         Cisco Systems
                                                        September 2008

            MIB for Fibre-Channel Security Protocols (FC-SP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for information related
   to FC-SP, the Security Protocols defined for Fibre Channel.

Table of Contents

   1. Introduction ....................................................3
   2. The Internet-Standard Management Framework ......................3
   3. Overview of Fibre Channel .......................................3
      3.1. Introduction ...............................................3
      3.2. Zoning .....................................................4
      3.3. Virtual Fabrics ............................................5
      3.4. Security ...................................................5
           3.4.1. Authentication ......................................5
           3.4.2. Security Associations ...............................6
           3.4.3. Fabric Security Policies ............................7
           3.4.4. Policy Model ........................................8
           3.4.5. Policy Objects ......................................9
         Policy Object Names .......................10
           3.4.6. Three Kinds of Switches ............................10
           3.4.7. Security Policy Management .........................11
           3.4.8. FC-SP Zoning .......................................11
   4. Document Overview ..............................................12
      4.1. Fibre Channel Management Instance .........................12
      4.2. Entity Name ...............................................12
      4.3. Fabric Index ..............................................13
      4.4. Interface Index ...........................................13
      4.5. Syntax for Policy Object Names ............................14
Top   ToC   RFC5324 - Page 2
      4.6. Certificates, CAs, and CRLs ...............................14
      4.7. Traffic Selectors .........................................15
      4.8. The MIB Modules ...........................................16
           4.8.1. The T11-FC-SP-TC-MIB Module ........................16
           4.8.2. The T11-FC-SP-AUTHENTICATION-MIB Module ............16
           4.8.3. The T11-FC-SP-ZONING-MIB Module ....................16
           4.8.4. The T11-FC-SP-POLICY-MIB Module ....................17
           4.8.5. The T11-FC-SP-SA-MIB Module ........................17
      4.9. Rate Control for Notifications ............................18
   5. Relationship to Other MIB Modules ..............................19
   6. MIB Module Definitions .........................................20
      6.1. The T11-FC-SP-TC-MIB Module ...............................20
      6.2. The T11-FC-SP-AUTHENTICATION-MIB Module ...................33
      6.3. The T11-FC-SP-ZONING-MIB Module ...........................52
      6.4. The T11-FC-SP-POLICY-MIB Module ...........................64
      6.5. The T11-FC-SP-SA-MIB Module ..............................152
   7. IANA Considerations ...........................................204
   8. Security Considerations .......................................204
      8.1. Information Not Defined in This Document .................204
      8.2. The T11-FC-SP-TC-MIB Module ..............................204
      8.3. The T11-FC-SP-AUTHENTICATION-MIB Module ..................205
      8.4. The T11-FC-SP-ZONING-MIB Module ..........................206
      8.5. The T11-FC-SP-POLICY-MIB Module ..........................207
      8.6. The T11-FC-SP-SA-MIB Module ..............................209
      8.7. Recommendations Common to All MIB Modules ................211
   9. Normative References ..........................................212
   10. Informative References .......................................213
   11. Acknowledgements .............................................215
Top   ToC   RFC5324 - Page 3
1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for information
   concerning the Fibre Channel Security Protocols (FC-SP), as specified
   in [FC-SP].  The FC-SP standard includes the definition of protocols
   to authenticate Fibre Channel entities, protocols to set up session
   keys, protocols to negotiate the parameters required to ensure frame-
   by-frame integrity and confidentiality, and protocols to establish
   and distribute policies across a Fibre Channel Fabric.

   This memo was initially developed by the INCITS T11 committee
   (, which subsequently approved it for forwarding
   to the IETF.

   This memo uses one of the following terms:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in BCP 14, RFC 2119

2.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base, or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580

3.  Overview of Fibre Channel

3.1.  Introduction

   Fibre Channel (FC) is logically a bidirectional point-to-point serial
   data channel, structured for high performance.  Fibre Channel
   provides a general transport vehicle for higher-level protocols such
   as Small Computer System Interface (SCSI) command sets, the High-
   Performance Parallel Interface (HIPPI) data framing, IP (Internet
   Protocol), IEEE 802.2, and others.
Top   ToC   RFC5324 - Page 4
   Physically, Fibre Channel is an interconnection of multiple
   communication points, called N_Ports, interconnected either by a
   switching network, called a Fabric, or by a point-to-point link.  A
   Fibre Channel "Node" consists of one or more N_Ports.  A Fabric may
   consist of multiple Interconnect Elements, some of which are
   Switches.  An N_Port connects to the Fabric via a port on a Switch
   called an F_Port.  When multiple FC Nodes are connected to a single
   port on a Switch via an "Arbitrated Loop" topology, the Switch port
   is called an FL_Port, and the Nodes' ports are called NL_Ports.  The
   term Nx_Port is used to refer to either an N_Port or an NL_Port.  The
   term Fx_Port is used to refer to either an F_Port or an FL_Port.  A
   Switch port, which is interconnected to another Switch port via an
   Inter-Switch Link (ISL), is called an E_Port.  A B_Port connects a
   bridge device with an E_Port on a Switch; a B_Port provides a subset
   of E_Port functionality.

   Many Fibre Channel components, including the Fabric, each Node, and
   most ports, have globally unique names.  These globally unique names
   are typically formatted as World Wide Names (WWNs).  More information
   on WWNs can be found in [FC-FS-2].  WWNs are expected to be
   persistent across agent and unit resets.

   Fibre Channel frames contain 24-bit address identifiers that identify
   the frame's source and destination ports.  Each FC port has both an
   address identifier and a WWN.  When a Fabric is in use, the FC
   address identifiers are dynamic and are assigned by a Switch.  Each
   octet of a 24-bit address represents a level in an address hierarchy,
   with a Domain_ID being the highest level of the hierarchy.

3.2.  Zoning

   Zones within a Fabric provide a mechanism to control frame delivery
   between Nx_Ports ("Hard Zoning") or to expose selected views of Name
   Server information ("Soft Zoning").

   Communication is only possible when the communicating endpoints are
   members of a common zone.  This technique is similar to virtual
   private networks in that the Fabric has the ability to group devices
   into Zones.

   Hard zoning and soft zoning are two different means of realizing
   this.  Hard zoning is enforced in the Fabric (i.e., Switches),
   whereas soft zoning is enforced at the endpoints (e.g., Host Bus
   Adapters) by relying on the endpoints to not send traffic to an
   N_Port_ID not obtained from the Name Server with a few exceptions for
   well known Addresses (e.g., the Name Server).
Top   ToC   RFC5324 - Page 5
   Administrators create Zones to increase network security, and prevent
   data loss or corruption, by controlling access between devices or
   user groups.

3.3.  Virtual Fabrics

   The standard for an interconnecting Fabric containing multiple Fabric
   Switch elements is [FC-SW-4].  [FC-SW-4] carries forward the earlier
   specification for the operation of a single Fabric in a physical
   infrastructure, and augments it with the definition of Virtual
   Fabrics and with the specification of how multiple Virtual Fabrics
   can operate within one or more physical infrastructures.  The use of
   Virtual Fabrics provides for each frame to be tagged in its header to
   indicate which one of several Virtual Fabrics that frame is being
   transmitted on.  All frames entering a particular "Core Switch"
   [FC-SW-4] (i.e., a physical Switch) on the same Virtual Fabric are
   processed by the same "Virtual Switch" within that Core Switch.

3.4.  Security

   The Fibre Channel Security Protocols (FC-SP) standard [FC-SP]
   describes the protocols used to implement security in a Fibre Channel
   Fabric, including the definition of:

      - protocols to authenticate Fibre Channel entities,

      - protocols to set up session keys,

      - protocols to negotiate the parameters required to ensure frame-
        by-frame integrity and confidentiality, and

      - protocols to establish and distribute (security) policies across
        a Fibre Channel Fabric.

3.4.1.  Authentication

   Two entities may negotiate whether authentication is required and
   which Authentication Protocol is to be used.  Authentication can be
   used in Switch-to-Switch, Node-to-Switch, and Node-to-Node
   communication.  The defined Authentication Protocols are able to
   perform mutual authentication with optional shared key establishment.
   The shared key computed at the end of an Authentication Transaction
   may be used to establish Security Associations.
Top   ToC   RFC5324 - Page 6
   The Fabric security architecture is defined for several
   authentication infrastructures.  Secret-based, certificate-based, and
   password-based authentication infrastructures are accommodated.
   Specific authentication protocols that directly leverage these three
   authentication infrastructures are defined.

   With a secret-based infrastructure, entities within the Fabric
   environment that establish a security relationship share a common
   secret or centralize the secret administration in an external (e.g.,
   RADIUS [RFC2865], Diameter [RFC3588], or Terminal Access Controller
   Access Control System (TACACS) [RFC1492]) server.  Entities may
   mutually authenticate with other entities by using the Diffie-Hellman
   Challenge Handshake Authentication Protocol (DH-CHAP) [FC-SP].
   Security Associations may be set up using the session key computed at
   the end of the DH-CHAP transaction.

   With a certificate-based infrastructure, entities within the Fabric
   environment are certified by a trusted Certificate Authority (CA).
   The resulting certificates bind each entity to a public-private key
   pair that may be used to mutually authenticate with other certified
   entities via the Fibre Channel Certificate Authentication Protocol
   (FCAP) [FC-SP].  Security Associations may be set up by using these
   entity certificates and associated keys or by using the session key
   computed at the end of the FCAP transaction.

   With a password-based infrastructure, entities within the Fabric
   environment that establish a security relationship have knowledge of
   the password-based credential material of other entities.  Entities
   may use this credential material to mutually authenticate with other
   entities using the Fibre Channel Password Authentication Protocol
   (FCPAP) [FC-SP].  Security Associations may be set up using the
   session key computed at the end of the FCPAP transaction.

   In addition to DH-CHAP, FCAP, and FCPAP, one other Authentication
   Protocol is defined: Internet Key Exchange Protocol version 2-AUTH
   (IKEv2-AUTH), which refers to the use of an SA Management Transaction
   of the Security Association Management Protocol (see below) to
   perform two functions: not only SA management but also
   authentication.  The credentials used in an IKEv2-AUTH transaction
   are either strong shared secrets or certificates.

3.4.2.  Security Associations

   A subset of the IKEv2 protocol [RFC4306] suitable for Fibre Channel
   is defined as the (Fibre Channel) Security Association Management
   protocol [RFC4595].  This protocol -- which is *not* IPsec --
   provides the means to establish Security Associations (SAs) between
   Fibre Channel entities.  Traffic Selectors are defined to specify
Top   ToC   RFC5324 - Page 7
   which type of traffic has to be protected by which SA, and what the
   characteristics of the protection are.  Two mechanisms are available
   to protect specific classes of traffic:

      - ESP_Header is used to protect FC-2 frames (see [FC-FS-2] and the
        conceptually similar mechanisms in [RFC4303]), and

      - CT_Authentication is used to protect CT_IUs (Common Transport
        Information Units) [FC-GS-5].

   An entity protecting specific classes of traffic maintains an
   internal Security Association Database (SADB) that contains the
   currently active Security Associations and Traffic Selectors.

   Each active SA has a Security Association entry in the SADB.  Each SA
   entry includes the SA's SPI (the Security Parameters Index, which is
   included in frames transmitted on the SA), a Sequence Number counter,
   and the parameters for the selected transforms (e.g., encryption
   algorithm, integrity algorithm, mode of operation of the algorithms,

   Each active Traffic Selector has an entry in the SADB that indicates
   whether it is used for ingress traffic or for egress traffic.  These
   Traffic Selector entries are ordered such that they are searched
   (when checking for a match) in the given order.  Two types of Traffic
   Selector entries may be present:

      - Traffic Selector entries identifying FC-2 frames or CT_IUs to be
        bypassed or discarded; and

      - Traffic Selector entries identifying FC-2 frames or CT_IUs to be
        protected or verified.  These entries point to the corresponding
        SA entry defining the parameters and the security processing to
        be performed.

   SAs are unidirectional, but they always exist as an SA pair of the
   same type, one in each direction.

3.4.3.  Fabric Security Policies

   Two separate approaches to defining Policies are adopted in FC-SP,
   but both approaches follow the same general concept for their Policy
   model.  One is the definition of a Policy Model for Fabric Policies
   that focus on Security.  These Security Policies specify the
   membership and connectivity allowed within a Fabric, and also which
   IP hosts are allowed to manage a Fabric.
Top   ToC   RFC5324 - Page 8
   The other approach is to define a variant of the Enhanced Zoning
   model defined in [FC-SW-4] and [FC-GS-5], such that the variant
   specifies extensions for use in a secure environment.  This variant
   of Zoning, denoted as "FC-SP Zoning", follows the same general
   concepts of the Policy model for Security Policies, but keeps Zoning
   management and enforcement completely independent from the management
   and enforcement of other policies.

3.4.4.  Policy Model

   Figure 25 of [FC-SP] depicts FC-SP's policy management model like

   *****          ************************
   *   *          *  Policy              *    *********************
   * M *  Add,    *  Configuration       *    * Policy            *
   * A *  Get,    *  Entity              *    * Enforcement       *
   * N *  Remove  *                      *    * Entity            *
   * A *  Policy  *  +----------------+  *    *                   *
   * G *  Objects *  | Non-Active     |  *    *  +-------------+  *
   * I *<-------->*  | Policy Objects |==*====*=>| Active      |  *
   * N *          *  +----------------+  *    *  | Policy      |  *
   * G *          ************************    *  | Objects     |  *
   *   *                                      *  +-------------+  *
   *   *              Activate Policy Summary *                   *
   * E *=====================================>*  +-------------+  *
   * N *            Deactivate Policy Summary *  | Policy      |  *
   * T *=====================================>*  | Summary     |  *
   * I *                                      *  | Object      |  *
   * T *            Get Policy Summary        *  +-------------+  *
   * Y *<-------------------------------------*                   *
   *   *            Get Policy Objects        *                   *
   *   *<-------------------------------------*                   *
   *****                                      *********************

   Note that the arrows in the picture above are used to indicate the
   movement of "data", rather than the direction of "messages", e.g.,
   for a "Get" (with no data) in one direction which invokes a
   "Response" (typically with data) in the reverse direction, the
   diagram has arrows only for the "with data" direction.
Top   ToC   RFC5324 - Page 9
3.4.5.  Policy Objects

   The Policies to be enforced by a Fabric are specified in a set of
   Policy Objects.  The various types of Policy Objects are:

      - The Policy Summary Object is a list of pointers to other Policy
        Objects, one pointer per each other active Policy Object.  Each
        pointer in a Policy Summary Object is paired with a
        cryptographic hash of the referenced Policy Object.

      - The Switch Membership List Object is a Fabric-wide Policy Object
        that defines which Switches are allowed to be part of a Fabric.

      - The Node Membership List Object is a Fabric-wide Policy Object
        that defines which Nodes are allowed to be connected to a

      - The IP Management List Object is a Fabric-wide Policy Object
        that describes which IP hosts are allowed to manage a Fabric.

      - A Switch Connectivity Object is a per-Switch Policy Object that
        describes the topology restrictions for a specific Switch; it
        specifies the other Switches or Nodes to which the particular
        Switch may be connected at the Node level and/or at the Port

      - Attribute Objects are Fabric-wide Policy Objects that define
        optional attributes to be associated with Switches or Nodes.
        They allow the extension of this policy model by defining new
        attributes as required.

   Note that the administratively specified name for a Fabric is
   contained in the Switch Membership List Object (not in the Policy
   Summary Object).

   When FC-SP is in use, each Fabric has a set of active Policy Objects:

      - one Policy Summary Object,

      - one Switch Membership List Object,

      - one Node Membership List Object,

      - one IP Management List Object,

      - zero or more Switch Connectivity Objects, and

      - zero or more Attribute Objects.
Top   ToC   RFC5324 - Page 10
   The active Policy Objects specify the Policies currently being
   enforced.  In addition, policies not currently being enforced are
   contained in non-active Policy Objects.  To change the active Policy
   Objects, the non-active Policy Objects are edited as necessary and a
   new Policy Summary Object that includes/references the changed Policy
   Objects is activated.  Policy Object Names

   Every Policy Object has a name.  In a Fabric's database of Policy
   Objects, a Policy Object Name is specified as a type/length/value
   (see section 7.2 of [FC-SP]).  The possible types are:

      - Node_Name

      - Restricted Node_Name

      - Port_Name

      - Restricted Port_Name

      - Wildcard

      - Negated Wildcard

      - Alphanumeric Name

      - IPv6 Address Range

      - IPv4 Address Range

3.4.6.  Three Kinds of Switches

   For a Fabric composed of n Switches and m Nodes, the potential
   complexity of Switch Connectivity Objects is O(n**2) to describe
   Switch to Switch connections, and O(n*m) for Switch to Node
   connections.  To provide better scaling, the Switch Connectivity
   Objects are not Fabric-wide information, but are distributed only to
   where they are needed.  To support this, the policy model supports
   three kinds of Switches in a Fabric:

      - Server Switches, which maintain the Fabric-wide Policy Objects,
        all the Switch Connectivity Objects, and a full copy of the FC-
        SP Zoning Database;

      - Autonomous Switches, which maintain the Fabric-wide Policy
        Objects, their own Switch Connectivity Object, and a full copy
        of the FC-SP Zoning Database; and
Top   ToC   RFC5324 - Page 11
      - Client Switches, which maintain the Fabric-wide Policy Objects,
        their own Switch Connectivity Object, and a subset of the FC-SP
        Active Zone Set (which is the configurations of zones currently
        being enforced by a Fabric, see section of [FC-SW-4]).

3.4.7.  Security Policy Management

   Security Policy can be changed in a server session [FC-GS-5] with a
   Security Policy Server.  All write access to a Security Policy Server
   occurs within a server session.  While read access to a Security
   Policy Server may occur at any time, the consistency of the returned
   data is guaranteed only inside a server session.

   The Enhanced Commit Service [FC-SW-4] is used to perform Fabric
   operations as and when necessary (see table 144 of [FC-SP]).  Many of
   these operations are named as if they were acronyms, e.g., SSB for
   Server Session Begin; SSE for Server Session End; SW_ILS for Switch
   Fabric Internal Link Services; EACA for Enhanced Acquire Change
   Authorization; ERCA for Enhanced Release Change Authorization; SFC
   for Stage Fabric Configuration.

   Each server session begins and ends, with a SSB request and a SSE
   request respectively, sent to a Security Policy Server.  In the
   Fabric, the SSB requests a lock of the Fabric via an EACA SW_ILS,
   while the SSE requests a release of the lock via the ERCA SW_ILS
   [FC-SW-4].  Active and non-active Policy Objects are persistent in
   that they survive after the end of a server session.

3.4.8.  FC-SP Zoning

   To preserve backward compatibility with existing Zoning definitions
   and implementations, FC-SP Zoning is defined as a variant of the
   Enhanced Zoning model defined in [FC-SW-4] and [FC-GS-5] that follows
   the general concepts of the Policy model for Security Policy
   Management, but keeps Zoning management and enforcement completely

   FC-SP Zoning allows for some Switches to retain less than a complete
   replicated copy of the Zoning Database, as follows:

      - Server Switches maintain the policies data structures for all
        Switches in the Fabric plus a replica of the Zoning data

      - Autonomous Switches maintain only the subset of policies data
        structures relevant for their operations plus a replica of the
        Zoning Database; and
Top   ToC   RFC5324 - Page 12
      - Client Switches maintain only the subset of policies data
        structures and the subset of the Active Zone Set relevant for
        their operations.

   When Client Switches are deployed in a Fabric, at least one Server
   Switch must also be deployed in the same Fabric.  A client-server
   protocol allows Client Switches to dynamically retrieve the Zoning
   information they may require from the Server Switches.

   A management application manages the Fabric Zoning configuration
   through the Fabric Zone Server, while other policies are managed
   through the Security Policy Server.  A new Zoning Check Protocol
   replaces the Zone Merge Protocol [FC-SW-4], and new command codes are
   defined for the SFC SW_ILS to distribute the FC-SP Zoning
   configuration on a Fabric.  The Zoning definitions are ordered to
   allow for the computation of a hash of the Active Zone Set and a hash
   of the Zone Set Database, plus other optional security data (e.g.,
   for integrity protection of Zoning information).

4.  Document Overview

   This document defines five MIB modules that together provide the
   means for monitoring the operation of, and configuring some
   parameters of, one or more instances of the FC-SP protocols.

4.1.  Fibre Channel Management Instance

   A Fibre Channel management instance is defined in [RFC4044] as a
   separable managed instance of Fibre Channel functionality.  Fibre
   Channel functionality may be grouped into Fibre Channel management
   instances in whatever way is most convenient for the
   implementation(s).  For example, one such grouping accommodates a
   single SNMP agent having multiple AgentX [RFC2741] sub-agents, with
   each sub-agent implementing a different Fibre Channel management

   The object, fcmInstanceIndex, is IMPORTed from the FC-MGMT-MIB
   [RFC4044] as the index value to uniquely identify each Fibre Channel
   management instance, for example, within the same SNMP context
   ([RFC3411] section 3.3.1).

4.2.  Entity Name

   A central capability of FC-SP is the use of an Authentication
   Protocol.  The purpose of each of the possible Authentication
   Protocols is to allow a Fibre Channel entity to be assured of the
   identity of each entity with which it is communicating.  Examples of
   such entities are Fibre Channel Switches and Fibre Channel Nx_Ports.
Top   ToC   RFC5324 - Page 13
   Each entity is identified by a name.  The FC-MGMT-MIB [RFC4044]
   defines MIB objects for such names:

      - for entities that are Fibre Channel Switches, the definition of
        a Fibre Channel management instance allows multiple Switches to
        be managed by the same Fibre Channel management instance.  In
        this case, each entity is a Switch and has the name given by the
        MIB object, fcmSwitchWWN.

      - for entities other than Fibre Channel Switches, a Fibre Channel
        management instance can manage only one entity, and the name of
        the entity is given by the MIB object, fcmInstanceWwn.

4.3.  Fabric Index

   With multiple Fabrics, each Fabric has its own instances of the
   Fabric-related management instrumentation.  Thus, these MIB modules
   define all Fabric-related information in tables that are INDEX-ed by
   an arbitrary integer, named a "Fabric Index".  The syntax of a Fabric
   Index is T11FabricIndex, imported from T11-TC-MIB [RFC4439].  When a
   device is connected to a single physical Fabric, without use of any
   virtual Fabrics, the value of this Fabric Index will always be 1.  In
   an environment of multiple virtual and/or physical Fabrics, this
   index provides a means to distinguish one Fabric from another.

4.4.  Interface Index

   Several of the MIB modules defined in this document use the
   InterfaceIndexOrZero syntax in order to allow information to be
   specified/instantiated on a per-port/interface basis, e.g., for:
   statistics, Traffic Selectors, Security Associations, etc.  This
   allows the same object to be used either when there is a separate row
   for each of multiple ports/interfaces, or when multiple interfaces
   are represented by a single row.  The use of a zero value supports
   the simpler cases of: a) when there is only one port/interface, b)
   where the implementation chooses to aggregate the information for
   multiple ports/interfaces.  The minimum (for compliance) requirement
   is to implement any one of the above cases.

   When a Fabric Index and an object with the InterfaceIndexOrZero
   syntax are used together in a single INDEX clause, the
   InterfaceIndexOrZero object is listed before the Fabric Index in
   order to simplify management queries that retrieve information
   concerning multiple Fabrics connected to the same port/interface.
Top   ToC   RFC5324 - Page 14
4.5.  Syntax for Policy Object Names

   T11FcSpPolicyNameType and T11FcSpPolicyName are two Textual
   Conventions defined in this document (in the T11-FC-SP-TC-MIB module)
   to represent the types and values of Policy Object Names (see section above).  However, two of the nine possible types are IPv4
   Address Range and IPv6 Address Range.  It is standard practice in MIB
   modules to represent all IP addresses using the standard Textual
   Conventions defined in [RFC4001] for IP addresses: specifically,
   InetAddressType and InetAddress.  This document adheres to such
   standard practice to the following extent:

      - for MIB objects representing a Policy Object Name that can
        *only* be an IPv4 Address Range or an IPv6 Address Range, then
        those MIB objects are defined as a 3-tuple: (InetAddressType,
        InetAddress, InetAddress), in which the first address is the low
        end of the range, the second address is the high end of the
        range, and both addresses are of the type given by

      - for MIB objects representing a Policy Object Name that is
        (possibly) of a different type, i.e., it is not (necessarily) an
        IPv4 or IPv6 Address Range, then those MIB objects are defined
        as a 2-tuple: (T11FcSpPolicyNameType, T11FcSpPolicyName), in
        which the first object represents the type of Policy Object Name
        and the second object represents the value of the Policy Object
        Name.  For MIB objects defined in this manner, if and when they
        represent a range of IP addresses: a) the value of
        T11FcSpPolicyNameType differentiates between an IPv4 Address
        Range and an IPv6 Address Range; and b) the value of
        T11FcSpPolicyName is one string containing the concatenation of
        the two addresses that are the low and high addresses of the
        range.  This is the same format as used within FC-SP Policy
        Objects [FC-SP].

4.6.  Certificates, CAs, and CRLs

   In order to authenticate with the FCAP protocol, each entity,
   identified by a unique Name, is provided with: a digital certificate
   associated with that Name, the private/public key pair that
   corresponds to the certificate, and with the Root Certificate (the
   certificate of the signing Certification Authority).  To authenticate
   another entity, an entity is required to be provided with the
   certificate of the associated Certification Authority.

   FCAP requires entities to support at least four Root Certificates
   against which received corresponding certificates can be validated.
   Support for certificate chains and verification of certificate chains
Top   ToC   RFC5324 - Page 15
   containing more than one certificate is optional.  Entities need to
   be able to access a Certificate Revocation List (CRL) for each
   configured Root Certificate, if one is available from the CA.
   Certificates on the CRL are considered invalid.

   The management of certificates, Certification Authorities, and
   Certificate Revocation Lists is the same in Fibre Channel networks as
   it is in other networks.  Therefore, this document does not define
   any MIB objects for such management.

4.7.  Traffic Selectors

   When Traffic Selectors are compared against an ingress or egress
   frame in order to determine the security processing to be applied to
   that frame, there are circumstances in which multiple Traffic
   Selectors, specifying different actions, can match with the frame.
   Specifically, when matching against an egress frame to decide which
   active Security Association to transmit on, or, against an ingress
   frame unprotected by FC-SP, i.e., without an SPI value in it, to
   decide which action ('drop' or 'bypass') to apply.  For these cases,
   the MIB includes a unique precedence value for each Traffic Selector
   such that the one with the numerically lowest precedence value is
   determined to be the one that matches.  In contrast, ingress frames
   on active Security Associations (i.e., protected by FC-SP) are
   compared against the set of traffic selectors negotiated when the
   Security Association was set up and identified by the SPI value
   contained in the frame; the action taken depends on whether any
   Traffic Selector matches, but not on which one.

   This difference between ingress and egress Traffic Selectors on
   active Security Associations is reflected in having separate MIB
   tables defined for them: the table for Traffic Selectors on egress
   SAs, t11FcSpSaTSelNegOutTable, has a precedence value in its INDEX
   clause; whereas the table for Traffic Selectors on ingress SAs,
   t11FcSpSaTSelNegInTable, has an arbitrary integer value in its INDEX
   clause.  For 'drop' and 'bypass' Traffic Selectors, one table,
   t11FcSpSaTSelDrByTable, having a precedence value in its INDEX
   clause, is sufficient for both ingress and egress traffic.
Top   ToC   RFC5324 - Page 16
4.8.  The MIB Modules

4.8.1.  The T11-FC-SP-TC-MIB Module

   This MIB module defines Textual Conventions that are being, or have
   the potential to be, used in more than one MIB module.  The module
   also defines Object Identifiers to identify the Cryptographic
   Algorithms listed in [FC-SP] so that they can be used as the value of
   various MIB objects that specify the algorithms being/to be used by
   an FC-SP implementation.


   This MIB module specifies the management information required to
   manage FC-SP Authentication Protocols.  It defines three tables:

      - t11FcSpAuEntityTable -- a table of Fibre Channel entities that
        can be authenticated using FC-SP's Authentication Protocols,
        including the names, capabilities, and basic configuration
        parameters of the entities.

      - t11FcSpAuIfStatTable -- this table has two purposes: to be a
        list of the mappings of a FC-SP Authentication entity onto an
        interface and to contain Authentication Protocol per-interface

      - t11FcSpAuRejectTable -- a table of FC-SP Authentication Protocol
        transactions that were recently rejected.

   It also defines two notifications: one for sending a reject in
   response to an AUTH message and another for receiving a reject in
   response to an AUTH message.

4.8.3.  The T11-FC-SP-ZONING-MIB Module

   This MIB module specifies the extensions to the T11-FC-ZONE-SERVER-
   MIB module [RFC4936] for the management of FC-SP Zoning Servers.
   Specifically, it augments three tables defined in T11-FC-ZONE-SERVER-

      - t11FcSpZsServerTable -- to this table, it adds FC-SP Zoning
        information defined for Zone Servers.

      - t11ZsStatsTable -- to this table, it adds FC-SP Zoning
        statistics for Zone Servers.

      - t11ZsNotifyControlTable  -- to this table, it adds control
        information for FC-SP Zoning notifications.
Top   ToC   RFC5324 - Page 17
   It also defines two FC-SP Zoning notifications: one for success and
   one for failure in the joining of two Fabrics.

4.8.4.  The T11-FC-SP-POLICY-MIB Module

   This MIB module specifies management information that is used to
   manage FC-SP policies.  The MIB module has five parts:

      - Active Policy Objects - read-only MIB objects representing the
        set of active Policy Objects for each Fabric;

      - Activate/Deactivate Operations - read-write MIB objects for
        invoking operations, either 1) to activate policies that are
        specified as a set of non-active Policy Objects, or 2) to
        deactivate the currently active policies; also included are
        objects giving the status of invoked operations;

      - Non-Active Policy Objects - read-create MIB objects to create
        and modify non-active Policy Objects;

      - Statistics for FC-SP Security Policy Servers;

      - The definition and control of notifications for the success or
        failure of the activation or deactivation of FC-SP policies.

4.8.5.  The T11-FC-SP-SA-MIB Module

   This MIB module specifies the management information required to
   manage Security Associations established via FC-SP.  All of the
   tables in this MIB module are INDEX-ed by t11FcSpSaIfIndex, with
   syntax InterfaceIndexOrZero, which is either non-zero for a specific
   interface or zero for all (of the management instance's) interfaces
   to the particular Fabric.

   The MIB module consists of six parts:

      - a per-Fabric table, t11FcSpSaIfTable, of capabilities,
        parameters, status information, and counters; the counters
        include non-transient aggregates of per-SA transient counters;

      - three tables, t11FcSpSaPropTable, t11FcSpSaTSelPropTable, and
        t11FcSpSaTransTable, specifying the proposals for an FC-SP
        entity acting as an SA_Initiator to present to the SA_Responder
        during the negotiation of Security Associations.  The same
        information is also used by an FC-SP entity acting as an
        SA_Responder to decide what to accept during the negotiation of
Top   ToC   RFC5324 - Page 18
        Security Associations.  One of these tables,
        t11FcSpSaTransTable, is used not only for information about
        security transforms to propose and to accept, but also as agreed
        upon during the negotiation of Security Associations;

      - a table, t11FcSpSaTSelDrByTable, of Traffic Selectors having the
        security action of 'drop' or 'bypass' to be applied either to
        ingress traffic, which is unprotected by FC-SP, or to all egress

      - four tables, t11FcSpSaPairTable, t11FcSpSaTSelNegInTable,
        t11FcSpSaTSelNegOutTable, and t11FcSpSaTSelSpiTable, containing
        information about active bidirectional pairs of Security
        Associations; in particular, t11FcSpSaPairTable has one row per
        active bidirectional SA pair, t11FcSpSaTSelNegInTable and
        t11FcSpSaTSelNegOutTable contain information on the Traffic
        Selectors negotiated on the SAs, and the t11FcSpSaTSelSpiTable
        is an alternate lookup table such that the Traffic Selector(s)
        in use on a particular Security Association can be quickly
        determined based on its (ingress) SPI value;

      - a table, t11FcSpSaControlTable, of control and other information
        concerning the generation of notifications for events related to
        FC-SP Security Associations;

      - one notification, t11FcSpSaNotifyAuthFailure, generated on the
        occurrence of an Authentication failure for a received FC-2 or
        CT_IU frame.

4.9.  Rate Control for Notifications

   All but one of the notifications defined in the five MIB modules in
   this document are notifications that are generated based on events
   occurring in the "control plane", e.g., notifications that are
   generated at the frequency of operator-initiated activities.  The one
   exception is t11FcSpSaNotifyAuthFailure, which is generated based on
   an event occurring in the "data plane", and could (in a worst case
   scenario) occur for every received ingress frame.  Therefore, a
   method of rate controlling the generation of notifications is needed
   for t11FcSpSaNotifyAuthFailure, but not for any of the other

   For t11FcSpSaNotifyAuthFailure, rate control is achieved by
   specifying that a) after the first occurrence of an Authentication
   failure on any particular Security Association, the SNMP
   notifications for second and subsequent failures are suppressed for
   the duration of a time window and b) that even the notification for
   the first occurrence is suppressed after it is sent in the same time
Top   ToC   RFC5324 - Page 19
   window for a configured (in t11FcSpSaControlMaxNotifs) number of
   Security Associations within a Fabric.  Note that while these
   suppressions prevent the network from being flooded with
   notifications, the Authentication Failures themselves must still be
   detected and counted.

   The length of the time window is given by t11FcSpSaControlWindow, a
   read-write object in the t11FcSpSaControlTable.  If and when the time
   since the last generation of the notification is less than the value
   of sysUpTime (e.g., if one or more notifications have occurred since
   the last re-initialization of the management system), then
   t11FcSpSaControlElapsed and t11FcSpSaControlSuppressed contain the
   elapsed time since the last notification and the number of
   notifications suppressed in the window after sending the last one,
   respectively.  Otherwise, t11FcSpSaControlElapsed contains the value
   of sysUpTime and t11FcSpSaControlSuppressed has the value zero.

5.  Relationship to Other MIB Modules

   The first standardized MIB module for Fibre Channel [RFC2837] was
   focused on Fibre Channel Switches.  It was obsoleted by the more
   generic Fibre Channel Management MIB [RFC4044], which defines basic
   information for Fibre Channel Nodes and Switches, including
   extensions to the standard IF-MIB [RFC2863] for Fibre Channel
   interfaces.  Several other MIB modules have since been defined to
   extend [RFC4044] for various specific Fibre Channel functionality,
   (e.g., [RFC4438], [RFC4439], [RFC4625], [RFC4626], [RFC4747],
   [RFC4936], [RFC4935], and [RFC4983]).

   The MIB modules defined in this memo further extend [RFC4044] to
   cover the operation of Fibre Channel Security Protocols, as specified
   in [FC-SP].

   One part of the FC-SP specification is "FC-SP Zoning", which is an
   extension/variant of the Fibre Channel Zoning defined in [FC-GS-5].
   Management information for the latter is defined in the T11-FC-ZONE-
   SERVER-MIB module [RFC4936].  Consequently, the T11-FC-SP-ZONING-MIB
   module defined in this document defines the extensions to the T11-FC-
   ZONE-SERVER-MIB module that are needed to manage FC-SP Zoning.

   The MIB modules in this memo import some common Textual Conventions
   from T11-TC-MIB, defined in [RFC4439], and from INET-ADDRESS-MIB,
   defined in [RFC4001].

   If the RADIUS protocol is used for access to an external server,
   information about RADIUS Servers is likely to be available from the