Aller au contenu principal

14. Security Considerations

The potential security concerns when using DLEP are as follows:

  1. An attacker might pretend to be a DLEP participant, either at DLEP session initialization or by injection of DLEP Messages once a session has been established.

  2. DLEP Data Items could be altered by an attacker, causing the receiving implementation to inappropriately alter its information base concerning network status.

  3. An attacker could join an unsecured radio network and inject over-the-air signals that maliciously influence the information reported by a DLEP modem, causing a router to forward traffic to an inappropriate destination.

The implications of attacks on DLEP peers are directly proportional to the extent to which DLEP data is used within the control plane. While the use of DLEP data in other control-plane components is out of scope for this document, as an example, if DLEP statistics are incorporated into route cost calculations, adversaries masquerading as a DLEP peer and injecting malicious data via DLEP could cause suboptimal route selection, adversely impacting network performance. Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput.

For these reasons, security of the DLEP transport must be considered at both the transport layer and Layer 2.

At the transport layer, when TLS is in use, each peer SHOULD check the validity of credentials presented by the other peer during TLS session establishment. Implementations following the "dedicated deployments" model attempting to use TLS MAY (1) need to consider the use of pre-shared keys for credentials, (2) provide specialized techniques for peer identity validation, and (3) refer to [RFC5487] for additional details. Implementations following the "networked deployment" model described in "Implementation Scenarios" (Section 4) SHOULD refer to [RFC7525] for additional details.

At Layer 2, since DLEP is restricted to operation over a single (possibly logical) hop, implementations SHOULD also secure the Layer 2 link. Examples of technologies that can be deployed to secure the Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X].

By examining the Secured Medium flag in the Peer Type Data Item (Section 13.4), a router can decide if it is able to trust the information supplied via a DLEP modem. If this is not the case, then the router SHOULD consider restricting the size of attached subnets, announced in IPv4 Attached Subnet Data Items (Section 13.10) and/or IPv6 Attached Subnet Data Items (Section 13.11), that are considered for route selection.

To avoid potential denial-of-service attacks, it is RECOMMENDED that implementations using the Peer Discovery mechanism (1) maintain an information base of hosts that persistently fail Session Initialization, even though those hosts have provided an acceptable Peer Discovery Signal and (2) ignore any subsequent Peer Discovery Signals from such hosts.

This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed.