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

[David Schinazi <[e-mail]>]

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