Re: [babel] [Babel-users] HMAC Key rotation key format (was ripemd)

Maybe I'm misunderstanding, but I think this issue is not comparable to
DNSSEC. The key difference here (no pun intended) is that you can operate
Babel-HMAC with multiple keys at the same time. So your rollover becomes a
simple two step process:
0) all routers are functioning with OLD_KEY configured
1) go into all routers one by one and configure them to use both OLD_KEY
and NEW_KEY
2) go into all routers one by one and configure them to only use NEW_KEY
3) profit

You don't need any notion of time, or any added complexity to the spec.

If some of the routers are down during step (1), you get to decide whether
to either wait for them to come back, or skip them and effectively
disconnect them from the network based on the urgency of your key rollover.
Anything beyond that becomes a key management problem that is specific to
your deployment, not to the routing protocol you use.

On Mon, Nov 26, 2018 at 2:22 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Dave Taht <dave.taht@gmail.com> writes:
>
> > On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
> >>
> >> Dave Taht <dave.taht@gmail.com> writes:
> >>
> >> > To me this leaves the biggest problem remaining is key rotation. Me
> >> > being me, and remembering just how hard it was to get dnssec working
> >> > on systems lacking reliable time,
> >>
> >> The Babel HMAC extension as currently specified does not rely on wall
> >> clock time in any way, so not really sure how a comparison to dnssec is
> >> relevant?
> >
> > More below. Relative time is ok, too. 3000 seconds from now, start
> > rolling over. Stop signing records with the old key as soon as
> > everyone you can currently hear uses the new key, 6000 seconds from
> > now, retire the old key unconditionally.
>
> Well, you would handle this by whatever mechanism you use to configure
> your routers in the first place...
>
> >> > Setting that aside for the moment, having a standardized file format
> >> > for babel keys would be a boon and boost interoperability between
> >> > bird/babel and other possible implementations.
> >>
> >> From the point of view of each routing daemon this would just make Babel
> >> a special snowflake.
> >
> > ok. That leaves how to get new keys into nodes running different
> > daemons. Anyone for IKEv2?
> >
> > My out of bound way is via scp and ssh.
>
> I think Juliusz' insistence that we shouldn't reinvent key distribution
> is wise. See above; you need to configure the daemons in the first place
> anyway...
>
> > Also the present babeld cannot rewrite it's entire config file (so far
> > as I know). I think bird can...
>
>
> Yup, a 'bird reconfigure' will re-read the entire config file and apply
> it if it parses successfully.
>
> > but I don't trust it.
>
> Your trust issues are probably best resolved between you and your daemon ;)
>
> >> What we can do is to specify the format in the information model if a
> >> cross-implementation format is really needed (which I'm not really
> >> convinced of, either)...
> >
> > To quote from appendix A:
> >
> > "In order to perform key rotation, the new key is added to all the
> > nodes; once this is done, both the old and the new key are sent in all
> > packets, and packets are accepted if they are properly signed by
> > either of the keys. At that point, the old key is removed."
> >
> > My key points made here are "the new key is added to *all* the
> > nodes"... which may or may not be up over the course of days, or weeks
> > for whatever definition of "all" you have ... "Once this is done" -
> > how can you tell? -  "and packets are accepted if they are properly
> > signed by either of the keys" hopefully you log this ... "the old key
> > is removed".
> >
> > perhaps "deprecated, no longer actively used for signing, then removed
> > after a suitable period"?
>
> Hmm, having a way to mark a key as "verify only" may be useful for
> simpler monitoring. But really, you *could* derive the same information
> from the opposite bit (track how many neighbours don't sign with the new
> key yet). So then it becomes more of an efficiency issue (you could save
> one signature on the wire during rotation). Not sure if it's worth
> specifying another bit in the spec for this? Or if such a configuration
> mode should even be in the spec at all?
>
> > So, if you do a key rotation and X routers are offline or inaccessible
> > at that particular time... they are going to stay inaccessible
> > forevermore, unless rekey'd via sneakernet, climbing on trees, and
> > other forms of manual intervention.
>
> Presumably your key rotation policy would take into account the outage
> schedules of the routers in your network? :)
>
> -Toke
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users