Subject: [babel] DTLS and handshake failure

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 23 Feb 2018 19:28:07 +0100

David,

What shall we do if the DTLS handshake fails?  We switch to unauthentified
operation for this particular neighbour, we drop the neighbour, or we
blacklist the neighbour for a couple of minutes?

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Fri, 23 Feb 2018 11:24:59 -0800

Falling back to unauthenticated operation would allow for downgrade attacks,
so I'd strongly recommend against that. I'd recommend retrying with an
exponential back-off?

David

> On Feb 23, 2018, at 10:28, Juliusz Chroboczek <[email-masked]> wrote:
> 
> David,
>

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 23 Feb 2018 22:18:50 +0200

> blacklist the neighbour for a couple of minutes?

This is a matter of policy, but if third party can force DTLS handshake failure, switch to unauthenticated operation basically means you can (potentially) always force unathenticated mode.

In general allowing anything weaker than acceptable level of security is usually not good idea (c.f. historic ciphersuites in relatively modern browsers due to legacy, cough), but basically if I have configured something to use DTLS, having it not use it is a bug and not a feature.

Probably just fixed (and relatively long, e.g. 10 minutes or something) blacklist period is what I would use, as e.g. exponential backoff will also have issues (problems of defining acceptable minimum/maximum window mainly; if it is too long, user cannot ‘fix’ things in reasonable timeframe either, and if too short, it won’t help).

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 24 Feb 2018 00:49:55 +0100

> This is a matter of policy, but if third party can force DTLS handshake
> failure, switch to unauthenticated operation basically means you can
> (potentially) always force unathenticated mode.

I'm not a specialist, but I don't think we're vulnerable.
 
There's two different policies: what you do on reception, and what you do
on emission.

What you do on reception is clear: if an interface has been configured to
requre authentication, we ignore all unauthenticated TLVs except Hellos.
No exceptions of any kind.

The question is -- what do we send.  If the DTLS handshake succeeded, we
send all unicast TLVs authenticated except for Hellos.  If the DTLS
handshake failed, we can:

  - send all TLVs in clear, in case the peer is configured without auth;
  - drop the neighbour association, which will cause the next Hello to
    trigger a new handshake attempt;
  - blacklist the neighbour, so that another Hello will not trigger a new
    handshake attempt.

As far as I can tell, the three options are equivalent from a security
perspective when all routers are configured correctly, since we still
ignore any unauthentified TLVs.  They do differ when some routers are
mis-configured, and they don't generate the same amount of traffic.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Fri, 23 Feb 2018 16:51:52 -0800

If I understand this correctly, the only benefit of sending TLVs in the clear
is to interoperate with devices that have not been configured with the
proper authentication. However that won't work, since because they do
not have a way to authenticate, all their TLVs will be unauthenticated
so we will drop of all them (except Hellos) so we will drop their IHU,
so we will never establish bidirectional reachability.

That said, by design we do not want to interoperate with nodes that do
not have the proper authentication, so sending these TLVs in the clear
leaks information without providing benefit.

Having each Hello trigger a handshake attempt would work but can
generate useless traffic. Blacklisting the device for a given period of time
sounds like the best way to limit this traffic.

I would argue that such blacklisting is a local implementation matter,
but that it perhaps should have an upper bound such as 10 minutes to allow
a device to recover when it's provisioned with new authentication credentials.

David

> On Feb 23, 2018, at 15:49, Juliusz Chroboczek <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Feb 2018 19:55:46 -0500

> a device to recover when it's provisioned with new authentication credentials.

Beware of the case where the "configuring authentication" and "starting babel" processes start at the same time.   Ten minutes is a long time on a home network.   The customer is probably already on the phone with the manufacturer when it heals.   :)

---

From: David Schinazi <[email-masked]>
Date: Fri, 23 Feb 2018 16:58:10 -0800

True, but a device configured for homenet use should not be sending Babel Hellos
before it has received the network configuration - as it has no way of authenticating
what it receives.

David

> On Feb 23, 2018, at 16:55, Ted Lemon <[email-masked]> wrote:
> 
> On Feb 23, 2018, at 7:51 PM, David Schinazi <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Feb 2018 20:06:37 -0500

> before it has received the network configuration - as it has no way of authenticating

Is this captured in the Homenet Babel protocol doc?   :)

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 24 Feb 2018 05:23:41 +0200

>  - send all TLVs in clear, in case the peer is configured without auth;

This is somewhat problematic as then it can be potentially forced to do this with creative shenaginans (forged packets etc), leaking the information. However, if this configuration is just a corner case that is allowed for to allow non-DTLS interoperability I suppose it is fine. 

>    trigger a new handshake attempt;

This s problematic as if the network has one ‘legacy’ node, it will cause frequent handshakes (and also is potentially highly DoSable if one really cares about such things as DTLS sessions consume both CPU and memory).

>  - blacklist the neighbour, so that another Hello will not trigger a new

I would probably add per-neighbor blacklist and total DTLS concurrent handshake limit per time window for whole device, as you will otherwise wind up running out of resources anyway (IPv6 has plenty of addresses).

I am not sure how much of this should be in spec and how much is implementation matter though.

> mis-configured, and they don't generate the same amount of traffic.

Depends on the perspective you define :-) First one can be made leak information but if it is just configuration knob to enable I suppose it should be fine; second one is bit vulnerable in terms of resource exhaustion attacks.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 24 Feb 2018 12:16:32 +0100

> True, but a device configured for homenet use should not be sending
> Babel Hellos before it has received the network configuration - as it
> has no way of authenticating what it receives.

Not necessarily.  If a device has statically configured interfaces, it is
perfectly permissible to start helloing before HNCP has converged.  In
particular, with shncpd you start babeld and shncpd simultaneously, and
they deal with any configuration changes.

(That's a little more difficult with border border detection, since you
cannot speak Babel on an interface before you've determined its type.
I don't care, since I happen to think that border detection is unreliable
and insecure, and configure all of my routers with static interface types.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 24 Feb 2018 12:26:57 +0100

> a device to recover when it's provisioned with new authentication credentials.

I think Ted is right, David -- making a node unreachable for 10 minutes
after it failed a DTLS handshake is a bad idea.  Older versions of babeld
used to keep a silent time of 100 seconds at startup (since they lost
their loop-avoidance state), and users complained.

A possibility I didn't consider is to augment Hellos with a mandatory
sub-TLV that indicates that authentication is required.  This way the node
will not be discover routers running without auth, and, conversely, it
won't be discovered by such routers.  Perhaps that's overkill, though.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sat, 24 Feb 2018 16:06:18 +0100

> won't be discovered by such routers.  Perhaps that's overkill, though.

Couldn't you just make the blacklist duration exponentially increasing
up to a maximum? Start with 1 second, then go up until you hit the 10
minute mark? That would handle the "HNCP has not converged yet" failure
mode without risking the human users timing out and calling support...

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Sat, 24 Feb 2018 10:41:37 -0500

> mode without risking the human users timing out and calling support...

When coming up with the number "10 minutes," it might be worth asking what the failure mode is that we're trying to avoid.   Is it really so expensive to deal with these handshakes that we have to limit them this much?   Why is 10 minutes a better number than 10 seconds?