1. Diameter Security Application User Guide with UDR
  2. Understanding DSA Functionality and Logic
  3. Understanding DSA Functionality

2.2 Understanding DSA Functionality

DSA allows the operator to screen various diameter messages received from roaming partners for possible vulnerability. It should be deployed at DSR, which is acting as DEA for the operator’s home network so all roaming traffic can be screened for vulnerability by DSA.

DSA screens the incoming diameter message for vulnerability by a set of countermeasures. Each countermeasure has a predefined validation process, which is performed to validate the incoming diameter message for vulnerability. The validation process requires some DSA specific configuration data for performing validation. Apart from DSA specific configuration, some of the countermeasures also require data from an earlier diameter message. Based on this, the countermeasures are broadly divided into the following categories:

  • Stateful countermeasures
  • Stateless countermeasures

Stateful countermeasures require data from an earlier diameter message (apart from DSA configuration data) for checking vulnerability of a given incoming diameter message. UDR is used in this case to save data from a diameter message. The saved data are later fetched by the countermeasure for performing the validation procedure. A list of stateful countermeasures the DSA provides includes:

  • Message Rate Monitoring
  • Time-Distance Check
  • Previous Location Check
  • Source Host Validation HSS
  • Source Host Validation MME
  • Session Integrity Validation Check

Stateless countermeasures do not requires any data from earlier diameter message for checking vulnerability of a given incoming diameter message. The message is screened for vulnerability by using DSA configuration data. So, stateless countermeasures do not require UDR for performing validation procedure. A list of stateless countermeasures DSA provides includes:

  • Application-ID Whitelist Screening
  • Application-ID and Command-Code Consistency Check
  • Origin Realm and Destination Realm Whitelist Screening
  • Origin host and Origin Realm Consistency Check
  • Destination-Realm and Origin-Realm Match Check
  • Visited-PLMN-ID and Origin-Realm Consistency Check
  • Realm and IMSI Consistency Check
  • Subscriber Identity Validation
  • Specific AVP Screening
  • AVP Multiple Instance Check
  • AVP Whitelist Screening
  • Origin Host and Origin Realm Format Check
  • Session Id Validation Check
  • Destination Host and Destination Realm Format Check
Counter measures based on fs19 category are as follows:
  • Category 0:
    • Origin Realm and Destination Realm Whitelist Screening
    • Destination-Realm and Origin-Realm Match Check
    • AVP Multiple Instance Check
    • AVP Whitelist Screening
    • Origin Host Origin Realm Format check
    • Session Id validation check
    • Destination Host Destination Realm Format Check
  • Category 1:
    • Application-ID Whitelist Screening
    • Application-ID and Command-Code Consistency Check
  • Category 2:
    • Subscriber Identity Validation
    • Visited-PLMN-ID and Origin-Realm Consistency Check
    • Specific AVP Screening
    • Origin host and Origin Realm Consistency Check
    • Realm and IMSI Consistency Check
  • Category 3:
    • Message Rate Monitoring
    • Time-Distance Check
    • Previous Location Check
    • Source Host Validation HSS
    • Source Host Validation MME
    • Session Integrity validation check