Subject: Re: [babel] rtgdir Last Call Review requested: draft-ietf-babel-dtls

From: Henning Rogge <[email-masked]>
Date: Fri, 5 Jul 2019 14:31:56 +0200

Hi,

I was asked by the Routing Directorate to do a last call review of
draft-ietf-babel-dtls-06.

I like that the draft is quite short, which is a good thing for a
security draft. I have found a few question you can consider to
address in the final document.

Chapter 2.3:
I wonder if using DTLS protected unicast Hellos should be mandatory...
using unprotected multicast to determine bidirectional reachability
looks like a good way to do a cheap denial of service attack.

Chapter 2.5:
What happens when a node starts a new DTLS connection and there is
already one in the neighbor table? This could both be an attempt to
attack Babel, a reboot of a node or just a matter of misconfiguration
of two nodes.

Chapter 3:
Different pairs of nodes could select different ciphers, resulting in
different MTUs. I assume this is no problem for Babel (could be
mentioned in the chapter).

Some of the design decisions of regarding the three questions could be
mentioned in chapter 5 (Security Implications).

Henning Rogge

---

From: David Schinazi <[email-masked]>
Date: Fri, 5 Jul 2019 18:21:01 -0700

Hi Henning, and thank you for your review. Responses inline.

> looks like a good way to do a cheap denial of service attack.

In Babel, bidirectional reachability is established using both Hellos and
IHUs.
We explicitly require DTLS protection for IHUs to prevent an attacker
from tricking you into thinking you have bidirectional reachability.
This reduces the protocol's attack surface by limiting what an attacker can
do.

Unicast Hellos are protected by the rule that all unicast traffic must be
protected by DTLS. This is also there to reduce attack surface.

DTLS itself contains mechanisms to prevent denial of service attacks
(see section 4.2.1 of RFC 6347), and it is good practice for us to use
those instead of coming up with our own.

> attack Babel, a reboot of a node or just a matter of misconfiguration

There is no reason for a node to initiate a DTLS connection if it already
has one to the neighbor in question. However, you're right that receiving
a new connection when we already have one wasn't explicitly discussed.
I've added a sentence to Section 2.1:
    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.

> mentioned in the chapter).

Good point. I've added this text to section 3:
    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.

The changes above are reflected in draft -07.

Thanks,
David

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 07 Jul 2019 14:15:29 +0200

> In Babel, bidirectional reachability is established using both Hellos and IHUs.
> This reduces the protocol's attack surface by limiting what an attacker can do.

I think David's answer is clear, but I'll insist some more, since this is
an important point (and we got it wrong in an earlier draft).

In Babel, the equivalent of an OSPF Hello is a pair of Hello (establishes
reverse reachability) and IHU (establishes direct reachability).
Bidirectional reachability is only established after a successful
Hello/IHU exchange.

In cleartext Babel, both Hellos and IHUs can be sent over either multicast
or unicast.  In DTLS-protected Babel, Hellos can be sent over either
(unprotected) multicast or (protected) unicast, while IHUs can only be
sent over (protected) unicast and are silently ignored if sent over multicast.

Hence, bidirectional reachability requires a protected IHU to be received.

-- Juliusz