<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I believe I had brought this up before. There is a YANG keychain model (RFC 8177) that might help provide some guidance here.<div class=""><br class=""></div><div class="">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 ...</div><div class=""><br class=""></div><div class=""><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"> +-- 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</pre><div class=""><br class=""></div></div><div class="">… 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 :-)</div><div class=""><br class=""></div><div class="">BTW, do we want to maintain the ability to have a global config for security such that it applies to all interfaces? </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"> +--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</pre><div class=""><br class=""></div></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Cheers.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 12, 2019, at 5:45 AM, Toke Høiland-Jørgensen <<a href="mailto:toke=40toke.dk@dmarc.ietf.org" class="">toke=40toke.dk@dmarc.ietf.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Juliusz Chroboczek <<a href="mailto:jch@irif.fr" class="">jch@irif.fr</a>> writes:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">FWIW, Bird will also use the simpler mechanism (a key is part of the<br class="">iface config).<br class=""></blockquote><br class="">How do you share a key between interfaces?<br class=""></blockquote><br class="">You can set them globally or per-interface (interface options in general<br class="">are just overrides of the global per-protocol options). I'm not sure<br class="">what happens if you set both, actually.<br class=""><br class="">If you want to, say, use the same key on two interfaces, but not a<br class="">third, you'd have to copy the config line to both interface configs.<br class=""><br class="">There are also a bunch of per-key options, such as active times and an<br class="">ID. See the 'password' entry here:<br class=""><a href="https://bird.network.cz/?get_doc&v=20&f=bird-3.html#ss3.3" class="">https://bird.network.cz/?get_doc&v=20&f=bird-3.html#ss3.3</a><br class=""><br class="">I haven't played around with this extensively, but am planning to do<br class="">that once I get around to updating the implementation to the latest<br class="">version of the draft...<br class=""><br class="">-Toke<br class=""><br class="">_______________________________________________<br class="">babel mailing list<br class="">babel@ietf.org<br class="">https://www.ietf.org/mailman/listinfo/babel<br class=""></div></div></blockquote></div><br class=""><div class="">
<div class="">Mahesh Jethanandani</div><div class=""><a href="mailto:mjethanandani@gmail.com" class="">mjethanandani@gmail.com</a></div><div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>