Appendix – Security Features

SA Key is used to identify trusted SA requests.

Configuration Parameters

Standard SA has a concept of trust-based requests on the SA_Key that is part of each SA MAD. A trusted request is when the SA_Key value is not equal to zero but equals the SA configured value, while an untrusted request is when the SA_Key value equals zero in the request. If a request has a non-zero SA_Key value that is different from the configured SA key, it will be dropped and reported.

When SAETM is enabled, the SA limits the set of untrusted requests allowed. Untrusted requests that are not allowed according to SAETM will be silently dropped (for the set of untrusted requests allowed, see the following section below).

SAETM feature is disabled by default. To enable it, set the sa_enhanced_trust_model parameter to TRUE.

Additional SAETM Configuration Parameters

List of Untrusted SA Requests

The following table lists the untrusted requests allowed when SAETM is enabled:

Notes:

- When sa_etm_allow_untrusted_guidinfo_recis set to FALSE (and SAETM is enabled), the SA will drop GUIDInfoRecord Set/Delete untrusted requests.

- When sa_etm_allow_guidinfo_rec_by_vf is set to FALSE (and SAETM is enabled), the SA will drop GUIDInfoRecord Set/Delete requests from non-physical ports.

- In case sa_etm_allow_untrusted_guidinfo_recis FALSE, GUIDInfoRecord Set/Delete requests will become part of the SAETM set of untrusted requests allowed.

- When sa_etm_allow_guidinfo_rec_by_vf is FALSE, the requests will only be allowed from physical ports.

Proxy SA Requests

SA modification request (SET/DELETE) is identified as a proxy operation when the port corresponding with the requester source address (SLID from LRH / SGID from GRH) is diffident than the port for which the request applies:

• For MCMemberRecord, when the MCMemberRecord.PortGID field does not match the requester address.

  For ServiceRecord, when the ServiceRecord.ServiceGID field does not match requester address.

  For the GUIDInfoRecord, when the LID field in the RID of the record does not match the requester address.

When sa_etm_allow_untrusted_proxy_requestsis set to FALSE and SAETM is enabled, untrusted proxy requests will be dropped.

Registration Limits

When any of sa_etm_max_num_mcgs, sa_etm_max_num_srvcsor sa_etm_max_num_event_subsparameters is set to 0, the number of this parameter’s registrations can be unlimited. When the parameter’s value is different than 0, attempting to exceed the maximum number of registrations will result in the request being silently dropped. Consequently, the requester and request info will be logged, and an event will be generated for the Activity Manager.

The following parameters control the maximum number of registrations:

SAETM Logging

When requesting an operation that is not part of the SAETM set of untrusted requests, it will be silently dropped and eventually written to the SM log.

The logging of the dropped MADs is repressed to not overload the OpenSM log. If the request that needs to be dropped was received from the same requester many times consecutively, OpenSM logs it only if the request number is part of the following sequence:

0, 1, 2, 5, 10, 20, 50, 100, 200... (similar to the trap log repression).

SA can validate requester addresses by comparing the SLID and SGID of the incoming request. SA determines the requester port by the SLID and SGID field of the request. SGID spoofing is when the SGID and SLID do not match.

When sa_check_sgid_spoofingparameter is enabled, SA checks for SGID spoofing in every request that includes GRH, unless the SLID belongs to a router port in that same request. In case the request SGID does not match its SLID, the request will be dropped. The default value of this parameter is TRUE.

The ServiceKeyfeature may be used to allow authentication of the creation, replacement and deletion of ServiceRecords with selected ServiceNames, according to IB Specification.

SM Support mapping service name to service key using a file.

The path to service name to service key map file is set using *service_name2key_map_file* parameter in SM configuration file.

Each line in the file contains mapping from service name to service key (in IPv6 format).

For example:

            

            
```
SHArP.AggregationManager 1111:2222:3333:4444:5555:6666:7777:8888
```
        

M_Key Per Port

This feature increases protection on the fabric as a unique M_Key is generated and set for each HCA, router, or switch port.

OpenSM calculates an M_Key per port by performing a hash function on the port GUID of the device and the M_Key configured in opensm.conf.

To enable M_Key per port, set the parameter below in addition to the parameters listed in the previous section:

            

            
m_key_per_port TRUE
        

This section outlines the Subnet Manager (SM) feature for configuring class management keys.

The supported management classes include:

1. M_Key (Subnet Manager classes 0x01 and 0x81)

2. CC_Key (Congestion Control class 0x21)

3. VS_Key (Vendor Specific class 0x0A)

4. N2N_Key (Node-to-Node class 0x0C)

MADs are used to initialize and configure network devices in the subnet, and therefore, are considered privilege operation.

There is a mechanism to authorize management packets based on:

• A key specified in the MAD headers.

• A key stored locally on each HCA/Router port or switch port0 in the subnet.

Authentication is performed by the management entity at the destination port and is achieved by comparing the key contained in the MAD header with the key residing at the destination port.

As such, when the feature is enabled, MADs sent to network devices by diagnostics and monitoring tools should be sent with the correct key.

M_Key

Subnet Manager Class Parameters:

Notes:

• If m_key_per_port is enabled and m_key_protection_level is set to 0, the SM will override it to 2.

• If m_key_per_port is enabled and m_key is 0, the SM will automatically set it to 0xFFFFFFFFFFFFFFFF.

• If m_key_per_port is enabled and m_key_lease_period is 0, the SM will default it to 60 seconds.

