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

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 01:58:11 +0200

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.

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

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.

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

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

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

David?  Antonin?

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Wed, 7 Aug 2019 12:57:14 +0200

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

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

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

>    validated the identity of the peer.

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

> I am not competent to answer this, we'll need to wait for David or

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

Henning Rogge

---

From: David Schinazi <[email-masked]>
Date: Wed, 7 Aug 2019 09:59:20 -0700

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

---

From: David Schinazi <[email-masked]>
Date: Wed, 7 Aug 2019 10:46:03 -0700

[Adding the IESG to this thread since there might be overlap between
conversations]

---

From: Henning Rogge <[email-masked]>
Date: Thu, 15 Aug 2019 08:23:38 +0200

Hi,

I have looked through the changes you made from draft-06 to draft 09
and I think they help the draft a lot. It now spells out quite a few
common pit traps either explaining how to avoid them or explaining
what to expect. This is a good thing for a security document.

Henning Rogge

On Wed, Aug 7, 2019 at 7:46 PM David Schinazi <[email-masked]> wrote:
>
> [Adding the IESG to this thread since there might be overlap between conversations]
>
> On Wed, Aug 7, 2019 at 9:59 AM David Schinazi <[email-masked]> wrote:
>>
>> (1) Bidirectional reachability is protected by DTLS by requiring IHU to be sent
>> We've made changes to the draft from these comments, and they landed in draft -07:

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Aug 2019 09:01:36 -0700

Thanks for your helpful comments and for taking another look Henning!

David