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

[David Schinazi <[e-mail]>]

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

David

On Wed, Aug 14, 2019 at 11:24 PM Henning Rogge <[e-mail]> wrote:

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