Subject: Re: [karp] Only two lifetimes ?

From: RJ Atkinson <[email-masked]>
Date: Mon, 14 May 2012 15:42:30 -0400

Reducing the applicable lifetimes from the 4 defined in the
Key Table draft (and in standards-track IETF RFCs) at present 
to 2 creates multiple issues -- and solves no technical problems.

1) It breaks existing deployments of OSPFv2 Authentication,
   which use those lifetimes.  By itself, this is more than
   sufficient reason to retain the current approach.

2) It means that the Key Table cannot comply with the OSPFv2
   specification (e.g. RFC-2328, Appendix D.3, page 230).
   This also, by itself, is more than sufficient reason to
   retain the current approach.  OSPFv2 is widely implemented
   with these 4 lifetimes.  It even managed to get all the way
   through to full IETF Standard, which is pretty amazing, and
   also indicative of maturity of specification.

3) It is not obvious that 2 times are sufficient to enable
   smooth key rollover, for several different reasons.

   A) Clocks on routers might or might not be tightly synchronised
      in practice.  Even if intended to be tightly synchronised,
      for example via NTP, relying on milli-second accuracy would
      create a new (D)DOS attack vector (e.g. on NTP running 
      inside the routers).  In many deployments that I'm aware of,
      adjacent routers commonly have clocks a few minutes apart.

   B) Transit time between adjacent routers is not necessarily
      a few milliseconds.  Consider, for example, two routers inside 
      a single administrative domain connected via an MPLS L2 VPN.  
      Those easily could be a continent apart.  I know of such
      deployments that cross oceans today (e.g. for VM migration reasons).  
      L2 WAN VPNs are NOT uncommon in the deployed world, especially
      for distributed enterprises that use a commercial ISP for
      inter-site connectivity.  A common reason to deploy one's
      network this way is to enable VM migration between multiple
      geographically diverse data centres, but this is not the 
      only reason one might deploy one's enterprise network that way.

   C) Operationally, we know that the 4 lifetime approach in RFC-2328
      works well because multiple sites have deployed that today
      (e.g. using NetConf or Tcl/Expect/SSH to update the SAs inside 
      the routers).  By contrast, it has not been shown here that 
      a 2 lifetime approach is even sufficient, even with tightly 
      synchronised clocks.  Consider an OSPF packet that is sent just 
      before the end lifetime of a start-lifetime/stop-lifetime system.  
      That packet will arrive at the adjacent router AFTER the stop-lifetime 
      and so will be discarded as non-authentic -- potentially causing 
      routing issues and certainly delaying (re)convergence.

By contrast, keeping a 4 lifetime system is NOT an operational burden,
evidence that some sites have deployed this for OSPFv2.  Also, the
additional code required in a router or provisioning system to support
the 4 lifetime scheme is neither complex nor sophisticated, nor does
it have a large code footprint.

So there is no reason to reduce from 4 lifetimes to 2 lifetimes.

In fact, there is some operational evidence that other IGPs would 
benefit from having the same 4 lifetimes specified as part of their
Security Associations.  That would be a more promising fix.

Just to be clear, the burden of proof here is on folks advocating 2 lifetimes,
since both operational experience and existing standards-track RFCs
(e.g. RFC-2328) specify 4 lifetimes.  

Yours,

Ran