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

[David Schinazi <[e-mail]>]

I think this thread may have forked...

Henning's original email from July 5:
https://mailarchive.ietf.org/arch/msg/babel/_Jt5gfUMQbnPJFdfvR7HhqO6vSc

Juliusz and I replied shortly after:
https://mailarchive.ietf.org/arch/msg/babel/yNGgOauQHCp5EyMj8ivQxdTcdJI
https://mailarchive.ietf.org/arch/msg/babel/wZOOhPjOBK1xF6EsuxLTCdctcQE

And Juliusz sent a new reply yesterday to which Henning responded:
https://mailarchive.ietf.org/arch/msg/babel/vaJowPOfLBKblh5LYpwSstS7Ins
https://mailarchive.ietf.org/arch/msg/babel/cDvi0BzZoJXUo3TOpkq4YlfZvcY

To summarize the discussions in all these threads.

(1) Bidirectional reachability is protected by DTLS by requiring IHU to be
sent
protected, this reduces the security boundary of the protocol.

(2) We've added text documenting what to do when a node receives a new
connection, this prevents attackers from impacting the neighbor table

(3) We've added text discussing that different ciphers can have different
overheads and that needs to be taken into account when computing MTU

(4) An attacker can create state on a victim by creating many DTLS
connection attempts. We rely on DTLS's DoS prevention mechanisms
(such as cookies) to avoid these issues.

We've made changes to the draft from these comments, and they landed in
draft -07:
https://tools.ietf.org/html/draft-ietf-babel-dtls-07

Please let me know if I missed anything.

Thanks,
David



On Wed, Aug 7, 2019 at 3:57 AM Henning Rogge <[e-mail]> wrote:

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