Summary

  • RFC 5324 deliberately separates non-active policy objects that can be edited, an activation operation and its result, read-only active policy, negotiated Security Association pairs, ordered traffic selectors, counters, notification suppression and bounded rejection history.
  • A reliable receipt follows one decision across those boundaries. It does not infer enforcement from configuration, protected traffic from an SA row, or absence of failure from a missing notification or an empty bounded table.

The row was real, but its authority was prospective

An operator can create a complete-looking security policy in the T11 FC-SP policy MIB. It can name members, permitted managers, connectivity restrictions and attributes. Its storage may even be persistent. None of those facts says that the Fabric is enforcing it.

RFC 5324 mirrors the FC-SP policy model rather than flattening it. Non-active Policy Objects are the working set. A management entity edits them and constructs a new Policy Summary that points to the intended objects. A separate activate operation asks the Policy Enforcement Entity to replace the active set. The operation has a status and can succeed or fail. Only the active Policy Objects describe the policy currently being enforced.

That separation is the first evidence boundary. “The row exists” is configuration evidence. “Activation was requested” is action evidence. “The operation reported success” is transition evidence. “This is the read-only active object now observed” is current-state evidence. Each can be true while the next remains unproved.

A policy summary carries references and hashes

The active set is not just an unordered collection of rows. Its Policy Summary contains a pointer to each other active Policy Object and pairs every pointer with a cryptographic hash of the referenced object. The set includes one Switch Membership List, one Node Membership List, one IP Management List, zero or more Switch Connectivity Objects and zero or more Attribute Objects.

This design makes the summary a binding structure, but the binding must not be oversold. A matching hash can show that a summary refers to a particular object value. It does not independently prove that every switch has received the object, that every enforcement point has applied it or that the policy achieved the intended business outcome.

The administratively specified Fabric name resides in the Switch Membership List, not in the Policy Summary. An inventory builder that takes a convenient name from the wrong object can preserve valid bytes while assigning the wrong semantic owner.

Persistence is not editability, and neither is activation

RFC 5324 uses StorageType to describe the memory realization of configuration. A row can be volatile, non-volatile or permanent. Yet the MIB text explicitly warns that even when the value is permanent(4), none of the corresponding information needs to be writable.

Persistence answers whether state survives. Writability answers whether this management path can alter it. Activation answers whether the Fabric now enforces it. Those are three different questions. A compliance export that maps all three to a single “configured” Boolean loses the exact distinction that determines operational authority.

Active and non-active Policy Objects persist after a Security Policy Server session ends. Meanwhile, read consistency is guaranteed only inside a server session. A set of rows collected across separate, unlocked reads may each be authentic and still not represent one coherent epoch.

Authentication creates an option to establish an SA

FC-SP accommodates secret-, certificate- and password-based infrastructures. DH-CHAP, FCAP and FCPAP can perform mutual authentication and optionally produce a shared key. IKEv2-AUTH can combine authentication with SA management.

The operative verb matters: the resulting material may be used to establish Security Associations. A configured authentication method is not evidence that a transaction ran. A successful authentication is not automatically an SA. An SA is not automatically traffic. Traffic is not automatically an application success.

The MIB also records which external server protocol an entity uses to verify DH-CHAP responses. If no protocol is used, or the third party is unreachable, locally configured information may be used instead. Therefore, the configured external protocol names a possible verification path, not necessarily the one used for a particular authentication.

The Fibre Channel SA protocol is not IPsec

RFC 5324 describes the Fibre Channel Security Association Management protocol as a subset of IKEv2 suitable for Fibre Channel and explicitly says it is not IPsec. It can negotiate protection for FC-2 frames through ESP_Header or for Common Transport Information Units through CT_Authentication.

Borrowed concepts do not collapse protocol identities. A dashboard that labels every SA “IPsec” because it recognizes IKEv2 terms invents a protocol fact. The receipt needs the FC-SP mechanism, protected object class, transforms, direction and reporting entity.

Each active SA has an entry in the internal Security Association Database. The entry includes its SPI, sequence counter and transform parameters. SAs are unidirectional, but they exist as a same-type pair, one in each direction. Accordingly, t11FcSpSaPairTable has one row per active bidirectional pair.

