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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 05:40:39 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-babel-dtls-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-dtls/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Unfortunately I need to discuss the port request again.

First of all I would like to comment on the shepherd write-up which says:
"The document requires only the allocation of a port number for Babel
over DTLS. Having such a second port for the secured version of a
protocol is a fairly common practice. This is shown in the IANA
Considerations section."
This is not correct. Having a second port for the secured version of a protocol
WAS common practice. However RFC6335 say now "The use of separate
   service name or port number assignments for secure and insecure
   variants of the same service is to be avoided in order to discourage
   the deployment of insecure services."

Anyway, in this case I understand that a different port is desired because
unencrypted HELLO messages are still received over the default babel port.
However, it is not clear to me why a fixed/default port is needed. The
neighbour needs to be discovered in some why, no matter what, before a DTLS
connection can be established and this discovery procedure could indicate a
dynamic port number that the peer is listening on for babel over DTLS. E.g. the
multicast HELLO could have a new TLV with this port information. Please clarify
why this option is not suitable! Thanks!

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This specification seems to only support babel over DTLS for IPv6. This should
be stated clearly in the introduction.

---

From: David Schinazi <[email-masked]>
Date: Wed, 7 Aug 2019 11:09:07 -0700

Hello Mirja, and thank you for your review.

(1) Discuss - port number

Using an ephemeral port that is discovered at runtime would add a failure
mode
to the protocol and make it less robust. Implementors in the working group
felt strongly that a separate port is simpler, safer and more reliable.

(2) Comment on IPv4/IPv6

Thanks for catching this! We've allowed IPv4 in this commit:
https://github.com/jech/babel-drafts/commit/335e3edf06ac58853e33475e32f2d452022e04e0
It'll be included in the next revision of the draft.

Thanks,
David

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 8 Aug 2019 12:25:32 +0200

Hi David,

Please see below.

> On 7. Aug 2019, at 20:09, David Schinazi <[email-masked]> wrote:
> 
> Using an ephemeral port that is discovered at runtime would add a failure mode

Can you please explain why that would make it less robust? I would actually think that is would make it more robust. In any case you need to somehow discovery the neighbour. Usually the babel HELLO would be used for that. When you add an new TLV to that HELLO that indicates a port that should be used for DTLS, this also gives you and additional indication that the peer sending the hello actually supports DTLS which I believe would make it more robust.

Further with respect to security and topics probably recently discussed, not having a default port would make it harder for an attacker to flood a route with DTLS handshakes on that port. I think that’s an additional benefit that should be seriously considered.

Was this specific proposal discussed in the working group?

> It'll be included in the next revision of the draft.

Thanks!

Mirja

> 
> Thanks,
> David
> 
> 
> On Wed, Aug 7, 2019 at 5:40 AM Mirja Kühlewind via Datatracker <[email-masked]> wrote:

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 08 Aug 2019 13:17:08 +0200

>> to the protocol and make it less robust.

> Can you please explain why that would make it less robust? I would
> actually think that is would make it more robust. In any case you need
> to somehow discovery the neighbour. Usually the babel HELLO would be
> used for that. When you add an new TLV to that HELLO that indicates
> a port that should be used for DTLS, this also gives you and additional
> indication that the peer sending the hello actually supports DTLS which
> I believe would make it more robust.

That's an intruiguing idea.

> Further with respect to security and topics probably recently discussed, not having a default port would make it harder for an attacker to flood a route with DTLS handshakes on that port.

Could you please explain what happens if an attacker sends out 65535
spoofed multicast Hellos indicating 65535 distinct ports?

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 8 Aug 2019 13:44:58 +0200

> On 8. Aug 2019, at 13:17, Juliusz Chroboczek <[email-masked]> wrote:
> 

You maybe rate limit DTLS connection attempts…? I didn’t fully design the protocol here but would like the wg to consider such an approach. However, I guess it might make sense to even rate limit in the proposed approach, or cache for a certain time that a connection attempt to a certain peer failed before trying again.

Mirja

---

From: David Schinazi <[email-masked]>
Date: Thu, 8 Aug 2019 09:44:29 -0700

Hi Mirja,

Negotiated parameters are generally less robust than hard-coded ones
because they open us up to state mismatch bugs.

That said, I'm not certain we want to redesign protocol fundamentals in
this review thread. You had previously asked us
to investigate the feasibility of not having an assigned port within the
working group. The authors took that advice and
brought the discussion to the working group:
https://mailarchive.ietf.org/arch/msg/babel/Mo4wxCQbgcNK8rPcKuNvOqxCopU
The outcome of that discussion appeared to be clear consensus on requesting
another port.

I understand your rationale for pushing back on port allocations, and I'm
glad we had a conversation about alternatives,
but the discussion of pros and cons lead us to the conclusion that a second
port will improve the protocol's chances of success.

Thanks,
David

On Thu, Aug 8, 2019 at 4:45 AM Mirja Kuehlewind <[email-masked]> wrote:

> >> Further with respect to security and topics probably recently
> discussed, not having a default port would make it harder for an attacker
> to flood a route with DTLS handshakes on that port.
> >
> You maybe rate limit DTLS connection attempts…? I didn’t fully design the
> protocol here but would like the wg to consider such an approach. However,
> I guess it might make sense to even rate limit in the proposed approach, or
> cache for a certain time that a connection attempt to a certain peer failed
> before trying again.
>
> Mirja
>
>
> >
> > -- Juliusz
> >
> >
>
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 08 Aug 2019 19:16:21 +0200

> 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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 14 Aug 2019 16:52:25 +0200

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 <[email-masked]> wrote:
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Aug 2019 19:10:06 +0200

> Thanks for the detailed explanation. I believe the underlying problem is
> that in this approach the Hello is not authenticated.

Exactly.

One of the important properties of this protocol is that it uses
a previously standardised protocol (DTLS) for all crypto work.  David
feels that is important.  Since the IETF has not standardised any
general-purpose security mechanism that is suitable for protecting
multicast traffic, we're stuck.

(This is not a criticism of DTLS, which has a well-defined scope.  This
might or might not be a criticism of a now-concluded high-profile IETF WG.)

-- Juliusz

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Aug 2019 00:06:51 -0500

> multicast traffic, we're stuck.

There is perhaps some content of note in
https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm though it of
course does not meet the precondition, at present.

-Ben