
		SA security features (Version: OpenSM 5.4.0)

===============================================================================
 Table of contents
===============================================================================

1. SA Enhanced Trust Model - SAETM
	1.1. Set untrusted SA Requests Allowed
	1.2. Proxy SA Requests
	1.3. Registration Limits
	1.4. SAETM Logging
2. SGID Spoofing


===============================================================================
 1. 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 1.1 below).

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

Additional SAETM configuration parameters:
1. sa_etm_allow_untrusted_guidinfo_rec:
	Defines whether to allow GUIDInfoRecord as part of the SAETM set of
	untrusted requests allowed (see 1.1).
2. sa_etm_allow_guidinfo_rec_by_vf:
	Defines whether to drop GUIDInfoRecord from non-physical ports (see 1.1).
3. sa_etm_allow_untrusted_proxy_requests:
	Defines the behavior for proxy requests (see 1.2).
4. sa_etm_max_num_mcgs/sa_etm_max_num_srvcs/sa_etm_max_num_event_subs:
	Defines the registration limits in SAETM (see 1.3).


===============================================================================
 1.1. Set of Untrusted SA Requests Allowed
===============================================================================

List of untrusted requests allowed when SAETM is enabled:
1. MCMemberRecord - Get/Set/Delete
2. PathRecord     - Get
3. PathRecord     - GetTable, only if both destination and source are specified
		    (e,g. only point to point)
4. ServiceRecord  - Get/Set/Delete
5. InformInfo     - Set, for non-SM security traps
6. ClassPortInfo  - Get
7. GUIDInfoRecord - 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.

In case 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.


===============================================================================
 1.2. 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.


===============================================================================
 1.3. 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 parameters registrations can be unlimited.
When the parameters 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:

1. sa_etm_max_num_mcgs:
   Max number of multicast groups per port/vport that can be registered.

2. sa_etm_max_num_srvcs:
   Max number of service records per port/vport that can be registered.

3. sa_etm_max_num_event_subs:
   Max number of event subscriptions (InformInfo) per port/vport
   that can be registered.

Registration limits are valid only when SAETM is enabled.


===============================================================================
 1.4. 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).


===============================================================================
 2. SGID Spoofing
===============================================================================

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.

