SM-Related Protection Mechanisms

Subnet Has One or More SMs

In this section, reference is made to the Master SM and Standby SMs.

At a minimum, a subnet must contain one SM, referred to as the Master SM. It has the responsibility of managing that subnet. A subnet may contain additional SMs, but only one SM may act as the Master SM. The other SMs remain in either the Standby or the Not-Active state.

The chapter entitled, “Multiple SMs” on page 851 provides a detailed description of how a Master SM is chosen from multiple SMs in a subnet.

Management Key (M_Key)

The Problem: Rogue SM Attempts Attribute Access

The Master SM for a subnet is the only SM permitted to manage that subnet. IBA includes a mechanism that enables a device to detect an attribute access attempt by an SM other than the one that originally configured it (i.e., the Master SM for that subnet).

Solution: Access Is Denied Without Correct Key

Each Port Has M_Key Attribute

Each CA and router port has its own dedicated 64-bit PortInfo.M_Key attribute. There is, however, only one M_Key per switch (on port 0, its management port).

Key Must Match To Access a Device's Attributes

In order to successfully access a device's SM-related attributes, the SM must supply the correct key (M_Key) in its SMP. The device's SMA compares the M_Key in the SMP to the port's assigned M_Key.

How SM Accesses Attributes Before M_Key Assignment

Unless a port's M_Key is stored in NV memory, it's initial state is zero. Any SM can access (and update) a port's SM-related attributes while the port's M_Key is zero.

M_Key Use Is Optional

Whether or not the Master SM chooses to assign M_Keys to the ports in the subnet is optional. If it doesn't assign M_Keys, all port M_Keys remain cleared to zero (assuming that the M_Keys assigned in a previous power-on session are not stored in NV memory) and no M_Key comparison is performed upon receipt of an SMP.

Initial M_Key Assignment

A port's M_Key is initially assigned by the Master SM and the Master SM then includes that M_Key in any SMP issued to access any of the port's SM-related attributes. Note that the Master SM may assign a different key to each port.

Port's Treatment of SMP With Key Mismatch

Once a non-zero M_Key has been assigned to a port by the Master SM, the port silently drops SMPs containing an M_Key that doesn't match the one assigned to the port.

The Key Comparison

The M_Key comparison process uses the following elements:

• The M_Key contained in the SMP.

• The port's PortInfo.M_Key attribute element.

• The port's 2-bit PortInfo.M_KeyProtectBits attribute element.

Figure 16-2 on page 326 illustrates the M_Key comparison process performed by the destination port upon receipt of an SMP. The state of the M_KeyProtectBits attribute element affords varying levels of access protection. Table 16-3 on page 327 provides a description of the various M_KeyProtectBits attribute settings. When initially powered up or reset, a port's M_Key, M_KeyProtectBits, and M_KeyLeasePeriod (covered in “Port Logic Detects Death of Master SM” on page 328) are either:

• cleared to zero if NV memory is not used or

• set to a value stored in NV memory.

Table 16-3. M_Key Verification

PortInfo.M_KeyProtectBits	Compare Operation
00b	Port's M_KeyProtectBits revert to this state under two conditions: On power-up or reset (if M_KeyProtectBits is not stored in NV memory). When a lease timeout occurs (due to the death of the current Master SM). See “Port Logic Detects Death of Master SM” on page 328. When the port's M_KeyProtectBits are in this state: On a read (i.e., SubnGet) of any attribute, no M_Key compare is performed and the response will return the attribute's current value. An attempted write (i.e., SubnSet) of any attribute succeeds if the M_Key supplied in the SMP matches the port's PortInfo.M_Key. Otherwise, the SubnSet SMP is silently dropped. An attempted Trap Repress operation (i.e., SubnTrap Repress) only succeeds if the M_Key supplied in the SMP matches the port's PortInfo.M_Key. Otherwise, the Subn TrapRepress SMP is silently dropped. See “Traps” on page 790 for a discussion of traps.
01b	On a read (i.e., SubnGet) of any attribute other than the port's M_Key, the access is permitted. On a read of the port's M_Key, the M_Key compare is performed and the response returns one of the following: - Port's currently assigned M_Key if SMP/PortInfo.M_Key match succeeds. - M_Key value of zero if SMP/PortInfo.M_Key match fails. An attempted write (i.e., SubnSet) of any of the port's attributes only succeeds if the M_Key supplied in the SMP matches the port's PortInfo.M_Key. Otherwise, the SubnSet SMP is silently dropped. An attempted trap repress operation (i.e., SubnTrapRepress) only succeeds if the M_Key supplied in the SMP matches the port's PortInfo.M_Key. Otherwise, the SubnTrapRepress SMP is silently dropped.
10b	An M_Key mismatch on a SubnGet or SubnSet of any attribute, or any SubnTrapRepress will result in the SMP being silently dropped.
11b

