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

[Juliusz Chroboczek <[e-mail]>]

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