Appendix – Security Features

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

Set of Untrusted SA Requests Allowed

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

When sa_etm_allow_untrusted_guidinfo_rec is 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.

If sa_etm_allow_untrusted_guidinfo_rec=FALSE, GUIDInfoRecord Set/Delete requests will become part of the SAETM set of untrusted requests allowed. Note that if sa_etm_allow_guidinfo_rec_by_vf=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_requests is 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_srvcs or sa_etm_max_num_event_subs parameters 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_spoofing parameter 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.

M_Key Authentication Enablement

In order to enable M_Key authentication in the InfiniBand fabric, the following parameters must be set in opensm.conf:

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
        

Once enabled, OpenSM forces the values of the following parameters:

            

            
m_key 0x1 (unless configured to non-zero value)
m_key_protection to 2 (unless configured to 3)
m_key_lookup to TRUE
        

Subnet Manager Protection

To protect UFM subnet manager from a hostile SM that may be enabled in the fabric, the SM_Key parameter must be set to some random value in addition to the M_Key protection described before:

            

            
sm_key <random_64b_integer>
        

Once a hostile SM is detected and queried by UFM SM, UFM SM compares the SM_Key provided by the hostile SM to the SM_Key configured in UFM opensm.conf.

As UFM SM_Key is a random 64-bit number, there is a high probability that the SM_Key provided by hostile SM will not match the UFM SM_Key.

As a result UFM SM, ignores hostile SMs and reports them in opensm.log and the syslog.

Example from opensm.log:

            

            
ERR 2F18: Got SM <direct_path_to_the_hostile_SM_node> with sm_key <hostile_SM_KEY> that doesn't match our local sm_key. Ignoring SMInfo.
        

Example from syslog:

            

            
Found remote SM <direct_path_to_the_remote_SM> with non-matching sm_key