Subject: Re: [saag] advice on key table YANG module

From: Stephen Farrell <[email-masked]>
Date: Mon, 26 Oct 2015 21:28:47 +0000

Hi all,

If folks have input to offer on this one I'm sure the authors
would appreciate that.

Thanks,
S.

On 15/10/15 18:03, Ing-Wher Chen wrote:
> Dear Security ADs,
> 
> Currently, RTGWG is trying to define a key management YANG module.
> There are two competing key management YANG modules, one organizes
> keys into key chains [1], and the other organizes keys as a key table
> [2] based on RFC 7210 [3].  Several implementations take the first
> approach, the key chain approach, and they were developed long before
> the publication of RFC 7210.
> 
> I was wondering if there is a need to continue both key-chain and
> key-table YANG modules in parallel?  More specifically, is there a
> need to continue to work on the key-table YANG module?
> 
> Thanks, Helen
> 
> [1]
> <https://datatracker.ietf.org/doc/draft-acee-rtg-yang-key-chain/>
> 
> [2]
> <http://datatracker.ietf.org/doc/draft-chen-rtgwg-key-table-yang/>
> 
> [3] <https://tools.ietf.org/html/rfc7210>
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Oct 2015 17:32:06 -0400

I'd be willing to hel with the work related to RFC 7210 if that is the one that will move forward.

Russ

On Oct 26, 2015, at 5:28 PM, Stephen Farrell wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Ing-Wher Chen <[email-masked]>
Date: Tue, 27 Oct 2015 14:30:30 +0000

Thanks in advance, Russ.

In terms of which version will/should move forward, here's a little more background and some questions for the SAAG mailing list.

The two YANG modules are key-chain [1] (based on existing implementations) and key-table [2] (based on RFC 7210 [3]).  The two are not identical, but they have the same purpose---to manage routing protocol keys, and so only one is necessary.  I'd like some feedback from the mailing list for the following questions:

Does the security community care how the keys are managed?
Is there a technical reason for keys to be managed and configured exactly as described in RFC 7210?

If there is a reason, I'll continue to work on key-table YANG module to address the concerns that came up a few months ago and try to make another argument for choosing key-table.  (I have an update that attempts to address some of those concerns, but I haven't submitted it because I'm not sure if it's necessary.)

There's a lot of interest in key-chain because there are existing implementations, although all of the implementations date from before the publication of RFC 7210.  (This is just my opinion, but because of the existing implementations, key-chain is unlikely to be dropped, unless there's a compelling reason to drop it.)  If the current thinking is that key-chain is also a reasonable approach to manage keys and is equivalent to key-table, then it is easier to just improve and standardize key-chain.

[1] <https://datatracker.ietf.org/doc/draft-acee-rtg-yang-key-chain/>
[2] <http://datatracker.ietf.org/doc/draft-chen-rtgwg-key-table-yang/>
[3] <https://tools.ietf.org/html/rfc7210>

Thanks,
Helen

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Monday, October 26, 2015 5:32 PM
> To: Stephen Farrell; Kathleen Moriarty
> Cc: Ing-Wher Chen; IETF SAAG; Alvaro Retana; Deborah Brungard; Alia Atlas
> Subject: Re: [saag] advice on key table YANG module
> 
> > If folks have input to offer on this one I'm sure the authors would
> > appreciate that.
> >
> > Thanks,
> > S.
> >