I believe I had brought this up before. There is a YANG keychain model (RFC
8177) that might help provide some guidance here.
But before we get there, there is one clarification. There is no
babel-security-obj any more. The current tree diagram for babel is as follows
...
+-- babel-information
+-- babel-implementation-version
+-- babel-enable
+-- router-id
+-- babel-supported-link-types
+-- self-seqno
+-- babel-metric-comp-algorithms
+-- babel-security-supported
+-- babel-hmac-enable
+-- babel-hmac-algorithms
+-- babel-dtls-enable
+-- babel-dtls-cert-types
+-- babel-stats-enable
+-- babel-stats-reset
+-- babel-constants
… with security configured by whether HMAC is enabled or not, and whether DTLS
is enabled or not. And there is no reference to a per-interface configuration.
So, currently, as defined, both HMAC and DTLS are global. Based on what I am
reading here, it appears that is not what was intended. So I will join Barbara
in saying we do not want to cause a rebellion by suggesting something totally
radical here :-)
BTW, do we want to maintain the ability to have a global config for security
such that it applies to all interfaces?
Back to the question at hand, and the guidance that the keychain model provides
for symmetric keys used by routing protocols. Again this is the YANG tree
diagram for keychains.
+--rw key-chains
+--rw key-chain* [name]
| +--rw name string
| +--rw description? string
| +--rw accept-tolerance {accept-tolerance}?
| | +--rw duration? uint32
| +--ro last-modified-timestamp? yang:date-and-time
| +--rw key* [key-id]
| +--rw key-id uint64
| +--rw lifetime
| | +--rw (lifetime)?
| | +--:(send-and-accept-lifetime)
| | | +--rw send-accept-lifetime
| | | +--rw (lifetime)?
| | | +--:(always)
| | | | +--rw always? empty
| | | +--:(start-end-time)
| | | +--rw start-date-time?
| | | | yang:date-and-time
| | | +--rw (end-time)?
| | | +--:(infinite)
| | | | +--rw no-end-time? empty
| | | +--:(duration)
| | | | +--rw duration? uint32
| | | +--:(end-date-time)
| | | +--rw end-date-time?
| | | yang:date-and-time
What this implies is that key-chains are declared globally, and each key-chain,
indexed by a name, defines a bunch of keys, referenced by a key-id, each of
which have their own lifetime, both on the send and receive side.
If the desire is to have a key per interface, that interface would then have a
reference to one of the key-chains. Ideally, a separate key rotation protocol
decides which key is used out of the chain. But since we never quite got around
to defining that protocol in KARP, each implementation is left to decide how to
pick the key. Sharing of keys between interfaces can be had by having both
interfaces refer to the same keychain.
Few things would have to happen to the existing documents in Babel. The IM
should be updated to provide a reference from the interface to the
babel-hmac-obj/babel-dtls-obj, and add a reference to a keychain instead of a
key itself. If a global security configuration is desired, where every flag
gets the same security configuration, then we will need a global flag to state
so. Secondly, in the YANG model for Babel, we augment the keychain model to
support ability to add/delete/rotate/synchronize keys separately, and update
the data model to mirror any changes we make to the IM.
Cheers.
> On Mar 12, 2019, at 5:45 AM, Toke Høiland-Jørgensen
> <[email protected]> wrote:
>
> Juliusz Chroboczek <[email protected]> writes:
>
>>> FWIW, Bird will also use the simpler mechanism (a key is part of the
>>> iface config).
>>
>> How do you share a key between interfaces?
>
> You can set them globally or per-interface (interface options in general
> are just overrides of the global per-protocol options). I'm not sure
> what happens if you set both, actually.
>
> If you want to, say, use the same key on two interfaces, but not a
> third, you'd have to copy the config line to both interface configs.
>
> There are also a bunch of per-key options, such as active times and an
> ID. See the 'password' entry here:
> https://bird.network.cz/?get_doc&v=20&f=bird-3.html#ss3.3
>
> I haven't played around with this extensively, but am planning to do
> that once I get around to updating the implementation to the latest
> version of the draft...
>
> -Toke
>
> _______________________________________________
> babel mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/babel
Mahesh Jethanandani
[email protected]
_______________________________________________
Babel-users mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
