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.
15. IANA Considerations
15.1. Registrations
IANA has created a new protocol registry for the Dynamic Link
Exchange Protocol (DLEP). The remainder of this section details the
new DLEP-specific registries.
15.2. Signal Type Registrations
IANA has created a new DLEP registry, named "Signal Type Values".
15.7. DLEP IPv4 Connection Point Flags
IANA has created a new DLEP registry, named "IPv4 Connection Point
Flags".
The following table provides initial registry values and the
policies, as defined by [RFC5226], that apply to the registry:
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Use TLS [RFC5246] indicator |
+------------+--------------------------------------+
15.8. DLEP IPv6 Connection Point Flags
IANA has created a new DLEP registry, named "IPv6 Connection Point
Flags".
The following table provides initial registry values and the
policies, as defined by [RFC5226], that apply to the registry:
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Use TLS [RFC5246] indicator |
+------------+--------------------------------------+
15.9. DLEP Peer Type Flags
IANA has created a new DLEP registry, named "Peer Type Flags".
The following table provides initial registry values and the
policies, as defined by [RFC5226], that apply to the registry:
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Secured Medium indicator |
+------------+--------------------------------------+
15.10. DLEP IPv4 Address Flags
IANA has created a new DLEP registry, named "IPv4 Address Flags".
The following table provides initial registry values and the
policies, as defined by [RFC5226], that apply to the registry:
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
15.11. DLEP IPv6 Address Flags
IANA has created a new DLEP registry, named "IPv6 Address Flags".
The following table provides initial registry values and the
policies, as defined by [RFC5226], that apply to the registry:
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
15.12. DLEP IPv4 Attached Subnet Flags
IANA has created a new DLEP registry, named "IPv4 Attached Subnet
Flags".
The following table provides initial registry values and the
policies, as defined by [RFC5226], that apply to the registry:
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
C.3. Link Characteristics Request
Router Modem Message Description
========================================================================
Destination has already been
~ ~ ~ ~ ~ ~ ~ announced by either peer.
| Router requires different
| characteristics for the
| destination and sends Link
|--Link Characteristics Request->| Characteristics Request Message.
|
| Modem attempts to adjust link
| properties to meet the received
| request and sends a Link
| Characteristics Response
|<---Link Characteristics Resp.--| Message with the new values.
Acknowledgments
We would like to acknowledge and thank the members of the DLEP design
team, who have provided invaluable insight. The members of the
design team are Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning
Rogge.
We would also like to acknowledge the influence and contributions of
Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang,
Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Pritchard.
Authors' Addresses
Stan Ratliff
VT iDirect
13861 Sunrise Valley Drive, Suite 300
Herndon, VA 20171
United States of America
Email: sratliff@idirect.net
Shawn Jury
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sjury@cisco.com
Darryl Satterwhite
Broadcom
Email: dsatterw@broadcom.com
Rick Taylor
Airbus Defence & Space
Quadrant House
Celtic Springs
Coedkernew
Newport NP10 8FZ
United Kingdom
Email: rick.taylor@airbus.com
Bo Berry
