| RFC 8968 | Babel over DTLS | January 2021 |
| Décimo, et al. | Standards Track | [Page] |
The Babel Routing Protocol does not contain any means to authenticateneighbours or provide integrity or confidentiality for messages sent betweenthem. This document specifies a mechanism to ensure these properties usingDatagram Transport Layer Security (DTLS).¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8968.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The Babel routing protocol[RFC8966] does not containany means to authenticate neighbours or protect messages sent between them.Because of this, an attacker is able to send maliciously crafted Babelmessages that could lead a network to route traffic to an attacker orto an under-resourced target, causing denial of service.This document specifies a mechanism to prevent such attacks usingDatagram Transport Layer Security (DTLS)[RFC6347].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The protocol described in this document protects Babel packets withDTLS. As such, it inherits the features offered by DTLS, notablyauthentication, integrity, optional replay protection, confidentiality, andasymmetric keying. It is therefore expected to be applicable in a widerange of environments.¶
There exists another mechanism for securing Babel, namely Message Authentication Code (MAC)authentication for Babel (Babel-MAC)[RFC8967]. Babel-MAC only offers basicfeatures, namely authentication, integrity, and replay protection witha small number of symmetric keys. A comparison of Babel security mechanismsand their applicability can be found in[RFC8966].¶
Note that Babel over DTLS provides a single authentication domain, meaningthat all nodes that have the right credentials can convey any and all routinginformation.¶
DTLS supports several mechanisms by which nodes can identify themselvesand prove possession of secrets tied to these identities. This documentdoes not prescribe which of these mechanisms to use; details of identitymanagement are left to deployment profiles of Babel over DTLS.¶
Babel over DTLS requires some changes to how Babel operates.First, DTLS is a client-server protocol, while Babel is a peer-to-peerprotocol. Second, DTLS can only protect unicast communication, whileBabel packets can be sent to both unicast and multicast destinations.¶
Babel over DTLS operates on a different port than unencrypted Babel.All Babel over DTLS nodesMUST act as DTLS servers on a given UDP portandMUST listen for unencrypted Babel traffic on another UDP port, whichMUST be distinct from the first one. The default port for Babel over DTLS isregistered with IANA as the "babel-dtls" port (UDP port 6699, seeSection 4), and the port exchanging unencryptedBabel traffic is registered as the "babel" port (UDP port 6696,seeSection 5 of [RFC8966]).¶
When a Babel node discovers a new neighbour (generally byreceiving an unencrypted multicast Babel packet), it compares the neighbour'sIP address with its own, using network byte ordering. If a node'saddress is lower than the recently discovered neighbour's address, it actsas a client and connects to the neighbour. In other words, the node withthe lowest address is the DTLS client for this pairwise relationship.As an example, fe80::1:2 is considered lower than fe80::2:1.¶
The node acting as DTLS client initiates its DTLS connection from anephemeral UDP port. NodesSHOULD ensure that new client DTLS connectionsuse different ephemeral ports from recently used connections to allowservers to differentiate between the new and old DTLS connections.Alternatively, nodes could use DTLS connection identifiers[DTLS-CID] as a higher-entropy mechanism to distinguish betweenconnections.¶
When a node receives a new DTLS connection, itMUST verify that the sourceIP address is either an IPv6 link-local address or an IPv4 address belongingto the local network; if it is neither, itMUST reject theconnection. Nodes use mutual authentication (authenticatingboth client and server); clientsMUST authenticate servers and serversMUSTauthenticate clients. ImplementationsMUST supportauthenticating peers against a local store of credentials. If either nodefails to authenticate its peer against its local policy, itMUST abort the DTLShandshake. The guidance given in[BCP195]MUST be followed toavoid attacks on DTLS. Additionally, nodesMUST only negotiate DTLS version1.2 or higher. NodesMUSTuse DTLS replay protection to prevent attackers from replaying staleinformation. NodesSHOULD drop packets that have been reordered by more thantwo IHU (I Heard You) intervals, to avoid letting attackers make staleinformation last longer. If a node receives a new DTLS connection from aneighbour to whom it already has a connection, the nodeMUST NOT discard theolder connection until it has completed the handshake of the new one andvalidated the identity of the peer.¶
Babel over DTLS sends all unicast Babel packets protected by DTLS. Theentire Babel packet, from the Magic byte at the start of the Babel headerto the last byte of the Babel packet trailer, is sent protected by DTLS.¶
When sending packets, Babel over DTLS nodesMUST NOT send any TLVs overthe unprotected "babel" port, with the exception of Hello TLVs without theUnicast flag set. Babel over DTLS nodesMUST NOT send any unprotected unicastpackets. This ensures the confidentiality of the information sent in Babelpackets (e.g., the network topology) by only sending it encrypted by DTLS.Unless some out-of-band neighbour discovery mechanism is available,nodesSHOULD periodically send unprotected Multicast Hellos to ensurediscovery of new neighbours. In order to maintain bidirectional reachability,nodes can either rely entirely on unprotected Multicast Hellos, or sendprotected Unicast Hellos in addition to the Multicast Hellos.¶
Since Babel over DTLS only protects unicast packets, implementors mayimplement Babel over DTLS by modifying an implementation of Babel without DTLSsupport and replacing any TLV previously sent over multicast with a separateTLV sent over unicast for each neighbour. TLVs previously sent over multicastcan be replaced with the same contents over unicast, with the exception ofHellos as described above. Some implementations could also change the contentsof IHU TLVs when converting to unicast in order to remove redundantinformation.¶
Babel over DTLS nodes can receive Babel packets either protected over aDTLS connection or unprotected directly over the "babel" port. To ensure thesecurity properties of this mechanism, unprotected packets are treateddifferently. NodesMUST silently ignore any unprotected packet sent overunicast. When parsing an unprotected packet, a nodeMUST silentlyignore all TLVs that are not of type Hello. NodesMUST also silently ignoreany unprotected Hello with the Unicast flag set. Note that receiving anunprotected packet can still be used to discover new neighbours, even whenall TLVs in that packet are silently ignored.¶
It isRECOMMENDED for nodes to associate the state of their DTLS connectionwith their neighbour table. When a neighbour entry is flushed from theneighbour table (Appendix A of [RFC8966]), its associatedDTLS stateSHOULD be discarded. The nodeSHOULD send a DTLS close_notify alertto the neighbour if it believes the link is still viable.¶
ImplementationsMAY implement both Babel over DTLS and unprotected Babel.Additionally, a nodeMAY simultaneously run both Babel over DTLS andunprotected Babel. However, a node running bothMUST ensure that it runsthem on separate interfaces, as the security properties of Babel over DTLSrely on ignoring unprotected Babel packets (other than Multicast Hellos).An implementationMAY offer configuration options to allow unprotected Babel onsome interfaces but not others, which effectively gives nodes on that interfacethe same access as authenticated nodes; however, thisSHOULD NOT be done unless thatinterface has a mechanism to authenticate nodes at a lowerlayer (e.g., IPsec).¶
If Babel over DTLS and unprotected Babel are both operated on the samenetwork, the Babel over DTLS implementation will receive unprotected MulticastHellos and attempt to initiate a DTLS connection. These connection attemptscan be sent to nodes that only run unprotected Babel, who will notrespond. Babel over DTLS implementationsSHOULD therefore rate-limit theirDTLS connection attempts to avoid causing undue load on the network.¶
Compared to unprotected Babel, DTLS adds header, authentication tag, andpossibly block-size padding overhead to every packet. This reduces the size ofthe Babel payload that can be carried. This document does not relax thepacket size requirements inSection 4 of [RFC8966] butrecommends that DTLS overhead be taken into account when computing maximumpacket size.¶
More precisely, nodesSHOULD compute the overhead of DTLS depending onthe ciphersuites in use andSHOULD NOT send Babel packets larger than theinterface maximum transmission unit (MTU) minus the overhead of IP, UDP,and DTLS. NodesMUST NOT send Babel packets larger than the attachedinterface's MTU adjusted for known lower-layer headers (at least UDP andIP) or 512 octets, whichever is larger, but not exceeding 216 -1 adjusted for lower-layer headers. Every Babel speakerMUST be able toreceive packets that are as large as any attached interface's MTU adjustedfor UDP and IP headers or 512 octets, whichever is larger. Note that thisrequirement on reception does not take into account the overhead of DTLSbecause the peer may not have the ability to compute the overhead of DTLS,and the packet may be fragmented by lower layers.¶
Note that distinct DTLS connections can use different ciphers, which canhave different amounts of per-packet overhead. Therefore, the MTU to oneneighbour can be different from the MTU to another neighbour on the samelink.¶
IANA has registered a UDP portnumber, called "babel-dtls", for use by Babel over DTLS:¶
A malicious client might attempt to perform a high number of DTLShandshakes with a server. As the clients are not uniquely identifiedby the protocol until the handshake completes and can be obfuscated with IPv6temporary addresses, a server needs to mitigate the impact of such an attack.Note that attackers might attempt to keep in-progress handshakes open for aslong as possible by using variants on the attack commonly known asSlowloris[SLOWLORIS]. Mitigating these attacks might involvelimiting the rate of handshakes from a given subnet or more advanced denial ofservice avoidance techniques beyond the scope of this document.¶
Babel over DTLS allows sending Multicast Hellos unprotected; attackers cantherefore tamper with them. For example, an attacker could send erroneousvalues for the Seqno and Interval fields, causing bidirectionalreachability detection to fail. While implementationsMAY use Multicast Hellosfor link quality estimation, theySHOULD also emit protected Unicast Hellos toprevent this class of denial-of-service attack.¶
While DTLS provides protection against an attacker that replays validpackets, DTLS is not able to detect when an active on-path attacker interceptsvalid packets and resends them at a later time. This attack could be used tomake a node believe it has bidirectional reachability to a neighbour eventhough that neighbour has disconnected from the network. To prevent thisattack, nodesMUST discard the DTLS state associated with a neighbour after afinite time of not receiving valid DTLS packets. This can be implemented by,for example, discarding a neighbour's DTLS state when its associated IHU timerfires. Note that relying solely on the receipt of Hellos is not sufficient asMulticast Hellos are sent unprotected. Additionally, an attacker could savesome packets and replay them later in hopes of propagating stale routinginformation at a later time. This can be mitigated by discarding receivedpackets that have been reordered by more than two IHU intervals.¶
To reduce the number of octets taken by the DTLS handshake,especially the size of the certificate in the ServerHello (which canbe several kilobytes), Babel peers can use raw public keys[RFC7250] or the Cached Information Extension[RFC7924]. The Cached Information Extension avoidstransmitting the server's certificate and certificate chain if theclient has cached that information from a previous TLS handshake. TLSFalse Start[RFC7918] can reduce round trips byallowing the TLS second flight of messages (ChangeCipherSpec) to alsocontain the (encrypted) Babel packet.¶
The authors would like to thankRoman Danyliw,Donald Eastlake,Thomas Fossati,Benjamin Kaduk,Gabriel Kerneis,Mirja Kühlewind,Antoni Przygienda,Henning Rogge,Dan Romascanu,Barbara Stark,Markus Stenberg,Dave Taht,Martin Thomson,Sean Turner,andMartin Vigoureuxfor their input and contributions.The performance considerations in this document were inspired from the ones forDNS over DTLS[RFC8094].¶