SA Enhanced Trust Model (SAETM)
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
Defines whether to allow GUIDInfoRecord as part of the SAETM set of untrusted requests allowed (see section below)
Defines whether to drop GUIDInfoRecord from non-physical ports (see section below)
Defines the behavior for proxy requests (see section below)
Defines the registration limits in SAETM (see section below)
Set of Untrusted SA Requests Allowed
The following table lists the untrusted requests allowed when SAETM is enabled:
GetTable (only if both destination and source are specified (e,g. only point to point))
Set (for non-SM security traps)
Set/Delete – this request can only be part of this set depending on the values of sa_etm_allow_untrusted_guidinfo_rec and sa_etm_allow_guidinfo_rec_by_vf – see elaboration below.
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.
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:
Maximum number of multicast groups per port/vport that can be registered.
Maximum number of service records per port/vport that can be registered.
Maximum number of event subscriptions (InformInfo) per port/vport that can be registered.
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:
|The value must be set to some random number.|
The lease period used for the M_Key on this subnet in seconds.Recommended value is 60 seconds.
|Must be enabled when M_key is non-zero|
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:
Once enabled, OpenSM forces the values of the following parameters:
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:
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:
Example from syslog: