2.6.15.10.3 DOIC AVP Blocking

There are potential security issues with DOIC, for instance, an unauthorized third party or unauthorized node might inject an overload report into the network to throttle 100% of the traffic as a form of a Denial-of-Service (DoS) attack. OLRs also include potentially sensitive information such as network topology, current network status. And DOIC overload reports could contain sensitive information about the status of a vendor’s network if they were allowed to transit to a roaming partner.

The DSR enforces a Hop by Hope trust model at the peer level to address this potential security issue. For every peer configured on a DSR it is possible to either allow (pass through) or block (strip the DOIC AVPs) on both requests and answers. The figure below shows a logical picture of a network with both a “first hop” DSR 1, and a “last hop” DSR 2.

Figure 2-29 DOIC Security Setting Example


DOIC Security Setting Example

The following three scenarios are supported:

  • All DOIC AVPs are stripped on all requests and answers sent and received on a connection to a given peer.
  • All OC-Supported-Features AVPs are stripped from requests sent to the peer, and all OC-Supported-Features AVPs and OLR AVPs are stripped from answers received from the peer. The OC-Supported-Features AVP and the OLR AVP are allowed on answers sent to the Peer from the DSR. This mode allows the DOIC Reporting Node function to be done by either DSR or by a downstream peer. But it blocks the DSR or downstream peer from doing the DOIC Reacting Node function.
  • All OC-Supported-Features AVPs and OLR reports are stripped on answers sent to the Peer. The OC-Supported-Features AVP is allowed on requests sent to the peer. This mode allows the DOIC Reacting Node function to be done on the DSR or on a downstream Peer.