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

[Henning Rogge <[e-mail]>]

On Wed, Aug 7, 2019 at 1:58 AM Juliusz Chroboczek <[e-mail]> wrote:
>
> Hi Henning,
>
> Good to hear from you again.
>
> The two main authors of this draft appear to be on holiday, so I'll answer
> your review to the best of my capacities.
>
> > 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 ofa service attack.
>
> In Babel, bidirectional reachability is established by a Hello/IHU
> exchange.  This document requires IHUs to be authenticated, therefore
> bidirectional reachability will never be established with an attacker.
>
> However, this doesn't prevent DoS attacks:
>
>   - an attacker could send cleartext Hellos from spoofed addresses, thus
>     causing the victim to create unbounded numbers of neighbour entries;
>   - an attacker could send DTLS ClientHello packets from spoofed
>     addresses, with a similar effect.

As long as this "unverified" links are not used for global routing I
would not be worried...

you can never prevent a direct neighbor from doing a DoS.

> Requiring an authenticated Hello is not workable, since an authenticated
> Hello cannot be sent until after the DTLS handshake has completed.

And there is also the point that DTLS and Multicast don't mix well...

> This is somewhat mitigated by the fact that only packets from link-local
> addresses are accepted (see Section 2.1 of this draft and Section 4 of
> RFC 6126bis).  This is what the draft has to say on the subject (Section 5):

>    A malicious client might attempt to perform a high number of DTLS
>    handshakes with a server.  As the clients are not uniquely identified
>    by the protocol and can be obfuscated with IPv6 temporary addresses,
>    a server needs to mitigate the impact of such an attack.  Such
>    mitigation might involve rate limiting handshakes from a given subnet
>    or more advanced denial of service avoidance techniques beyond the
>    scope of this document.
>
> I'm not happy with this either.

I think some parts of this information could be useful for the
Security Considerations section.

Most people don't know BABEL that deep, so giving them some advise
what has already been considered and what no is always good.

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

Sorry, missed that... good to see it has already dealt with.

> > 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).
>
> I am not competent to answer this, we'll need to wait for David or
> Antonin to resurface.

Sure... I was away fore quite a while too after my post.

Henning Rogge