Subject: [babel] Babel over unicast

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 10 Mar 2018 15:06:35 +0100

Hi,

I've just pushed the code to run Babel over unicast.  Antonin is using
this for his DTLS code, so it's rather important if we're serious about
DTLS.

The current code sends Hellos and IHUs over multicast, and all other TLVs
over unicast.  This has two consequences:

  1. I never use the unicast Hellos extension; I'm still not convinced
     that it should stay in the spec, I'm waiting for somebody to actually
     show it's useful;
  2. Hellos and IHUs won't be protected by DTLS.  I'd like some security
     specialist to convince me whether that's a problem.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Sat, 10 Mar 2018 13:00:17 -0800

Hi Juliusz,

I wouldn't call myself a "security specialist", but I do think this can be a problem.

In the rest of this email, I use "protected" to mean "protected by DTLS", as in
encrypted, integrity-checked and authenticated. The most important aspect
of this is to prevent tampering.

Let's assume there's an attacker on an open Wi-Fi network Babel is running over.
The attacker can see all unprotected Babel traffic, and they can send arbitrary
payloads with spoofed source IP addresses. If you do not protect Hellos and IHUs
this attacker can pretty easily cause a DoS attack. I think this will be a common
scenario, and compromised IoT devices will likely be able to send this tampered
traffic without actually being able to DoS by jamming the 2.4/5GHz signal.

We could:
- use multicast hellos for discovery of peers and ETX
- send unicast hellos and IHUs protected
- only let the multicast hellos influence our cost to within some bounds

This allows us to fallback to solely protected traffic in the presence of an attacker.

Random thought: we could imagine a scheme where we extract keys from DTLS
that can be used to HMAC the unprotected multicast traffic, similar to RFC7298.

Bottom line: we don't need to encrypt everything, but we need a way to prevent
attackers from sending spoofed Hellos/IHUs with bad seqnos/intervals/costs
that could disrupt neighbors that have authenticated each other and exchanged keys.

I'll see how much of this I can implement in the coming week, because this is
very academic until we have bits on the wire.

David

> On Mar 10, 2018, at 06:06, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 10 Mar 2018 22:43:30 +0100

> Let's assume there's an attacker on an open Wi-Fi network Babel is
> running over.  The attacker can see all unprotected Babel traffic, and
> they can send arbitrary payloads with spoofed source IP addresses. If
> you do not protect Hellos and IHUs this attacker can pretty easily cause
> a DoS attack.

Isn't that easier to do using neighbour discovery?

I was under the impression that we're protecting against traffic
redirection and, more generally, any attack that can cross routers.  I am
pretty sure that we're not supposed to be trying to protect against
link-local DoS attacks, since that's obviously impossible in a universe
where ND is not protected.

(RFC 2461 Section 11 makes the amusing claim that "Confidentiality issues
are addressed by the IP Security Architecture and the IP Encapsulating
Security Payload documents".  Its successor, RFC 4861, weasels its way out
by merely stating that "Alternatively, IPsec can be used for IP layer
authentication".)

> I'll see how much of this I can implement in the coming week,

Please do.  I'm looking forward to having a good fight with you in London,
and unless you've implemented it yourself, the fight won't be any good.

-- Juliusz