< draft-ietf-manet-dlep-27.txt   draft-ietf-manet-dlep-28.txt >
Mobile Ad hoc Networks Working Group S. Ratliff Mobile Ad hoc Networks Working Group S. Ratliff
Internet-Draft VT iDirect Internet-Draft VT iDirect
Intended status: Standards Track S. Jury Intended status: Standards Track S. Jury
Expires: July 28, 2017 Cisco Systems Expires: September 4, 2017 Cisco Systems
D. Satterwhite D. Satterwhite
Broadcom Broadcom
R. Taylor R. Taylor
Airbus Defence & Space Airbus Defence & Space
B. Berry B. Berry
January 24, 2017 March 3, 2017
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-27 draft-ietf-manet-dlep-28
Abstract Abstract
When routing devices rely on modems to effect communications over When routing devices rely on modems to effect communications over
wireless links, they need timely and accurate knowledge of the wireless links, they need timely and accurate knowledge of the
characteristics of the link (speed, state, etc.) in order to make characteristics of the link (speed, state, etc.) in order to make
routing decisions. In mobile or other environments where these routing decisions. In mobile or other environments where these
characteristics change frequently, manual configurations or the characteristics change frequently, manual configurations or the
inference of state through routing or transport protocols does not inference of state through routing or transport protocols does not
allow the router to make the best decisions. DLEP describes a new allow the router to make the best decisions. DLEP describes a new
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 28, 2017. This Internet-Draft will expire on September 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
12.13. Destination Announce Message . . . . . . . . . . . . . . 30 12.13. Destination Announce Message . . . . . . . . . . . . . . 30
12.14. Destination Announce Response Message . . . . . . . . . 30 12.14. Destination Announce Response Message . . . . . . . . . 30
12.15. Destination Down Message . . . . . . . . . . . . . . . . 32 12.15. Destination Down Message . . . . . . . . . . . . . . . . 32
12.16. Destination Down Response Message . . . . . . . . . . . 32 12.16. Destination Down Response Message . . . . . . . . . . . 32
12.17. Destination Update Message . . . . . . . . . . . . . . . 32 12.17. Destination Update Message . . . . . . . . . . . . . . . 32
12.18. Link Characteristics Request Message . . . . . . . . . . 34 12.18. Link Characteristics Request Message . . . . . . . . . . 34
12.19. Link Characteristics Response Message . . . . . . . . . 34 12.19. Link Characteristics Response Message . . . . . . . . . 34
12.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 35 12.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 35
13. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 36 13. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 36
13.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 40 13.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 39
13.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 41 13.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 40
13.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 42 13.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 41
13.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 43 13.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 42
13.6. Extensions Supported . . . . . . . . . . . . . . . . . . 44 13.6. Extensions Supported . . . . . . . . . . . . . . . . . . 43
13.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 44 13.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 44
13.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 45 13.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 44
13.8.1. IPv4 Address Processing . . . . . . . . . . . . . . 46 13.8.1. IPv4 Address Processing . . . . . . . . . . . . . . 45
13.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 47 13.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 46
13.9.1. IPv6 Address Processing . . . . . . . . . . . . . . 48 13.9.1. IPv6 Address Processing . . . . . . . . . . . . . . 47
13.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 49 13.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 48
13.10.1. IPv4 Attached Subnet Processing . . . . . . . . . . 50 13.10.1. IPv4 Attached Subnet Processing . . . . . . . . . . 49
13.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 51 13.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 50
13.11.1. IPv6 Attached Subnet Processing . . . . . . . . . . 52 13.11.1. IPv6 Attached Subnet Processing . . . . . . . . . . 51
13.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 53 13.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 52
13.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 53 13.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 53
13.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 54 13.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 54
13.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 55 13.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 54
13.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 55 13.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 55
13.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 56 13.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 56
13.18. Relative Link Quality (Receive) . . . . . . . . . . . . 57 13.18. Relative Link Quality (Receive) . . . . . . . . . . . . 57
13.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 58 13.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 57
13.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 59 13.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 58
14. Security Considerations . . . . . . . . . . . . . . . . . . . 59 14. Security Considerations . . . . . . . . . . . . . . . . . . . 59
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
15.1. Registrations . . . . . . . . . . . . . . . . . . . . . 61 15.1. Registrations . . . . . . . . . . . . . . . . . . . . . 60
15.2. Signal Type Registration . . . . . . . . . . . . . . . . 61 15.2. Signal Type Registration . . . . . . . . . . . . . . . . 60
15.3. Message Type Registration . . . . . . . . . . . . . . . 61 15.3. Message Type Registration . . . . . . . . . . . . . . . 61
15.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 62 15.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 61
15.5. DLEP Status Code Registrations . . . . . . . . . . . . . 63 15.5. DLEP Status Code Registrations . . . . . . . . . . . . . 62
15.6. DLEP Extensions Registrations . . . . . . . . . . . . . 64 15.6. DLEP Extensions Registrations . . . . . . . . . . . . . 63
15.7. DLEP IPv4 Connection Point Flags . . . . . . . . . . . . 64 15.7. DLEP IPv4 Connection Point Flags . . . . . . . . . . . . 63
15.8. DLEP IPv6 Connection Point Flags . . . . . . . . . . . . 65 15.8. DLEP IPv6 Connection Point Flags . . . . . . . . . . . . 64
15.9. DLEP Peer Type Flag . . . . . . . . . . . . . . . . . . 65 15.9. DLEP Peer Type Flag . . . . . . . . . . . . . . . . . . 64
15.10. DLEP IPv4 Address Flag . . . . . . . . . . . . . . . . . 65 15.10. DLEP IPv4 Address Flag . . . . . . . . . . . . . . . . . 64
15.11. DLEP IPv6 Address Flag . . . . . . . . . . . . . . . . . 66 15.11. DLEP IPv6 Address Flag . . . . . . . . . . . . . . . . . 65
15.12. DLEP IPv4 Attached Subnet Flag . . . . . . . . . . . . . 66 15.12. DLEP IPv4 Attached Subnet Flag . . . . . . . . . . . . . 65
15.13. DLEP IPv6 Attached Subnet Flag . . . . . . . . . . . . . 66 15.13. DLEP IPv6 Attached Subnet Flag . . . . . . . . . . . . . 65
15.14. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 67 15.14. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 66
15.15. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 67 15.15. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 66
15.16. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 67 15.16. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 66
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
17.1. Normative References . . . . . . . . . . . . . . . . . . 67 17.1. Normative References . . . . . . . . . . . . . . . . . . 66
17.2. Informative References . . . . . . . . . . . . . . . . . 68 17.2. Informative References . . . . . . . . . . . . . . . . . 67
Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 69 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 68
Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 69 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 68
B.1. Session Initialization . . . . . . . . . . . . . . . . . 69 B.1. Session Initialization . . . . . . . . . . . . . . . . . 68
B.2. Session Initialization - Refused . . . . . . . . . . . . 70 B.2. Session Initialization - Refused . . . . . . . . . . . . 69
B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 70 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 69
B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 70 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 69
B.5. Router Terminates Session . . . . . . . . . . . . . . . . 71 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 70
B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 71 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 70
B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 72 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 71
B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 73 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 72
B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 74 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 73
Appendix C. Destination Specific Message Flows . . . . . . . . . 74 Appendix C. Destination Specific Message Flows . . . . . . . . . 73
C.1. Common Destination Notification . . . . . . . . . . . . . 74 C.1. Common Destination Notification . . . . . . . . . . . . . 73
C.2. Multicast Destination Notification . . . . . . . . . . . 75 C.2. Multicast Destination Notification . . . . . . . . . . . 74
C.3. Link Characteristics Request . . . . . . . . . . . . . . 76 C.3. Link Characteristics Request . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
There exist today a collection of modem devices that control links of There exist today a collection of modem devices that control links of
variable datarate and quality. Examples of these types of links variable datarate and quality. Examples of these types of links
include line-of-sight (LOS) terrestrial radios, satellite terminals, include line-of-sight (LOS) terrestrial radios, satellite terminals,
and broadband modems. Fluctuations in speed and quality of these and broadband modems. Fluctuations in speed and quality of these
links can occur due to configuration, or on a moment-to-moment basis, links can occur due to configuration, or on a moment-to-moment basis,
due to physical phenomena like multipath interference, obstructions, due to physical phenomena like multipath interference, obstructions,
rain fade, etc. It is also quite possible that link quality and rain fade, etc. It is also quite possible that link quality and
skipping to change at page 10, line 24 skipping to change at page 10, line 24
ancillary devices (e.g., a laptop) are also plugged into the switch. ancillary devices (e.g., a laptop) are also plugged into the switch.
But in either event, the resulting network segment is constrained to But in either event, the resulting network segment is constrained to
a small number of devices, and is not generally accessible from a small number of devices, and is not generally accessible from
anywhere else in the network. anywhere else in the network.
The other type of deployment envisioned can be viewed as a "networked The other type of deployment envisioned can be viewed as a "networked
deployment". In this type of scenario, the DLEP router and modem(s) deployment". In this type of scenario, the DLEP router and modem(s)
are placed on a segment that is accessible from other points in the are placed on a segment that is accessible from other points in the
network. In this scenario, not only are the DLEP router and modem(s) network. In this scenario, not only are the DLEP router and modem(s)
accessible from other points in the network; the router and a given accessible from other points in the network; the router and a given
modem could be multiple physical hops away from each other. As modem could be multiple physical hops away from each other. This
mentioned, this scenario necessitates the use of Layer 2 tunneling scenario necessitates the use of Layer 2 tunneling technology to
technology to enforce the single-hop requirement of DLEP. enforce the single-hop requirement of DLEP.
5. Assumptions 5. Assumptions
DLEP assumes that a signaling protocol exists between modems DLEP assumes that a signaling protocol exists between modems
participating in a network. The specification does not define the participating in a network. The specification does not define the
character or behavior of this over-the-air signaling, but does expect character or behavior of this over-the-air signaling, but does expect
some information to be carried (or derived) by the signaling, such as some information to be carried (or derived) by the signaling, such as
the arrival and departure of modems from this network, and the the arrival and departure of modems from this network, and the
variation of the link characteristics between modems. This variation of the link characteristics between modems. This
information is then assumed to be used by the modem to implement the information is then assumed to be used by the modem to implement the
skipping to change at page 13, line 10 skipping to change at page 13, line 10
second; it SHOULD be a configurable parameter. Note that this second; it SHOULD be a configurable parameter. Note that this
operation (sending Peer Discovery and waiting for Peer Offer) is operation (sending Peer Discovery and waiting for Peer Offer) is
outside the DLEP Transaction Model (Section 8), as the Transaction outside the DLEP Transaction Model (Section 8), as the Transaction
Model only describes Messages on a TCP session. Model only describes Messages on a TCP session.
Routers receiving a Peer Offer Signal MUST use one of the modem Routers receiving a Peer Offer Signal MUST use one of the modem
address/port combinations from the Peer Offer Signal to establish a address/port combinations from the Peer Offer Signal to establish a
TCP connection to the modem, even if a priori configuration exists. TCP connection to the modem, even if a priori configuration exists.
If multiple connection point Data Items exist in the received Peer If multiple connection point Data Items exist in the received Peer
Offer Signal, routers SHOULD prioritize IPv6 connection points over Offer Signal, routers SHOULD prioritize IPv6 connection points over
IPv4 connection points. Routers supporting TLS [RFC5246] MUST IPv4 connection points. If multiple connection points exist with the
prioritize connection points using TLS over those that do not. If same transport (e.g. IPv6 or IPv4), implementations MAY use their
multiple connection points exist with the same transport (e.g. IPv6 own heuristics to determine the order in which they are tried. If a
or IPv4), implementations MAY use their own heuristics to determine TCP connection cannot be achieved using any of the address/port
the order in which they are tried. If a TCP connection cannot be combinations and the Discovery mechanism is in use, then the router
achieved using any of the address/port combinations and the Discovery SHOULD resume issuing Peer Discovery Signals. If no Connection Point
mechanism is in use, then the router SHOULD resume issuing Peer Data Items are included in the Peer Offer Signal, the router MUST use
Discovery Signals. If no Connection Point Data Items are included in the source address of the UDP packet containing the Peer Offer Signal
the Peer Offer Signal, the router MUST use the source address of the as the IP address, and the DLEP well-known port number.
UDP packet containing the Peer Offer Signal as the IP address, and
the DLEP well-known port number.
In the Peer Discovery state, the modem implementation MUST listen for In the Peer Discovery state, the modem implementation MUST listen for
incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or
IPv4 link-local multicast address and port. On receipt of a valid IPv4 link-local multicast address and port. On receipt of a valid
Peer Discovery Signal, it MUST reply with a Peer Offer Signal. Peer Discovery Signal, it MUST reply with a Peer Offer Signal.
Modems MUST be prepared to accept a TCP connection from a router that Modems MUST be prepared to accept a TCP connection from a router that
is not using the Discovery mechanism, i.e. a connection attempt that is not using the Discovery mechanism, i.e. a connection attempt that
occurs without a preceding Peer Discovery Signal. occurs without a preceding Peer Discovery Signal.
Upon establishment of a TCP connection, both modem and router enter Implementations of DLEP SHOULD implement, and use, TLS [RFC5246] to
the Session Initialization state. It is up to the router protect the TCP session. The "dedicated deployments" discussed in
implementation if Peer Discovery Signals continue to be sent after Implementation Scenarios (Section 4) MAY consider use of DLEP without
the device has transitioned to the Session Initialization state. TLS. For all "networked deployments" (again, discussed in
Modem implementations MUST silently ignore Peer Discovery Signals Implementation Scenarios), implementation and use of TLS is STRONGLY
from a router with which it already has a TCP connection. RECOMMENDED. If TLS is to be used then the TLS session MUST be
established before any Messages are passed between peers. Routers
supporting TLS MUST prioritize connection points using TLS over those
that do not.
Upon establishment of a TCP connection, and TLS session if TLS is in
use, both modem and router enter the Session Initialization state.
It is up to the router implementation if Peer Discovery Signals
continue to be sent after the device has transitioned to the Session
Initialization state. Modem implementations MUST silently ignore
Peer Discovery Signals from a router with which it already has a TCP
connection.
7.2. Session Initialization State 7.2. Session Initialization State
On entering the Session Initialization state, the router MUST send a On entering the Session Initialization state, the router MUST send a
Session Initialization Message (Section 12.5) to the modem. The Session Initialization Message (Section 12.5) to the modem. The
router MUST then wait for receipt of a Session Initialization router MUST then wait for receipt of a Session Initialization
Response Message (Section 12.6) from the modem. Receipt of the Response Message (Section 12.6) from the modem. Receipt of the
Session Initialization Response Message containing a Status Data Item Session Initialization Response Message containing a Status Data Item
(Section 13.1) with status code set to 0 'Success', see Table 2, (Section 13.1) with status code set to 0 'Success', see Table 2,
indicates that the modem has received and processed the Session indicates that the modem has received and processed the Session
skipping to change at page 36, line 17 skipping to change at page 36, line 17
(Section 15.3)). (Section 15.3)).
There are no valid Data Items for the Heartbeat Message. There are no valid Data Items for the Heartbeat Message.
The Message is used by DLEP participants to detect when a DLEP The Message is used by DLEP participants to detect when a DLEP
session peer (either the modem or the router) is no longer session peer (either the modem or the router) is no longer
communicating, see Section 7.3.1. communicating, see Section 7.3.1.
13. DLEP Data Items 13. DLEP Data Items
Following is the list of core Data Items that MUST be recognized by a
DLEP compliant implementation. As mentioned before, not all Data
Items need be used during a session, but an implementation MUST
correctly process these Data Items when correctly associated with a
Signal or Message.
The core DLEP Data Items are: The core DLEP Data Items are:
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Type Code | Description | | Type Code | Description |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| 0 | Reserved | | 0 | Reserved |
| 1 | Status (Section 13.1) | | 1 | Status (Section 13.1) |
| 2 | IPv4 Connection Point (Section 13.2) | | 2 | IPv4 Connection Point (Section 13.2) |
| 3 | IPv6 Connection Point (Section 13.3) | | 3 | IPv6 Connection Point (Section 13.3) |
| 4 | Peer Type (Section 13.4) | | 4 | Peer Type (Section 13.4) |
skipping to change at page 60, line 4 skipping to change at page 59, line 27
receiving implementation to inappropriately alter its information receiving implementation to inappropriately alter its information
base concerning network status. base concerning network status.
3. An attacker could join an unsecured radio network and inject 3. An attacker could join an unsecured radio network and inject
over-the-air signals that maliciously influence the information over-the-air signals that maliciously influence the information
reported by a DLEP modem, causing a router to forward traffic to reported by a DLEP modem, causing a router to forward traffic to
an inappropriate destination. an inappropriate destination.
The implications of attacks on DLEP peers are directly proportional The implications of attacks on DLEP peers are directly proportional
to the extent to which DLEP data is used within the control plane. 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 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 of scope for this document, as an example, if DLEP statistics are
incorporated into route cost calculations, adversaries masquerading incorporated into route cost calculations, adversaries masquerading
as a DLEP peer, and injecting malicious data via DLEP, could cause as a DLEP peer, and injecting malicious data via DLEP, could cause
suboptimal route selection, adversely impacting network performance. suboptimal route selection, adversely impacting network performance.
Similar issues can arise if DLEP data is used as an input to policing Similar issues can arise if DLEP data is used as an input to policing
algorithms - injection of malicious data via DLEP can cause those algorithms - injection of malicious data via DLEP can cause those
policing algorithms to make incorrect decisions, degrading network policing algorithms to make incorrect decisions, degrading network
throughput. throughput.
For these reasons, security of the DLEP transport must be considered For these reasons, security of the DLEP transport must be considered
at both the transport layer, and at Layer 2. at both the transport layer, and at Layer 2.
At the transport layer, implementations of DLEP SHOULD implement, and At the transport layer, when TLS is in use, each peer SHOULD check
use, TLS [RFC5246] to protect the TCP session. The "dedicated the validity of credentials presented by the other peer during TLS
deployments" discussed in Implementation Scenarios (Section 4) MAY session establishment. Implementations following the "dedicated
consider use of DLEP without TLS. For all "networked deployments" deployments" model attempting use of TLS MAY need to consider use of
(again, discussed in Implementation Scenarios), implementation and pre-shared keys for credentials, and provide specialized techniques
use of TLS is STRONGLY RECOMMENDED. for peer identity validation. Implementations following the
When TLS is in use, each peer SHOULD check the validity of
credentials presented by the other peer during TLS session
establishment. Mobile implementations MAY need to consider use of
pre-shared keys for credentials; implementations following the
"networked deployment" model described in Implementation Scenarios "networked deployment" model described in Implementation Scenarios
SHOULD refer to [RFC7525] for additional details. SHOULD refer to [RFC7525] for additional details.
At layer 2 - since DLEP is restricted to operation over a single At layer 2 - since DLEP is restricted to operation over a single
(possibly logical) hop, implementations SHOULD also secure the Layer (possibly logical) hop, implementations SHOULD also secure the Layer
2 link. Examples of technologies that can be deployed to secure the 2 link. Examples of technologies that can be deployed to secure the
Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X].
By examining the Secured Medium flag in the Peer Type Data Item 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 (Section 13.4), a router can decide if it is able to trust the
 End of changes. 16 change blocks. 
95 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/