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

[David Schinazi <[e-mail]>]

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

On Fri, Jul 5, 2019 at 5:32 AM Henning Rogge <[e-mail]> wrote:

>
> 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.
>

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.


> 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.
>

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.


> 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).
>

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