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

[Henning Rogge <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>>
>> 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