Port Logic Detects Death of Master SM

General

Refer to Figure 16-3 on page 329. There is a timer implemented in each port (the PortInfo.M_KeyLeasePeriod attribute element) to detect the death of the port's managing SM. It detects the cessation of Master SM-initiated SMP accesses to the port's attributes. This implies (and it is true) that the Master SM is expected to access one or more SM-related attributes on each port on a regularly scheduled basis. Upon detecting this timeout, the port then permits any SM to access its SM-related attributes, thereby permitting another SM to take over the management of the port.

Starting the Countdown and Handling a Timeout

When a SM with the wrong M_Key attempts to access any of the port's SM-related attributes, the following actions are taken:

- The port increments its PortInfo.M_KeyViolations counter by one.

- If the port supports traps and its ability to generate M_KeyViolation traps had previously been enabled by the Master SM, then the port sends a SubnTrap(Notice) MAD to inform the Master SM of the unauthorized access attempt. If the Master SM is still operational, it can refresh the lease period timer in response to the receipt of the trap.

- If the lease period countdown has not expired, the port logic takes one the following actions:

- If the lease period timeout had not previously been triggered to start its countdown, then trigger it.

- If the lease period countdown had previously been triggered, let it continue to count down.

- If the lease period has expired, then the port clears its M_KeyProtectBits attribute to zero, thereby permitting another SM to access its attributes (including the M_Key value assigned to it by the previous Master SM).

Other M_Key-Related Matters

• The M_Key, M_KeyProtectBits, and M_KeyLeasePeriod elements of the PortInfo attribute must be set using a single SubnSet(PortInfo) method execution.

• Receipt of a SubnGetResp(PortInfo) response SMP with the status field in the MAD header = 0 tells an SM that it has successfully accessed the PortInfo attribute and therefore has taken over management of the port.

• When a port is initially powered-up or reset, the M_Key, M_KeyProtectBits, and M_KeyLeasePeriod attribute elements are either:

  - cleared to zero if NV memory is not used, or

  - set to a value stored in NV memory.

• If the Master SM discovers that it doesn't have the proper M_Key to configure a CA, switch, or router, it notifies software (through an interface outside the scope of the specification).

• If M_Key protection is used, the Master SM must sweep the subnet at a rate that refreshes the lease period of every port in the subnet prior to a possible timeout occurring.

Subnet Manager Key (SM_Key)

Reminder

The chapter entitled “Multiple SMs” on page 851 provides a detailed description of how a Master SM is chosen from multiple SMs in a subnet.

The Problem

SM_Key checking prevents passing control to, and/or sharing vital information with, unauthorized SMs. SMs that are not authorized to manage a subnet must not be permitted to gain SM mastership, nor have access to privileged information (i.e., a port's M_Key and P_Keys).

The Solution

SM mastership can only be passed to an SM with the proper SM_Key and:

• higher priority, or

• the same priority and a numerically lower GUID.

Where is the SM_Key?

The SM_Key is a read-only, 64-bit value. Its format is outside the scope of the specification. Each SM (in the Master, Standby, Non-Active, or Discovering state) is connected to the subnet via a specific port on a device. That port implements the SMInfo attribute that contains (among other elements) the SMInfo.SM_Key value. The manner in which the SM_Key is assigned a value is outside the scope of the specification.

How SM_Key Is Used

On a Read of the SM_Key

A read of a port's SM_Key returns 0 “unless the requesting SM is proven to be the master, or the requester is otherwise authenticated” (this is a direct quote from the specification).

Handing Over Control To Another SM

The current Master only hands over control to an SM with higher-priority (its priority is contained in the port's SMInfo.Priority attribute element) and with the proper SM_Key. Note that the manner in which the Priority attribute element is assigned a value is outside the scope of the specification.

If the current Master discovers another Master with higher priority and an incorrect SM_Key, it must report this to software using a mechanism beyond the scope of the specification.

SA Guards Access to M_Key/P_Keys Assigned to Ports

The currently active SA (Subnet Administrator; typically a subset of the SM) must only share a port's M_Key and P_Keys with trusted SMs (i.e., those with the proper SM_Key). Note that the SM_Key is contained in each SA GMP.