Subject: Re: [babel] babel Digest, Vol 21, Issue 9

From: Tony Przygienda <[email-masked]>
Date: Mon, 29 May 2017 10:09:14 -0700

>
> > Network wide keys are useless.
>
> Depends on the size of the network, I guess.
>

>From experience, I would dissuade you from pursuing a "network wide-key
approach" to secure a routing protocol (in terms of node associations, i.e.
adjacencies). Routing protocol is the substrate on which very often things
like X.509 run (or Radius or any other key infra "du jour"). In case you
loose the protocol nodes due to bugs, unexpected behavior, key expiration
and so on you loose the infra and with that you may never recover the
routing since key infra cannot reach the nodes anymore ... Key
roll-over/withdrawal/repudiation are especially tricky.

 Having a distro of keys across the network to provide "path-security",
i.e. I do not only trust my neighbor but trust the whole chain an update
passed is doable but too expensive to bother for routing (well, BGP will
get there eventually I guess) and benefits from a key infra obviously or
rather cannot be run without some kind of key infra.

my 2c

--- tony

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 30 May 2017 10:28:18 +0300

Disclaimer: It has been few years since I thought about this hard :) 

On 29 May 2017, at 20.09, Tony Przygienda <[email-masked]> wrote:
> From experience, I would dissuade you from pursuing a "network wide-key approach" to secure a routing protocol (in terms of node associations, i.e. adjacencies). Routing protocol is the substrate on which very often things like X.509 run (or Radius or any other key infra "du jour"). In case you loose the protocol nodes due to bugs, unexpected behavior, key expiration and so on you loose the infra and with that you may never recover the routing since key infra cannot reach the nodes anymore ... Key roll-over/withdrawal/repudiation are especially tricky. 
> 
>  Having a distro of keys across the network to provide "path-security", i.e. I do not only trust my neighbor but trust the whole chain an update passed is doable but too expensive to bother for routing (well, BGP will get there eventually I guess) and benefits from a key infra obviously or rather cannot be run without some kind of key infra. 

From experience, if you cannot trace the attacker down (i.o.w. the state which spreads from the attacker to the whole network) and selectively ignore them, life gets hard anyway.

Looking at the solutions I have seen in the wild, roughly in order of decreasing security:

a) shared state with verifiable source (some future BGP version, hopefully); as you said, probably unrealistic unfortunately here.

b) per-hop keys but non-verifiable shared state (HNCP with DTLS, X with IKE+IPsec)

c) global key and non-verifiable shared state (HNCP provided global keys to other protocols, manually keyed IPsec, RFC7298 for Babel)

d) ignore the security.

With [a] you know who inserted the bad state. With [b-d], you do not. The difference between [b] and [c] is actually not much. You cannot trace down the source of shared state change (except very, very painfully hop by hop; you can do that in even in [d]).

Quoting Ted Lemon:

> In the case we are talking about, a shared key doesn’t work because if any device on the network is pwned, it can masquerade as any other device to escape detection.   You or I could do a fault isolation process to figure out which device has been pwned, but we can’t expect homenet users to be able to do that.

In a distance vector routing protocol, how do you determine who inserted that bad route update, regardless of whether transport keying is per-hop or network wide?

Babel solution with [a] is much more than just sticking in DTLS transport to unicast packets. Or IKE+IPsec.

You essentially need signed state updates if you want to be able to trace down bad apples, and ignore them as needed. Otherwise it becomes just a matter of trying to secure transport of the updates to some degree, and my preferences are roughly inverse to the order of security noted above;

[e] if you can secure your lower layer or trust your nodes
[b#2] IPsec if you cannot (and change protocol so it can be secure without multicast)
[c] single (or ‘few’, to account for rollover like in RFC7298) keys with simple authentication/confidentiality
[b#1] if you must stick in DTLS (configuration awkward, not that bad implementation complexity)
[a] interesting, but serious performance challenges (I did some numbers when thinking about HNCP originally, and it did not scale very well even for home network usecase).

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 May 2017 09:47:52 -0400

> With [a] you know who inserted the bad state. With [b-d], you do not. The difference between [b] and [c] is actually not much. You cannot trace down the source of shared state change (except very,…

No, you can't, because spoofing.   That's the point of [b].

> [e] if you can secure your lower layer or trust your nodes

I don't think we can do this on a homenet.   Assigning blame, we can potentially do.   Effectively controlling access, probably not.   The problem is that even if we only allow registered nodes access to layer 2, all it takes is pwning one such node, and the infection is raging uncontrolled.

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 30 May 2017 20:32:04 +0300

On 30 May 2017, at 16.47, Ted Lemon <[email-masked]> wrote:
> No, you can't, because spoofing.   That’s the point of [b].

If you require signature (with reasonable antireplay) of every update TLV (by the origin), how do you spoof it? That was the whole point of [a].

[b] is not that, [b] is just per-adjacency encryption and the content of stuff _can_ be spoofed as long as you have credential to chat up with your next adjacency.

> I don't think we can do this on a homenet.   Assigning blame, we can potentially do.   Effectively controlling access, probably not.   The problem is that even if we only allow registered nodes acc…

You get ‘infection’ regardless, unless you have e.g. strongly authenticated DHCP, DNS, NTP, and everything else.

(HNCP as specified does funny things if you pretend to be upstream, and DHCP(v6) is not authenticated.)

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 May 2017 14:37:12 -0400

> [b] is not that, [b] is just per-adjacency encryption and the content of stuff _can_ be spoofed as long as you have credential to chat up with your next adjacency.

Well, I will freely admit that I prefer [a], but I get the sense that the babel working group does not, so if all I can get is [b], I do think it's better than [c] or [d].   The point of [b] is that yes, you can chat up your neighbor, but because you have to sign your communications, your neighbor knows that it is _you_ chatting it up.

> You get ‘infection’ regardless, unless you have e.g. strongly authenticated DHCP, DNS, NTP, and everything else.

Yes.   Securing just babel isn't a complete solution.

> (HNCP as specified does funny things if you pretend to be upstream, and DHCP(v6) is not authenticated.)

We're working on that...