Common Parameters for CC_Key / VS_Key / N2N_Key

For all management classes other than the Subnet Manager class, the key_mgr_seed parameter controls the seed used to generate unique keys per device for each class.

Configuration Parameters

Example Configuration

            

            
```
key_mgr_seed 0x0000000000000001
gmp_traps_threads_num 1
```
        

CC Key

The CC Key is a security mechanism for the Congestion Control (CC) Class 0x21. When enabled, the Subnet Manager assigns a unique CC Key to each port in the subnet that supports both the CC Class and CC Key feature. The extent of protection is controlled by configuration parameters in the SM configuration file.

Once enabled, if a device receives a Management Datagram (MAD) within the protected scope using an incorrect CC Key, it notifies the Subnet Manager of a key violation. (Refer to section 3.1.2: cc_key_lease_period for more details.)

Note: When the CC Key feature is enabled, all CC configuration MADs must carry the correct key. Therefore, Congestion Control can only be configured on a port after its CC Key has been set.

Support for CC Key requires Congestion Control to be either disabled or enabled (mlnx_congestion_control must be set to 1 or 2).

Configuration Parameters

Important: These configurations are valid only when non-zero keys are applied to the ports (i.e., cc_key_enable = 2). If ports are configured with a zero key, no protection is enforced.

Example

            

            
```
cc_key_enable 2
cc_key_lease_period 10
cc_key_protect_bit 1
cc_max_outstanding_mads 500
```
        

Vendor Specific (VS) Key

The VS Key is a security feature for the Vendor Specific (VS) Class 0xA. The Subnet Manager assigns a unique VS Key to each port in the subnet that supports the VS Class and the VS Key feature. The scope of protection is defined by parameters in the Subnet Manager’s configuration file.

Once the feature is enabled, if a device receives a Management Datagram (MAD) within the protected scope using an incorrect key, it notifies the Subnet Manager of a key violation. (See table below vs_key_lease_period for details.)

Configuration Parameters

Note that the above settings are only effective when non-zero keys are configured on the subnet ports (i.e., vs_key_enable is set to 2). Ports with a zero key are not protected.

Example Configuration

            

            
```
vs_key_enable 2
vs_key_lease_period 60
vs_key_ci_protect_bits 1
vs_max_outstanding_mads 500
```
        

Node-to-Node (N2N) Key

The N2N Key is a security feature for the Node-to-Node (N2N) Class 0xC. The Subnet Manager assigns a unique N2N Key to each port in the subnet that supports both the N2N Class and the N2N Key feature. The protection scope is defined through parameters in the Subnet Manager's configuration file.

Once the feature is enabled, if a device receives a Management Datagram (MAD) within the protected scope that contains an incorrect key, it notifies the Subnet Manager of the key violation.

Configuration Parameters

Please note that the above information is valid only if non-zero keys have been configured for the subnet ports (n2n_key_enable is set to 2). Ports with a zero key do not provide protection.

Example Configuration

            

            
```
n2n_key_enable 2
n2n_key_lease_period 10
n2n_key_protect_bit 1
n2n_max_outstanding_mads 500
```
        

Periodic Key Updates

The Subnet Manager (SM) supports periodic updates of the class management keys for network devices:

• The periodic key update feature applies to all management class keys supported by SM.

• This feature will take effect for management classes that are enabled and only on devices that support dual keys.

• Devices that do not support dual keys will not undergo periodic key updates.

• During each update cycle, SM will generate and assign new keys to all nodes based on a new random seed.

• After each key update, SM will update the relevant files (guid2mkey, guid2cckey, guid2vskey, guid2_m2n_key, guid2_n2n_key) with the new keys.

• The generated keys are unique to each port, derived from the SHA512 of:

  • /dev/urandom

  • Port GUID

  • Key type

• Periodic update will take effect per management class, if that class key is enabled. The sections above explain how to enable each key type (N2N, VS, CC, M_Keys).

In order to avoid potentially interfering with currently executing diagnostic tools, after startup, SM waits one interval before changing keys for devices.

Configuration Parameter

Example Configuration

            

            
```
# Perform a periodic update every 1440 minutes (24 hours), for each supporting class
periodic_key_update 1440
 
# Enable 
 
# Use random seed for M_Key
m_key 0xffffffffffffffff
m_key_per_port TRUE
m_key_lease_period 60
m_key_protection_level 2
 
# Use random seed for VS_Key, CC_Key and N2N_Key
key_mgr_seed 0xffffffffffffffff
 
# Enable VS_Key
vs_key_enable 2
vs_key_lease_period 60
vs_key_ci_protect_bits 1
 
# Enable N2N_Key
n2n_key_enable 2
n2n_key_lease_period 60
n2n_key_protect_bit 1
 
# Congestion control disabled, but CC_Key is enabled
mlnx_congestion_control 1 
cc_key_enable 2
cc_key_lease_period 60
cc_key_protect_bit 1
```
        

Key Violation Trap Logging

A key violation occurs when a port receives a MAD with an incorrect key (e.g., a Class 0xA MAD with an incorrect VS Key in the MAD header). In this case, the port reports the violation to the Subnet Manager (SM), which then sends a TrapRepress and KeyInfo Set (for the relevant key class) to the affected port.

Additionally, the SM logs the key violation event. However, if the same violation is reported consecutively by the same requester, the SM will only log it if the request number falls within the following sequence:

0, 1, 2, 5, 10, 20, 50, 100, 200...