The pair is active state, not universal coverage. It shows that the reporting entity has the two related SAs. It does not show that every frame selected them, that both directions carried traffic, or that an upper-layer operation completed.

Traffic Selectors decide what the SA can mean

The SADB contains ordered Traffic Selector entries. Some identify traffic to bypass or discard. Others identify traffic to protect or verify and point to the corresponding SA entry. Ordering matters because selectors are searched for a match in that order.

RFC 5324 exposes negotiated inbound and outbound selectors in separate tables and provides an SPI-based alternate lookup. A frame cannot be declared protected merely because an active SA exists somewhere in the same Fabric. The decision needs the direction, ordered selector match, action, SPI, transform and counter evidence for the relevant epoch.

Configured proposal tables are another distinct surface. They describe what an initiator will offer and what a responder will accept. A transform row can also record what was agreed during negotiation. Proposal, acceptability and negotiated result must remain separate columns; otherwise a policy preference becomes a fictional session outcome.

A default lifetime is not remaining lifetime

The authentication MIB includes a default SA lifetime, initially expressed as eight hours in seconds, with a separate unit field. The lifetime can instead be byte-based. It applies only when an SA has no explicitly specified lifetime. When the limit is reached, the SA must terminate and may need replacement.

Copying the default into every active row is therefore wrong. The active SA may have an explicit value, may use different units or may already have consumed part of its allowance. A useful receipt records source of lifetime, unit, initial value, observed remaining value, creation epoch, termination and replacement identity.

Notifications are intentionally incomplete

Most RFC 5324 notifications report control-plane events such as operator-initiated changes. t11FcSpSaNotifyAuthFailure is different: a bad ingress frame could trigger it for every frame. The RFC therefore requires rate control.

After the first authentication failure on an SA, later notifications for that SA are suppressed for a time window. Even the first occurrence for another SA can be suppressed once a configured number of SAs has generated a notification in that window. The failures themselves must still be detected and counted.

This is a decisive negative-evidence boundary. No trap does not mean no failure. It can mean notification disabled, per-SA suppression, Fabric-wide suppression, collector loss, agent restart or genuinely no event. The MIB offers elapsed and suppressed counters, but their meaning is tied to sysUpTime and the current window.

History can be correct and incomplete

The authentication rejection table has a configurable maximum from zero to 1000 rows. When full, it discards the oldest row to admit the new rejection. After an agent restart it may contain fewer rows. If the implementation does not support the table, the maximum is always zero.

An empty table therefore has several interpretations. Zero events is only one. A row may have aged out, the agent may have restarted, capacity may be zero or the feature may be unsupported. A bounded event list is a view, not a proof of historical absence.

The same discipline applies to last-notification fields. They describe the most recent notification since management restart, not the last policy event in absolute time. When the type is none, associated reason fields are irrelevant; when the request content is unavailable, the octet string can be empty. A missing diagnostic is not a successful operation.

Counters need an owner and a discontinuity

Some counters belong to the Security Policy Server on one Fabric. Others are per entity, per interface, per Fabric or non-transient aggregates of transient per-SA counters. InterfaceIndexOrZero can identify one interface or all interfaces in the management instance attached to that Fabric.

A number without its index tuple has no reliable owner. A delta without sysUpTime, restart evidence and counter-width handling has no reliable interval. Aggregates can outlive individual SA rows; active-row churn can occur without the aggregate resetting. The monitoring model must not join them by timestamp alone.

The decision receipt

For a policy change, retain management instance, Fabric index, locked server-session epoch, non-active object names and hashes, proposed summary, activation request source, operation status, failure reason and observed active summary after transition. For an SA decision, retain entity and interface, peer, direction, pair identity, SPI, negotiated transforms, selector order and action, lifetime source and units, counters, uptime and teardown or replacement.

For a failure claim, add notification enablement, window, maximum notified SAs, elapsed value, suppression count, relevant aggregate counter, rejection-table capacity, eviction/restart state and collector delivery. For a delivery claim, add the separate frame observation and upper-layer result. The MIB provides necessary evidence, but it does not collapse the chain on the operator's behalf.

Sources