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.
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).
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).
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.
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.
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.
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.
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 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.
PortInfo.M_KeyProtectBits | Compare Operation |
---|---|
00b | Port's M_KeyProtectBits revert to this state under two conditions:
|
01b |
|
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 |
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.
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).
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.
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.
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).
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.
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.
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).
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.
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.