RFC 8175
Dynamic Link Exchange Protocol (DLEP)
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".
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry: +--------------+--------------------------------------+ | Type Code | Description/Policy | +--------------+--------------------------------------+ | 0 | Reserved | | 1 | Peer Discovery Signal | | 2 | Peer Offer Signal | | 3-65519 | Unassigned / Specification Required | | 65520-65534 | Reserved for Private Use | | 65535 | Reserved | +--------------+--------------------------------------+15.3. Message Type Registrations
IANA has created a new DLEP registry, named "Message Type Values". The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry: +--------------+------------------------------------------+ | Type Code | Description/Policy | +--------------+------------------------------------------+ | 0 | Reserved | | | | | 1 | Session Initialization Message | | | | | 2 | Session Initialization Response Message | | | | | 3 | Session Update Message | | | | | 4 | Session Update Response Message | | | | | 5 | Session Termination Message | | | | | 6 | Session Termination Response Message | | | | | 7 | Destination Up Message | | | | | 8 | Destination Up Response Message | | | | | 9 | Destination Announce Message | | | | | 10 | Destination Announce Response Message | | | | | 11 | Destination Down Message | | | |
| 12 | Destination Down Response Message |
| | |
| 13 | Destination Update Message |
| | |
| 14 | Link Characteristics Request Message |
| | |
| 15 | Link Characteristics Response Message |
| | |
| 16 | Heartbeat Message |
| | |
| 17-65519 | Unassigned / Specification Required |
| | |
| 65520-65534 | Reserved for Private Use |
| | |
| 65535 | Reserved |
+--------------+------------------------------------------+
15.4. DLEP Data Item Registrations
IANA has created a new DLEP registry, named "Data Item Type Values".
The following table provides initial registry values and the
policies, as defined by [RFC5226], that apply to the registry:
+-------------------+------------------------------------------+
| Type Code | Description/Policy |
+-------------------+------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Status |
| | |
| 2 | IPv4 Connection Point |
| | |
| 3 | IPv6 Connection Point |
| | |
| 4 | Peer Type |
| | |
| 5 | Heartbeat Interval |
| | |
| 6 | Extensions Supported |
| | |
| 7 | MAC Address |
| | |
| 8 | IPv4 Address |
| | |
| 9 | IPv6 Address |
| | |
| 10 | IPv4 Attached Subnet |
| | |
| 11 | IPv6 Attached Subnet |
| | |
| 12 | Maximum Data Rate (Receive) (MDRR) |
| | |
| 13 | Maximum Data Rate (Transmit) (MDRT) |
| | |
| 14 | Current Data Rate (Receive) (CDRR) |
| | |
| 15 | Current Data Rate (Transmit) (CDRT) |
| | |
| 16 | Latency |
| | |
| 17 | Resources (RES) |
| | |
| 18 | Relative Link Quality (Receive) (RLQR) |
| | |
| 19 | Relative Link Quality (Transmit) (RLQT) |
| | |
| 20 | Maximum Transmission Unit (MTU) |
| | |
| 21-65407 | Unassigned / Specification Required |
| | |
| 65408-65534 | Reserved for Private Use |
| | |
| 65535 | Reserved |
+-------------------+------------------------------------------+
15.5. DLEP Status Code Registrations
IANA has created a new DLEP registry, named "Status Code Values".
The following table provides initial registry values and the
policies, as defined by [RFC5226], that apply to the registry:
+--------------+---------------+------------------------------------+
| Status Code | Failure Mode | Description/Policy |
+--------------+---------------+------------------------------------+
| 0 | Continue | Success |
| | | |
| 1 | Continue | Not Interested |
| | | |
| 2 | Continue | Request Denied |
| | | |
| 3 | Continue | Inconsistent Data |
| | | |
| 4-111 | Continue | Unassigned / Specification |
| | | Required |
| | | | | 112-127 | Continue | Private Use | | | | | | 128 | Terminate | Unknown Message | | | | | | 129 | Terminate | Unexpected Message | | | | | | 130 | Terminate | Invalid Data | | | | | | 131 | Terminate | Invalid Destination | | | | | | 132 | Terminate | Timed Out | | | | | | 133-239 | Terminate | Unassigned / Specification | | | | Required | | | | | | 240-254 | Terminate | Reserved for Private Use | | | | | | 255 | Terminate | Shutting Down | +--------------+---------------+------------------------------------+15.6. DLEP Extension Registrations
IANA has created a new DLEP registry, named "Extension Type Values". The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry: +--------------+--------------------------------------+ | Code | Description/Policy | +--------------+--------------------------------------+ | 0 | Reserved | | 1-65519 | Unassigned / Specification Required | | 65520-65534 | Reserved for Private Use | | 65535 | Reserved | +--------------+--------------------------------------+ Table 3: DLEP Extension Types
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 | +------------+--------------------------------------+
15.13. DLEP IPv6 Attached Subnet Flags
IANA has created a new DLEP registry, named "IPv6 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 | +------------+--------------------------------------+15.14. DLEP Well-Known Port
IANA has assigned the value 854 in the "Service Name and Transport Protocol Port Number Registry" found at <http://www.iana.org/assignments/service-names-port-numbers/> for use by "DLEP", as defined in this document. This assignment is valid for TCP and UDP.15.15. DLEP IPv4 Link-Local Multicast Address
IANA has assigned the IPv4 multicast address 224.0.0.117 in the registry found at <http://www.iana.org/assignments/multicast-addresses> for use as "DLEP Discovery".15.16. DLEP IPv6 Link-Local Multicast Address
IANA has assigned the IPv6 multicast address FF02:0:0:0:0:0:1:7 in the registry found at <http://www.iana.org/assignments/ipv6-multicast-addresses> for use as "DLEP Discovery".
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.16.2. Informative References
[IEEE-802.1AE] "IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Security", DOI 10.1109/IEEESTD.2006.245590, <http://ieeexplore.ieee.org/document/1678345/>. [IEEE-802.1X] "IEEE Standards for Local and metropolitan area networks-- Port-Based Network Access Control", DOI 10.1109/IEEESTD.2010.5409813, <http://ieeexplore.ieee.org/document/5409813/>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>. [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
Appendix A. Discovery Signal Flows
Router Modem Signal Description ======================================================================== | Router initiates discovery, | starts a timer, sends Peer |-------Peer Discovery---->X Discovery Signal. ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires without receiving Peer Offer. | Router sends another Peer |-------Peer Discovery---------->| Discovery Signal. | | Modem receives Peer Discovery | Signal. | | Modem sends Peer Offer with |<--------Peer Offer-------------| Connection Point information. : : Router MAY cancel discovery timer : and stop sending Peer Discovery : Signals.Appendix B. Peer-Level Message Flows
B.1. Session Initialization
Router Modem Message Description ======================================================================== | Router connects to discovered or | preconfigured Modem Connection |--TCP connection established---> Point. | | Router sends Session |----Session Initialization----->| Initialization Message. | | Modem receives Session | Initialization Message. | | Modem sends Session Initialization |<--Session Initialization Resp.-| Response with 'Success' Status | | Data Item. | | |<<============================>>| Session established. : : Heartbeats begin.
B.2. Session Initialization - Refused
Router Modem Message Description ======================================================================== | Router connects to discovered or | preconfigured Modem Connection |--TCP connection established---> Point. | | Router sends Session |-----Session Initialization---->| Initialization Message. | | Modem receives Session | Initialization Message and | will not support the advertised | extensions. | | Modem sends Session Initialization | Response with 'Request Denied' |<-Session Initialization Resp.--| Status Data Item. | | | Router receives negative Session | Initialization Response, closes ||---------TCP close------------|| TCP connection.B.3. Router Changes IP Addresses
Router Modem Message Description ======================================================================== | Router sends Session Update |-------Session Update---------->| Message to announce change of | IP address. | | Modem receives Session Update | Message and updates internal | state. | |<----Session Update Response----| Modem sends Session Update | Response.
B.4. Modem Changes Session-Wide Metrics
Router Modem Message Description ======================================================================== | Modem sends Session Update Message | to announce change of session-wide |<--------Session Update---------| metrics. | | Router receives Session Update | Message and updates internal | state. | |----Session Update Response---->| Router sends Session Update | Response.B.5. Router Terminates Session
Router Modem Message Description ======================================================================== | Router sends Session Termination |------Session Termination------>| Message with Status Data Item. | | |-------TCP shutdown (send)---> | Router stops sending Messages. | | Modem receives Session | Termination, stops counting | received heartbeats, and stops | sending heartbeats. | | Modem sends Session Termination |<---Session Termination Resp.---| Response with Status 'Success'. | | Modem stops sending Messages. | ||---------TCP close------------|| Session terminated.
B.6. Modem Terminates Session
Router Modem Message Description ======================================================================== | Modem sends Session Termination |<----Session Termination--------| Message with Status Data Item. | | Modem stops sending Messages. | | Router receives Session | Termination, stops counting | received heartbeats, and stops | sending heartbeats. | | Router sends Session Termination |---Session Termination Resp.--->| Response with Status 'Success'. | | Router stops sending Messages. | ||---------TCP close------------|| Session terminated.
B.7. Session Heartbeats
Router Modem Message Description ======================================================================== |----------Heartbeat------------>| Router sends Heartbeat Message. | | Modem resets heartbeats missed | counter. ~ ~ ~ ~ ~ ~ ~ |---------[Any Message]--------->| When the Modem receives any | Message from the Router. | | Modem resets heartbeats missed | counter. ~ ~ ~ ~ ~ ~ ~ |<---------Heartbeat-------------| Modem sends Heartbeat Message. | | Router resets heartbeats missed | counter. ~ ~ ~ ~ ~ ~ ~ |<--------[Any Message]----------| When the Router receives any | Message from the Modem. | | Modem resets heartbeats missed | counter.
B.8. Router Detects a Heartbeat Timeout
Router Modem Message Description ======================================================================== X<----------------------| Router misses a heartbeat. | X<----------------------| Router misses too many | heartbeats. | | |------Session Termination------>| Router sends Session Termination | Message with 'Timeout' Status | Data Item. : : Termination proceeds...B.9. Modem Detects a Heartbeat Timeout
Router Modem Message Description ======================================================================== |---------------------->X Modem misses a heartbeat. |---------------------->X | Modem misses too many | heartbeats. | | |<-----Session Termination-------| Modem sends Session Termination | Message with 'Timeout' Status | Data Item. : : Termination proceeds...
Appendix C. Destination-Specific Message Flows
C.1. Common Destination Notification
Router Modem Message Description ======================================================================== | Modem detects a new logical | destination is reachable and |<-------Destination Up----------| sends Destination Up Message. | |------Destination Up Resp.----->| Router sends Destination Up | Response. ~ ~ ~ ~ ~ ~ ~ | Modem detects change in logical | destination metrics and sends |<-------Destination Update------| Destination Update Message. ~ ~ ~ ~ ~ ~ ~ | Modem detects change in logical | destination metrics and sends |<-------Destination Update------| Destination Update Message. ~ ~ ~ ~ ~ ~ ~ | Modem detects logical destination | is no longer reachable and sends |<-------Destination Down--------| Destination Down Message. | | Router receives Destination Down, | updates internal state, and sends |------Destination Down Resp.--->| Destination Down Response Message.
C.2. Multicast Destination Notification
Router Modem Message Description ======================================================================== | Router detects a new multicast | destination is in use and sends |-----Destination Announce------>| Destination Announce Message. | | Modem updates internal state to | monitor multicast destination and |<-----Dest. Announce Resp.------| sends Destination Announce Response. ~ ~ ~ ~ ~ ~ ~ | Modem detects change in multicast | destination metrics and sends |<-------Destination Update------| Destination Update Message. ~ ~ ~ ~ ~ ~ ~ | Modem detects change in multicast | destination metrics and sends |<-------Destination Update------| Destination Update Message. ~ ~ ~ ~ ~ ~ ~ | Router detects multicast | destination is no longer in use |--------Destination Down------->| and sends Destination Down | Message. | | Modem receives Destination Down, | updates internal state, and sends |<-----Destination Down Resp.----| Destination Down Response Message.
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