< draft-ietf-babel-dtls-06.txt   draft-ietf-babel-dtls-07.txt >
Network Working Group A. Decimo Network Working Group A. Decimo
Internet-Draft IRIF, University of Paris-Diderot Internet-Draft IRIF, University of Paris-Diderot
Intended status: Standards Track D. Schinazi Intended status: Standards Track D. Schinazi
Expires: January 3, 2020 Google LLC Expires: January 6, 2020 Google LLC
J. Chroboczek J. Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
July 2, 2019 July 5, 2019
Babel Routing Protocol over Datagram Transport Layer Security Babel Routing Protocol over Datagram Transport Layer Security
draft-ietf-babel-dtls-06 draft-ietf-babel-dtls-07
Abstract Abstract
The Babel Routing Protocol does not contain any means to authenticate The Babel Routing Protocol does not contain any means to authenticate
neighbours or protect messages sent between them. This document neighbours or protect messages sent between them. This document
specifies a mechanism to ensure these properties, using Datagram specifies a mechanism to ensure these properties, using Datagram
Transport Layer Security (DTLS). Transport Layer Security (DTLS).
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 January 3, 2020. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 27 skipping to change at page 2, line 27
2.5. Neighbour table entry . . . . . . . . . . . . . . . . . . 5 2.5. Neighbour table entry . . . . . . . . . . . . . . . . . . 5
2.6. Simultaneous operation of both Babel over DTLS and 2.6. Simultaneous operation of both Babel over DTLS and
unprotected Babel . . . . . . . . . . . . . . . . . . . . 5 unprotected Babel . . . . . . . . . . . . . . . . . . . . 5
3. Interface Maximum Transmission Unit Issues . . . . . . . . . 6 3. Interface Maximum Transmission Unit Issues . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Performance Considerations . . . . . . . . . . . . . 8 Appendix A. Performance Considerations . . . . . . . . . . . . . 8
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 8 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Babel Routing Protocol [RFC6126bis] does not contain any means to The Babel Routing Protocol [RFC6126bis] does not contain any means to
authenticate neighbours or protect messages sent between them. authenticate neighbours or protect messages sent between them.
Because of this, an attacker is able to send maliciously crafted Because of this, an attacker is able to send maliciously crafted
Babel messages which could lead a network to route traffic to an Babel messages which could lead a network to route traffic to an
attacker or to an under-resourced target causing denial of service. attacker or to an under-resourced target causing denial of service.
This document specifies a mechanism to prevent such attacks, using This document specifies a mechanism to prevent such attacks, using
skipping to change at page 4, line 19 skipping to change at page 4, line 19
MUST reject the connection. Nodes use mutual authentication MUST reject the connection. Nodes use mutual authentication
(authenticating both client and server); servers MUST send a (authenticating both client and server); servers MUST send a
CertificateRequest message and subsequently authenticate the client. CertificateRequest message and subsequently authenticate the client.
Implementations MUST support authenticating peers against a local Implementations MUST support authenticating peers against a local
store of credentials. If either node fails to authenticate its peer store of credentials. If either node fails to authenticate its peer
against its local policy, it MUST abort the DTLS handshake. Nodes against its local policy, it MUST abort the DTLS handshake. Nodes
MUST only negotiate DTLS version 1.2 or higher. Nodes MUST use DTLS MUST only negotiate DTLS version 1.2 or higher. Nodes MUST use DTLS
replay protection to prevent attackers from replaying stale replay protection to prevent attackers from replaying stale
information. Nodes SHOULD drop packets that have been reordered by information. Nodes SHOULD drop packets that have been reordered by
more than two IHU intervals, to avoid letting attackers make stale more than two IHU intervals, to avoid letting attackers make stale
information last longer. information last longer. If a node receives a new DTLS connection
from a neighbour to whom it already has a connection, the node MUST
NOT discard the older connection until it has completed the handshake
of the new one and validated the identity of the peer.
2.2. Protocol Encoding 2.2. Protocol Encoding
Babel over DTLS sends all unicast Babel packets protected by DTLS. Babel over DTLS sends all unicast Babel packets protected by DTLS.
The entire Babel packet, from the Magic byte at the start of the The entire Babel packet, from the Magic byte at the start of the
Babel header to the last byte of the Babel packet trailer, is sent Babel header to the last byte of the Babel packet trailer, is sent
protected by DTLS. protected by DTLS.
2.3. Transmission 2.3. Transmission
skipping to change at page 6, line 28 skipping to change at page 6, line 28
attached interface's MTU adjusted for known lower-layer headers (at attached interface's MTU adjusted for known lower-layer headers (at
least UDP and IP) or 512 octets, whichever is larger, but not least UDP and IP) or 512 octets, whichever is larger, but not
exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel exceeding 2^16 - 1 adjusted for lower-layer headers. Every Babel
speaker MUST be able to receive packets that are as large as any speaker MUST be able to receive packets that are as large as any
attached interface's MTU adjusted for UDP and IP headers or 512 attached interface's MTU adjusted for UDP and IP headers or 512
octets, whichever is larger. Note that this requirement on reception octets, whichever is larger. Note that this requirement on reception
does not take into account the overhead of DTLS because the peer may does not take into account the overhead of DTLS because the peer may
not have the ability to compute the overhead of DTLS and the packet not have the ability to compute the overhead of DTLS and the packet
may be fragmented by lower layers. may be fragmented by lower layers.
Note that distinct DTLS connections can use different ciphers, which
can have different amounts of overhead per packet. Therefore, the
MTU to one neighbour can be different from the MTU to another
neighbour on the same link.
4. IANA Considerations 4. IANA Considerations
If this document is approved, IANA is requested to register a UDP If this document is approved, IANA is requested to register a UDP
port number, called "babel-dtls", for use by Babel over DTLS. port number, called "babel-dtls", for use by Babel over DTLS.
Details of the request to IANA are as follows: Details of the request to IANA are as follows:
o Assignee: David Schinazi, dschinazi.ietf@gmail.com o Assignee: IESG, iesg@ietf.org
o Contact Person: David Schinazi, dschinazi.ietf@gmail.com o Contact Person: IETF Chair, chair@ietf.org
o Transport Protocols: UDP only o Transport Protocols: UDP only
o Service Code: None o Service Code: None
o Service Name: babel-dtls o Service Name: babel-dtls
o Desired Port Number: 6699 o Desired Port Number: 6699
o Description: Babel Routing Protocol over DTLS o Description: Babel Routing Protocol over DTLS
skipping to change at page 8, line 47 skipping to change at page 9, line 8
or the Cached Information Extension [RFC7924]. The Cached or the Cached Information Extension [RFC7924]. The Cached
Information Extension avoids transmitting the server's certificate Information Extension avoids transmitting the server's certificate
and certificate chain if the client has cached that information from and certificate chain if the client has cached that information from
a previous TLS handshake. TLS False Start [RFC7918] can reduce round a previous TLS handshake. TLS False Start [RFC7918] can reduce round
trips by allowing the TLS second flight of messages trips by allowing the TLS second flight of messages
(ChangeCipherSpec) to also contain the (encrypted) Babel packet. (ChangeCipherSpec) to also contain the (encrypted) Babel packet.
Appendix B. Acknowledgments Appendix B. Acknowledgments
The authors would like to thank Donald Eastlake, Thomas Fossati, The authors would like to thank Donald Eastlake, Thomas Fossati,
Gabriel Kerneis, Antoni Przygienda, Dan Romascanu, Barbara Stark, Gabriel Kerneis, Antoni Przygienda, Henning Rogge, Dan Romascanu,
Markus Stenberg, Dave Taht, Martin Thomson, Sean Turner and Martin Barbara Stark, Markus Stenberg, Dave Taht, Martin Thomson, Sean
Vigoureux for their input and contributions. The performance Turner and Martin Vigoureux for their input and contributions. The
considerations in this document were inspired from the ones for DNS performance considerations in this document were inspired from the
over DTLS [RFC8094]. ones for DNS over DTLS [RFC8094].
Authors' Addresses Authors' Addresses
Antonin Decimo Antonin Decimo
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Paris Paris
France France
Email: antonin.decimo@gmail.com Email: antonin.decimo@gmail.com
 End of changes. 10 change blocks. 
13 lines changed or deleted 21 lines changed or added

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