Babel Routing Protocol over Datagram Transport Layer Security
Extracted elements (27)
Babel over DTLS operates on a separate port (6699) from unprotected Babel (6696) so that a node can simultaneously listen for unencrypted Multicast Hellos (for neighbour discovery) while enforcing DTLS for all other traffic.
DTLS is a client-server protocol while Babel is peer-to-peer; to resolve this, the node with the numerically lower IP address (in network byte order) acts as DTLS client. This deterministic rule avoids the need for out-of-band coordination.
Multicast Hellos are intentionally allowed to be sent unprotected because DTLS only protects unicast communication; this is accepted as a trade-off to enable neighbour discovery in the absence of an out-of-band mechanism.
The MTU reception requirement does not account for DTLS overhead because the peer may not have the ability to compute that overhead, and lower layers may fragment the packet independently.
To reduce DTLS handshake overhead — particularly large ServerHello certificates — Babel peers can use raw public keys (RFC 7250), the Cached Information Extension (RFC 7924), or TLS False Start (RFC 7918) to reduce round-trips and bytes on the wire.
Babel over DTLS provides a single authentication domain: all nodes with valid credentials can convey any routing information. This document does not prescribe identity management mechanisms; details are left to deployment profiles.
Distinct DTLS connections may use different cipher suites with different per-packet overhead, meaning the effective MTU to one neighbour on a link can differ from the MTU to another neighbour on the same link.
When Babel over DTLS and unprotected Babel coexist on the same network, DTLS nodes will attempt connections to unprotected nodes that will not respond. Babel over DTLS implementations SHOULD rate-limit their DTLS connection attempts to avoid causing undue load.
A node running both Babel over DTLS and unprotected Babel MUST ensure that it runs them on separate interfaces, as the security properties of Babel over DTLS rely on ignoring unprotected Babel packets other than Multicast Hellos.
All Babel over DTLS nodes MUST act as DTLS servers on the babel-dtls UDP port (6699) and MUST listen for unencrypted Babel traffic on the babel port (6696); these two ports MUST be distinct.
Babel over DTLS nodes MUST NOT send any TLVs over the unprotected 'babel' port, with the exception of Hello TLVs without the Unicast flag set. Nodes MUST NOT send any unprotected unicast packets.
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.
Nodes MUST discard the DTLS state associated with a neighbour after a finite time of not receiving valid DTLS packets, to prevent an attacker from making a node believe it has reachability to a disconnected neighbour.
Nodes MUST NOT send Babel packets larger than the attached interface's MTU adjusted for known lower-layer headers (at least UDP and IP) or 512 octets, whichever is larger, but not exceeding 2^16-1 adjusted for lower-layer headers.
Nodes MUST silently ignore any unprotected packet sent over unicast. When parsing an unprotected packet, a node MUST silently ignore all TLVs that are not of type Hello. Nodes MUST also silently ignore any unprotected Hello with the Unicast flag set.
Nodes MUST use DTLS replay protection to prevent attackers from replaying stale information. Nodes SHOULD drop packets that have been reordered by more than two IHU intervals.
Nodes use mutual authentication: clients MUST authenticate servers and servers MUST authenticate clients. Implementations MUST support authenticating peers against a local store of credentials. If either node fails to authenticate its peer, it MUST abort the DTLS handshake.
The guidance given in BCP 195 MUST be followed to avoid attacks on DTLS. Additionally, nodes MUST only negotiate DTLS version 1.2 or higher.
Unless some out-of-band neighbour discovery mechanism is available, nodes SHOULD periodically send unprotected Multicast Hellos to ensure discovery of new neighbours.
When a neighbour entry is flushed from the neighbour table, its associated DTLS state SHOULD be discarded. The node SHOULD send a DTLS close_notify alert to the neighbour if it believes the link is still viable.
When a node receives a new DTLS connection, it MUST verify that the source IP address is either an IPv6 link-local address or an IPv4 address belonging to the local network; if it is neither, it MUST reject the connection.
The DTLS client initiates its connection from an ephemeral UDP port. Nodes SHOULD ensure new client connections use different ephemeral ports from recently used ones to allow servers to differentiate old from new DTLS connections; alternatively, DTLS connection identifiers may be used.
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 encapsulated and protected by DTLS. No partial protection of packet fields is performed.
IANA has registered UDP port 6699 with service name 'babel-dtls' for use by the Babel Routing Protocol over DTLS.
A malicious client may perform a high number of DTLS handshakes (including Slowloris-style slow handshakes) against a server. Mitigations include rate-limiting handshakes from a given subnet; clients are not uniquely identified until the handshake completes and may use IPv6 temporary addresses to obscure their identity.
DTLS cannot detect an active on-path attacker that intercepts valid packets and replays them later, which could falsely maintain perceived bidirectional reachability after a neighbour disconnects. Nodes MUST discard DTLS state after a finite period without valid packets, and SHOULD discard packets reordered by more than two IHU intervals.
Multicast Hellos are sent unprotected and can be tampered with by an attacker, potentially causing bidirectional reachability detection to fail via erroneous Seqno or Interval values. Implementations SHOULD also emit protected Unicast Hellos to mitigate this denial-of-service vector.