[Babel-users] [babel] HMAC routerid->key mappings?

[Juliusz Chroboczek]

> as keys (currently) protect each interface, not each router association...

Correct.  Babel uses both unicast and multicast, and Babel-HMAC is
designed so that it can protect multicast traffic while remaining immune
to replay, even in the absence of persistent state or hardware clocks.

> consider, instead a case where you are dropping a bunch of networks
> into an information interchange (call it "BIX"[1]), where a bunch of
> networks have agreed to interconnect, over a single "wire", much like
> how BGP network interchanges work today. Key exchange here, in the BGP
> world, is on a per-router, not per-interface, basis.

BGP is a unicast-only protocol, hence it can easily use per-peer keys.

> It is unwise to share one key with all interchangers. Co-ordinating a
> key rollover with that many different entities on that wire is hard.

> Using specific keys instead for each of the A-F, A-G, A-B, etc,
> associations limits the geometric growth and security vulnerabilities.

The clean solution would be to use a bunch of point-to-point interfaces,
either by replacing your switch with direct router-to-router links, or by
putting up a bunch of VLANs or GRE tunnels.  Then you can use Babel-HMAC
unmodified.

> A) while we can append quite a few HMACs in a hello, at some point,
> when an interchange's hmacs grows past the size of a packet, we run
> out of space. What happens? Can we resend that hello with even more
> HMAC's attached, and win?

Sort of.  However, if there are any plaintext routers on the same link,
they will parse both packets.  I think that Babel should deal fairly well
with packet duplication, but I'm not sure.

But at that point, you might as well use DTLS.

> So if the code (in addition to protecting interfaces) could also (or
> instead of interfaces) associate keys to routerids, we scale to this
> scenario.

I'm not going to do that, unless there are any good reasons why you don't
want to use DTLS in that case.

> 1) Use BGP instead at large interchanges

Yep.  If your routing tables are relatively stable, BGP is the right choice.

> 2) Use DTLS

Yep.  It supports per-peer keying out of the box.

> 3) Use a minimal number for all associations on an interface scaled to
> the max size of hello + ihu + hmacs

Not so keen on that -- while the protocol does in principle support
multiple HMACs, both the amount of overhead and the amount of computation
go up linearly with the number of HMACs.  It's really not designed for that.

Of course, you could envision using the unicast variant of the protocol
(the one that rejects all multicast packets except Hellos) and protect
unicast packets with HMAC instead of DTLS.  But at that point, you might
just as well use DTLS.

Quite frankly -- just use DTLS, or run HMAC over point-to-point links.

-- Juliusz