Re: [babel] Mirja Kühlewind's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Juliusz, hi David,

(Only replying to this mail because it, I think, also covers a reply to David’s last mail.)

Thanks for the detailed explanation. I believe the underlying problem is that in this approach the Hello is not authenticated. However, I understand that changing this part, even though it could be desirable, is much more complex and using a fixed port might indeed be the simplest solution right now.

I will clear my discuss now, however, I would after all appreciate to have more  documentation in the draft why this solution was select and, more important, what limitations other approach have.

Mirja


> On 8. Aug 2019, at 19:16, Juliusz Chroboczek <[e-mail]> wrote:
> 
>>> Could you please explain what happens if an attacker sends out 65535
>>> spoofed multicast Hellos indicating 65535 distinct ports?
> 
>> You maybe rate limit DTLS connection attempts…?
> 
> That's not the issue I had in mind.  What I'm concerned about is that
> you're suggesting to use an unauthentifed TLV to negotiate DTLS connection
> parameters.  That cannot go well.
> 
> Let A and B be honest nodes, and C an attacker.  In the current protocol:
> 
>    A -> multicast: Hello
>    C spoofing A -> multicast: Hello
>    B -> A(well-known port): DTLS ClientHello
> 
> The DTLS connection succeeds even though C spoofed a Hello from A --
> a Hello is a Hello, even if it was spoofed.  In your suggested protocol:
> 
>    A -> multicast: Hello, port=1234
>    C spoofing A -> multicast: Hello, port = 1235
>    C spoofing A -> multicast: Hello, port = 1236
>    C spoofing A -> multicast: Hello, port = 1237
>    ...
>    B -> A(which port?)
> 
> Since B has received a bunch of Hellos ostensiby from A announcing
> different ports, it cannot reliably locate the one that's correct.  An
> on-link attacker can trivially DoS any node of its choosing.
> 
> What is more:
> 
>  - You can no longer identify Babel traffic -- it's just encrypted DTLS
>    with random ports.  What does that mean from a management point of view?
> 
>  - An attacker can cause any Babel node to send a DTLS ClientHello to an
>    arbitrary IP and port.  What consequences does that have for the
>    security and DoS-resistance of unrelated protocols?
> 
> Mirja, in the light of the above, you'll doubtless understand that we feel
> little motivation to spend time implementing your suggested protocol and
> experimenting with it.  (And this working group has been following the
> policy of implementing everythig and listening to implementation experience,
> a policy that we like and do not wish to change.)
> 
> -- Juliusz
>