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

[Juliusz Chroboczek <[e-mail]>]

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