draft-ietf-babel-dtls-03.txt   draft-ietf-babel-dtls-04.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
Updates: 6126bis (if approved) D. Schinazi Updates: 6126bis (if approved) D. Schinazi
Intended status: Standards Track Google LLC Intended status: Standards Track Google LLC
Expires: July 12, 2019 J. Chroboczek Expires: August 10, 2019 J. Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
January 8, 2019 February 6, 2019
Babel Routing Protocol over Datagram Transport Layer Security Babel Routing Protocol over Datagram Transport Layer Security
draft-ietf-babel-dtls-03 draft-ietf-babel-dtls-04
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 documents neighbours or protect messages sent between them. This documents
specifies a mechanism to ensure these properties, using Datagram specifies a mechanism to ensure these properties, using Datagram
Transport Layer Security (DTLS). This document updates RFC 6126bis. Transport Layer Security (DTLS). This document updates RFC 6126bis.
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 July 12, 2019. This Internet-Draft will expire on August 10, 2019.
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 23 skipping to change at page 2, line 23
2.1. DTLS Connection Initiation . . . . . . . . . . . . . . . 3 2.1. DTLS Connection Initiation . . . . . . . . . . . . . . . 3
2.2. Protocol Encoding . . . . . . . . . . . . . . . . . . . . 4 2.2. Protocol Encoding . . . . . . . . . . . . . . . . . . . . 4
2.3. Transmission . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Transmission . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Reception . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Reception . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
skipping to change at page 3, line 38 skipping to change at page 3, line 38
Babel packets can be sent over to both unicast and multicast Babel packets can be sent over to both unicast and multicast
destinations. destinations.
2.1. DTLS Connection Initiation 2.1. DTLS Connection Initiation
Babel over DTLS operates on a different port than unencrypted Babel. Babel over DTLS operates on a different port than unencrypted Babel.
All Babel over DTLS nodes MUST act as DTLS servers on a DTLS port, All Babel over DTLS nodes MUST act as DTLS servers on a DTLS port,
and MUST listen for unencrypted Babel traffic on an unencrypted port, and MUST listen for unencrypted Babel traffic on an unencrypted port,
which MUST be distinct from the DTLS port. The default port for which MUST be distinct from the DTLS port. The default port for
Babel over DTLS is registered with IANA as the "babel-dtls" port (UDP Babel over DTLS is registered with IANA as the "babel-dtls" port (UDP
port TBD), and the unencrypted port is registered as the "babel" port port TBD, see Section 4), and the unencrypted port is registered as
(UDP port 6696). Nodes SHOULD use these default ports. the "babel" port (UDP port 6696). Nodes SHOULD use these default
ports.
When a Babel node discovers a new neighbor (generally by receiving an When a Babel node discovers a new neighbor (generally by receiving an
unencrypted multicast Babel packet), it compares the neighbour's IPv6 unencrypted multicast Babel packet), it compares the neighbour's IPv6
link-local address with its own, using network byte ordering. If a link-local address with its own, using network byte ordering. If a
node's address is lower than the recently discovered neighbor's node's address is lower than the recently discovered neighbor's
address, it acts as a client and connects to the neighbor. In other address, it acts as a client and connects to the neighbor. In other
words, the node with the lowest address is the DTLS client for this words, the node with the lowest address is the DTLS client for this
pairwise relationship. As an example, fe80::1:2 is considered lower pairwise relationship. As an example, fe80::1:2 is considered lower
than fe80::2:1. than fe80::2:1.
The node acting as DTLS client initiates its DTLS connection from an The node acting as DTLS client initiates its DTLS connection from an
ephemeral UDP port. Nodes SHOULD ensure that new client DTLS ephemeral UDP port. Nodes SHOULD ensure that new client DTLS
connections use different ephemeral ports from recently used connections use different ephemeral ports from recently used
connections to allow servers to differentiate between the new and old connections to allow servers to differentiate between the new and old
DTLS connections. Alternatively, nodes MAY use DTLS connection DTLS connections. Alternatively, nodes MAY use DTLS connection
identifiers [DTLS-CID] as a higher-entropy mechanism to distinguish identifiers [DTLS-CID] as a higher-entropy mechanism to distinguish
between connections. between connections.
When a node receives a new DTLS connection, it MUST verify that the When a node receives a new DTLS connection, it MUST verify that the
source IP address is an IPv6 link-local address; if it is not, it source IP address is an IPv6 link-local address; if it is not, it
MUST reject the connection. Nodes MUST use mutual authentication MUST reject the connection. Nodes use mutual authentication
(authenticating both client and server); servers MUST request client (authenticating both client and server); servers MUST send a
authentication by sending a CertificateRequest message. If either CertificateRequest message and subsequently authenticate the client.
node fails to verify the peer's authentication, it MUST abort the Implementations MUST support authenticating peers against a local
DTLS handshake. Nodes MUST only negotiate DTLS version 1.2 or store of credentials. If either node fails to authenticate its peer
higher. Nodes MUST use DTLS replay protection to prevent attackers against its local policy, it MUST abort the DTLS handshake. Nodes
from replaying stale information. Nodes SHOULD drop packets that MUST only negotiate DTLS version 1.2 or higher. Nodes MUST use DTLS
have been reordered by more than several IHU intervals, to avoid replay protection to prevent attackers from replaying stale
letting attackers make stale information last longer. information. Nodes SHOULD drop packets that have been reordered by
more than several IHU intervals, to avoid letting attackers make
stale information last longer.
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 31 skipping to change at page 6, line 31
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.
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. The
IANA registry will include a reference to this document.
5. Security Considerations 5. Security Considerations
Confidential interaction between two Babel peers requires Datagram Confidential interaction between two Babel peers requires Datagram
Transport Layer Security (DTLS) with a cipher suite offering Transport Layer Security (DTLS) with a cipher suite offering
confidentiality protection. The guidance given in [RFC7525] MUST be confidentiality protection. The guidance given in [RFC7525] MUST be
followed to avoid attacks on DTLS. followed to avoid attacks on DTLS.
A malicious client might attempt to perform a high number of DTLS A malicious client might attempt to perform a high number of DTLS
handshakes with a server. As the clients are not uniquely identified handshakes with a server. As the clients are not uniquely identified
skipping to change at page 8, line 31 skipping to change at page 8, line 36
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, Barbara Stark, Markus Stenberg, Gabriel Kerneis, Antoni Przygienda, Barbara Stark, Markus Stenberg,
Dave Taht, and Martin Thomson for their input and contributions. The Dave Taht, Martin Thomson, and Sean Turner for their input and
performance considerations in this document were inspired from the contributions. The performance considerations in this document were
ones for DNS over DTLS [RFC8094]. inspired from the 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
David Schinazi David Schinazi
Google LLC Google LLC
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, California 94043 Mountain View, California 94043
USA USA
Email: dschinazi.ietf@gmail.com Email: dschinazi.ietf@gmail.com
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
 End of changes. 11 change blocks. 
21 lines changed or deleted 25 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/