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

From: RJ Atkinson <[email-masked]>
Date: Tue, 3 Nov 2015 20:30:24 -0500

I have reviewed both the KeyTable YANG Module and the KeyChain
YANG module.  

I have been involved in IGP routing protocol authentication since 
the mid/late-1990s, including being one of the designers of OSPFv2 
Authentication (The text in RFC-2328, Appendix D.3 is why I’m mentioned 
as a contributor in that RFC).

I have both built routers/switches and worked in network engineering
at a multi-continent ISP.

1. KeyTable YANG Module

The KeyTable YANG module is fully aligned with and meets
all of the functional requirements for Security Associations
for current IETF routing protocol authentication specifications
(e.g. RIPv2, OSPFv2, OSPFv3, BGP).

The KeyTable RFC was designed by security folks who understand
the concept of Security Associations.  It could be implemented 
in several different ways in a particular system (e.g. router).

The KeyTable YANG module appears to meet all the functional needs.

2. KeyChain YANG Module

In principle, a corrected version of the KeyChain YANG module
could meet those functional requirements.  However, the current 
KeyChain YANG module (-09) appears NOT to meet those requirements.

Also, the current KeyChain YANG module (-09) [page 5 bottom and
page 6 top “send-and-accept-lifetime"] appears NOT to fully support 
Smooth Key Rollover.  

For example, smooth key rollover CANNOT -reliably- occur if the 
“accept lifetime (start time, end time)” is identical to the 
“send lifetime (start time, end time)”.  Of course, one can
get lucky.  I’d prefer that we design for reliability, rather
than hope for luck.

OSPFv2 Cryptographic Authentication (e.g., RFC-2328, Appendix D.3) 
specifies different send lifetimes and accept lifetimes because
an objective was to support Smooth Key Rollover.

The KeyChain YANG model (-09) does additionally have the concept of
distinct send lifetime and accept lifetime, but it is optional,
and specified later, with NO discussion of why separate lifetimes
for these functions is critical operationally if one wants Smooth
Key Rollover.

This module does NOT appear to meet all the functional needs
at present.  So it needs to be reworked to fully support Smooth 
Key Rollover before it ought to be considered for advancement.

3. Non-relationship of CLI to YANG

There seems to be a very widespread mis-apprehension within the
routing protocol YANG community that the YANG ought to follow
the human command-line-interface (CLI).

In fact, small operators often still manually configure their
routers/switches/other devices, in which case both NetConf
and YANG are likely not very relevant.

Larger operators (e.g. Tier-1 ISPs) generally have automated
device provisioning/configuration systems driven by software
tool chains.  A common pre-NetCOnf implementation would have
combination of Expect, Tcl, Perl, & Python scripts connected
to a back-end network configuration database, and executed 
periodically via a cron job (or equivalent).  A former employer
of mine had such a system deployed operationally over 15 years
ago.  

For this larger operator situation, there is not a particular 
advantage to closely modeling the YANG XML upon any particular CLI.  
In fact, a fresh start with a clean-sheet-of-paper design might well
(IMHO, very probably would) be advantageous for the coders building 
and maintaining these automated configuration/provisioning management 
systems.

Summary:

- Smooth Key Rollover is a critical operational capability.
- KeyTable YANG module is ready now because it meets all 
  functional requirements.
- KeyChain YANG module needs to be reworked before it can
  meet all functional requirements.  For example, at present
  it does not fully meet functional requirements to reliably
  achieve Smooth Key Rollover.

Yours,

Ran