draft-ietf-manet-dlep-28.txt   draft-ietf-manet-dlep-29.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: September 4, 2017 Cisco Systems Expires: September 29, 2017 Cisco Systems
D. Satterwhite D. Satterwhite
Broadcom Broadcom
R. Taylor R. Taylor
Airbus Defence & Space Airbus Defence & Space
B. Berry B. Berry
March 3, 2017 March 28, 2017
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-28 draft-ietf-manet-dlep-29
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 September 4, 2017. This Internet-Draft will expire on September 29, 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 4, line 21 skipping to change at page 4, line 21
15.15. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 66 15.15. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 66
15.16. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 66 15.16. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 66
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
17.1. Normative References . . . . . . . . . . . . . . . . . . 66 17.1. Normative References . . . . . . . . . . . . . . . . . . 66
17.2. Informative References . . . . . . . . . . . . . . . . . 67 17.2. Informative References . . . . . . . . . . . . . . . . . 67
Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 68 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 68
Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 68 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 68
B.1. Session Initialization . . . . . . . . . . . . . . . . . 68 B.1. Session Initialization . . . . . . . . . . . . . . . . . 68
B.2. Session Initialization - Refused . . . . . . . . . . . . 69 B.2. Session Initialization - Refused . . . . . . . . . . . . 69
B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 69 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 70
B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 69 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 70
B.5. Router Terminates Session . . . . . . . . . . . . . . . . 70 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 70
B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 70 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 71
B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 71 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 71
B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 72 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 72
B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 73 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 73
Appendix C. Destination Specific Message Flows . . . . . . . . . 73 Appendix C. Destination Specific Message Flows . . . . . . . . . 73
C.1. Common Destination Notification . . . . . . . . . . . . . 73 C.1. Common Destination Notification . . . . . . . . . . . . . 73
C.2. Multicast Destination Notification . . . . . . . . . . . 74 C.2. Multicast Destination Notification . . . . . . . . . . . 74
C.3. Link Characteristics Request . . . . . . . . . . . . . . 75 C.3. Link Characteristics Request . . . . . . . . . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
skipping to change at page 59, line 43 skipping to change at page 59, line 43
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, when TLS is in use, each peer SHOULD check At the transport layer, when TLS is in use, each peer SHOULD check
the validity of credentials presented by the other peer during TLS the validity of credentials presented by the other peer during TLS
session establishment. Implementations following the "dedicated session establishment. Implementations following the "dedicated
deployments" model attempting use of TLS MAY need to consider use of deployments" model attempting to use TLS MAY need to consider use of
pre-shared keys for credentials, and provide specialized techniques pre-shared keys for credentials, and provide specialized techniques
for peer identity validation. Implementations following the for peer identity validation, and MAY refer to [RFC5487] for
"networked deployment" model described in Implementation Scenarios additional details. Implementations following the "networked
SHOULD refer to [RFC7525] for additional details. deployment" model described in Implementation Scenarios 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
information supplied via a DLEP modem. If this is not the case, then information supplied via a DLEP modem. If this is not the case, then
the router SHOULD consider restricting the size of attached subnets, the router SHOULD consider restricting the size of attached subnets,
skipping to change at page 67, line 36 skipping to change at page 67, line 36
[IEEE-802.1X] [IEEE-802.1X]
"IEEE Standards for Local and Metropolitan Area Networks: "IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control", Port based Network Access Control",
DOI 10.1109/IEEESTD.2010.5409813, February 2010. DOI 10.1109/IEEESTD.2010.5409813, February 2010.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <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>.
[RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and
M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit
Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578,
February 2010, <http://www.rfc-editor.org/info/rfc5578>. February 2010, <http://www.rfc-editor.org/info/rfc5578>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, "Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013, RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>. <http://www.rfc-editor.org/info/rfc6890>.
 End of changes. 9 change blocks. 
11 lines changed or deleted 17 lines changed or added

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