Internet Draft                                               R. Atkinson
<draft-rja-smooth-rollover-00.txt>                            Consultant
Category: Informational
Expires in 6 months                                    February 14, 2014

               Exising Practices for Smooth Key Rollover
                    with Interior Routing Protocols

                   <draft-rja-smooth-rollover-00.txt

Status of this Memo

   Distribution of this memo is unlimited.

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's
   Legal Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info)
   in effect on the date of publication of this document. Please
   review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may not be modified, and derivative works of it
   may not be created, and it may not be published except as an
   Internet-Draft.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF). Note
   that other groups may also distribute working documents as
   Internet-Drafts. The list of current Internet-Drafts is at
   http://datatracker.ietf.org/drafts/current.













   Internet-Drafts are draft documents valid for a maximum of six



Atkinson              Expires in 6 months                       [Page 1]

Internet Draft         Smooth Key Rollover  14 Feb 2014


   months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

Abstract

This document describes some existing deployed operational
practices that are in use to provide smooth key rollover for IETF
interior routing protocols (e.g. IS-IS, OSPFv2, RIPv2).  This is
intended for eventual publication as an Informational RFC on the
Independent Submission track, not via the IETF track.

Table of Contents

   1. Introduction ...........................................2
   2. Operational Context.....................................3
   3. Existing Practices for Smooth Key Rollover..............4
   4. Advice on Key Lifetime Settings.........................6
   5. Security Considerations.................................8
   6. IANA Considerations ....................................8
   7. References .............................................9


1. Introduction

   This document describes some existing deployed operational
   practices in use at present that provide smooth key rollover for
   IETF interior routing protocols (e.g. IS-IS, OSPFv2, RIPv2) when
   cryptographic authentication is deployed.

   The author does not claim that the descriptions here cover all
   possible operational practices to achieve the goal of smooth key
   rollover for IETF IGPs; no doubt other approaches also exist.

   The smooth key rollover approaches described herein only use
   existing IETF standards-track protocols and do NOT require an
   automated key management protocol.  This document, therefore,
   servces as documentation of an "existence proof" that one can
   deploy smooth key rollover without necessarily deploying an
   automated key management protocol.

   This draft does not discuss the situation where an interior
   routing protocol is protected through the use of IP Security
   mechanisms [RFC-4552].  Instead, the scope of this document is
   limited to situations where an IETF interior routing protocol
   includes integrated cryptographic protection mechanisms
   [RFC-2328] [RFC-4822] [RFC-5304] [RFC-5310] [RFC-6506] and those



Atkinson              Expires in 6 months                       [Page 2]

Internet Draft         Smooth Key Rollover  14 Feb 2014


   integrated cryptographic mechanisms are deployed (or are being
   considered for deployment) in a network.

   Feedback on this draft is very welcome.

   At this time, this document is NOT a submission to the IETF and
   also is NOT a submission or contribution to any IETF Working
   Group.

2. Operational Context

   Integrated cryptographic authentication for IETF interior routing
   protocols (IGPs), such as IS-IS, OSPF, & RIP, is not widely
   deployed at present.  Multiple router implementations support
   some form of cryptographic authentication for those IGPs.
   Anecdotal reports indicate that interoperability of different
   implementations generally is good.  Based on discussions with
   various network operators (e.g. enterprise operators, ISPs,
   content-providers), it appears that the original Keyed-MD5 or
   HMAC-MD5 approach probably remains the most widely deployed
   cryptographic authentication method for IGPs.

   In many cases, operators have indicated that this cryptographic
   authentication is NOT deployed for security or authentication
   reasons.  A common reason is simply to provide a higher quality
   integrity check than the ordinary routing protocol checksum.
   Anecdotal reports from multiple operators indicate that in recent
   years certain specific hardware components of certain routers
   were prone to erroneously modify the contents of an IGP message
   very infrequently (perhaps 1 packet out of 100,000).  None the
   less, if an IGP message were erroneously modified and the IGP
   checksum did not detect the erroneous modification, then the
   router's routing table and forwarding table entries sometimes
   could be adversely affected.  The defined cryptographic
   protection mechanisms were significantly less vulnerable to this
   operational anomaly, primarily due to the stronger integrity
   protection provided by a cryptographic hash function (versus a
   Fletcher checksum or CRC).  Once large operators became aware of
   this router hardware issue, IGP cryptographic authentication
   (especially IS-IS HMAC-MD5, as per [RFC-3567]) became much more
   widely deployed, but purely for integrity reasons (i.e. neither
   for packet origin authentication nor as protection against
   malicious packets).

   When used purely for strong integrity protection, multiple
   operators have indicated that they are not very concerned about
   either the quality of the cryptographic key used by IGP
   cryptographic authentication or the ease of changing the deployed



Atkinson              Expires in 6 months                       [Page 3]

Internet Draft         Smooth Key Rollover  14 Feb 2014


   IGP authentication key.

   So for an interesting subset of the current IGP cryptographic
   authentication deployments, multiple operators have indicated
   that key quality and smooth key rollover are not very important.

   Indeed, the original work on cryptographic authentication for
   RIPv2 [RFC-2082] and OSPFv2 [RFC-2328] had a very narrow goal,
   namely to provide protection against passive eavesdropping
   attacks (i.e., passive attacks similar to those described in
   [RFC-1704]).  At that time, many routers had very limited amounts
   of non-volatile storage, so achieving IETF consensus required
   certain specification compromises (e.g. not requiring an
   implementation to remember IGP sequence numbers across a router
   reboot).  Revisions to these specifications have addressed some
   of those limitations.

   However, the remainder of this document is focused on the other,
   possibly much smaller, subset of the IGP cryptographic
   authentication deployments.  Specifically, this document is
   focused on those operators who desire, for whatever reason, to
   periodically change their IGP authentication keys in a smooth
   manner (i.e. without disrupting the interior routing system
   operation).  The next section will describe three closely related
   methods being used at present by some network operators to
   provide regular smooth key rollover for their deployed IGP
   authentication keys.

3.0  Existing Practices for Smooth Key Rollover

   There are 3 slightly different approaches known to be in use
   today for smooth key rollover for interior routing protocols
   where cryptographic authentication has been enabled.

   The first uses vendor-specific network management applications,
   commonly called "Element Managers" that use a variety of
   on-the-wire protocols that provide configuration management for a
   set of networked switches/routers within a single operational
   domain.  These are most commonly encountered within enterprise
   networks where equipment from a single vendor constitutes the
   majority of the deployment.

   The second uses operator-specific application software, often
   developed by the operator itself, that provides configuration
   management for a set of networked switches/routers within a
   single operational domain.  Often this software supports
   equipment from multiple vendors running diverse operating
   systems.



Atkinson              Expires in 6 months                       [Page 4]

Internet Draft         Smooth Key Rollover  14 Feb 2014


   The third is a variant of the second approach, but leverages the
   IETF standards-track Network Configuration protocol (NetConf) for
   the over-the-wire configuration transfer.  NetConf provides some
   properties (e.g. atomic commit of configuration changes) that
   many operators find useful.  This approach has become more common
   as more and more vendors integrate NetConf support into their
   switches and routers.

3.1  Element Managers

   Many vendors offer "Element Manager" application software that
   can be used to monitor operational devices, manage the
   configuration of operational devices, collect network statistics
   (e.g. bandwidth used on particular network links), and perform
   other functions.  Most commonly, these vendor applications only
   support monitoring, configuration mangement, and other functions
   for devices made by that vendor.

   Element Managers from multiple vendors support the configuration
   of multiple IGP cryptographic authentication keys into devices
   (made by the same vendor as the Element Manager) within the set
   of devices whose configuration is managed via the Element Manager
   application.  By configuring the IGP cryptographic security
   association parameters (e.g. from Section D.3 of RFC-2328)
   correctly, one can arrange for automatic clock-based transition
   from one active IGP authentication key to a second IGP
   authentication key without losing any IGP messages due to
   authentication failure from an outdated key.  Section 4 provides
   advice on setting the time-focused parameters of an IGP security
   association.

3.2  Operator-specific Configuration Management Software

   Some network operators using a more varied mixture of equipment
   from multiple vendors have indicated that vendor-specific Element
   Manager applications are not practical in their environments.  No
   doubt different operators will have different perspectives.

   However, one result of that first perspective is that several
   network operators built their own automated configuration
   management system.  These often use various scripts, for example
   written in the the Tcl and Expect languages, to interact with a
   deployed devices command-line interface (CLI), often with
   product-specific or operating-system-specific software modules.
   These operator-specific applications often execute their scripts
   inside Secure Shell version 2 (SSHv2) communications session
   between the configuration management system and the device(s)
   being managed.  SSHv2 is used to provide confidentiality,



Atkinson              Expires in 6 months                       [Page 5]

Internet Draft         Smooth Key Rollover  14 Feb 2014


   authentication, integrity, and authorization for that
   communications session between the configuration management
   system and the managed device.  Reports indicate that in many
   cases a configuration management database, for example and
   open-source or commercial Structured Query Language (SQL)
   product, as part of the operator-specific solution.

   At least one network operator has reported that they use their
   configuration management system every night to verify that the
   deployed device configuration matches the intended device
   configuration (i.e., as stored in the configuration management
   database), for each managed device in their network
   infrastructure, making corrections to the configuration of each
   managed device as needed.

   Several reports indicate that these configuration management
   systems also are used for provisioning of new circuits or for
   provisioning-related reconfiguration of existing circuits.

3.3  NetConf-based Configuration Management

   This scenario is a variation on the operator-specific scenario
   described in the sub-section just above.  The primary difference
   is that the IETF Network Configuration protocol (NetConf) takes
   the place of the Expect/Tcl shell script interaction with the
   managed device's CLI.

   So in this scenario the configuration management system would use
   NetConf to interact with the managed device's NetConf service to
   read or modify the configuration of the managed device.  While in
   principle NetConf could work over more than one underlying
   communications protocol, in practice most NetConf deployments
   appear to run NetConf over SSHv2.  As in the preceding section,
   the use of SSHv2 is believed by operators to provide security,
   such as confidentiality, authentication, integrity, and
   authorisation.

   Anecdotal reports indicate that use of NetConf over SSHv2 is
   supported today in many deployed routers and switches and also
   that a growing number of network operators are using NetConf over
   SSHv2 as part of their device configuration management strategy.


4.  Advice on Key Lifetime Settings

   While an IGP Security Association contains a number of different
   variables, including the cryptographic key and cryptographic
   transform associated with a given key, the Security Association



Atkinson              Expires in 6 months                       [Page 6]

Internet Draft         Smooth Key Rollover  14 Feb 2014


   variables most critical to smooth key rollover are time related.

   As defined for OSPFv2 in RFC-2328, Section D.3 on page 230, and
   later also included in [draft-ietf-karp-crypto-key-table-10],
   there are 4 time-related parameters, which regrettably have
   different names in those 2 documents.  Of course, [RFC-6506],
   which is derived directly from RFC-2328, uses the naming and
   definitions from [RFC-2328].  These 4 variables actually are
   identical, despite the differences in naming:

   RFC-2328 Name      draft-ietf-karp-crypto-key-table-10 Name
   --------------     ----------------------------------------
   KeyStartAccept     AcceptLifeTimeStart
   KeyStartGenerate   SendLifeTimeStart
   KeyStopGenerate    SendLifeTimeEnd
   KeyStopAccept      AcceptLifeTimeEnd

   Also, while RFC-2328, Section D.3 allows these 4 values to be
   specified either in terms of seconds-since-last-reboot or in
   terms of clock time, draft-ietf-karp-crypto-key-table-10
   specifies these values in terms of Universal Coordinated Time
   (UTC).  In some communities, UTC is also known as "Zulu time" or
   "time Zulu".  Since RFC-2328 was published, it has become very
   common for deployed routers and switches to be configured as
   clients of the Network Time Protocol (NTP), which helps ensure
   that those devices have clock times that are very accurate (e.g.,
   within 1 second of each other).  So this document recommends that
   operators always configure those 4 variables using UTC, even if a
   particular routing protocol does not require use of UTC.  The use
   of Network Time Protocol by both the configuration management
   system and also by all of the managed devices is recommended.

   Quoting from RFC-2328, Section D.3, page 231:

        In order to achieve smooth key transition, KeyStartAccept
        should be less than KeyStartGenerate and KeyStopGenerate
        should be less than KeyStopAccept. If KeyStopGenerate and
        KeyStopAccept are left unspecified, the key's lifetime
        is infinite. When a new key replaces an old, the
        KeyStartGenerate time for the new key must be less than
        or equal to the KeyStopGenerate time of the old key.

   Expressed in a more mathematical syntax, the following time
   relations all must be true to achieve smooth key rollover:

     KeyStartAccept  <  KeyStartGenerate

     KeyStopGenerate <  KeyStopAccept



Atkinson              Expires in 6 months                       [Page 7]

Internet Draft         Smooth Key Rollover  14 Feb 2014


     KeyStartGenerate (new key) <= KeyStartGenerate (old key)

   Operational experience suggests that it is wise to allow for the
   possibility that one or more devices might have clocks that are
   not synchronised to the second.  So it is suggested to allow at
   least 10 minutes of difference between KeyStartAccept and
   KeyStartGenerate and also at least 10 minutes of difference
   between KeyStopGenerate and KeyStopAccept.  In some operational
   environments, especially those where clocks are at higher risk of
   skew, time differences greater than 10 minutes might be
   desirable.

   Because some implementations of interior routing protocols (IGPs)
   might have non-volatile storage for a limited number of
   cryptographic authentication keys, it is recommended that the
   configuration management system remove any expired keys that
   also no longer are in use by the managed device.

5.  Security Considerations

   This document does not create any new security considerations.

   As noted already in [RFC-2082] and [RFC-2328], if the existing IGP
   cryptographic authentication key in a router has expired, but a
   replacement key has not been configured into that router, it is
   recommended that the router continue to use the expired key until
   a new key has been configured into the router and that new key
   has become active.

   Much of this document discusses configuration management for
   cryptographic keys used by IETF interior routing protocols, which
   is inherently a security-related topic.

   Regardless of which method might be used to configure such
   cryptographic keys, it is important to provide confidentiality,
   authentication, and integrity protections to key material as it
   is created and conveyed into the running configurations of
   networked devices.  Further, such networked devices need to
   protect all cryptographic key material contained in those devices
   from unauthorised access or modification.

6.  IANA Considerations

   No actions are required from IANA as result of the publication of
   this document.  This section may be removed upon publication as
   an RFC.

7.  Acknowledgements



Atkinson              Expires in 6 months                       [Page 8]

Internet Draft         Smooth Key Rollover  14 Feb 2014


   The text of Section D.3 and Section D.4.3 of RFC-2328 was
   originally written by Fred Fred Baker and RJ Atkinson, initially
   in a separate Internet-Draft (I-D), that later was merged later
   into the I-D that became RFC-2328.  So the procedures for smooth
   key rollover, which are documented there, have been documented
   for at least 15 years.  That portion of RFC-2328 was directly
   derived from RFC-2082.

   Joel Halpern and Brian Weiss encouraged the author to write this
   draft in order to provide information for the Internet community.

   The following reviewers have provided feedback on an earlier
   version of this document (in alphabetical order):  ...tbd...

8.  References

8.1.  Normative References

     [RFC-2328] J. Moy, "OSPF Version 2", RFC-2328, April 1998.


     [RFC-4552] M. Gupta & N. Melam, "Authentication/Confidentiality
                for OSPFv3", RFC-4552, June 2006.

     [RFC-4822] R. Atkinson & M. Fanto, "RIPv2 Cryptographic
                Authentication", RFC-4822, February 2007.

     [RFC-5304] T.Li & R. Atkinson, "IS-IS Cryptographic
                Authentication", RFC-5304, October 2008.

     [RFC-5310] M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White,
                & M. Fanto, "IS-IS Generic Cryptographic
                Authentication", RFC-5310, February 2009.

     [RFC-6506] M. Bhatia, V. Manral, & A. Lindem, "Supporting
                Authentication Trailer for OSPFv3", RFC-6506,
                February 2012.

8.2.  Informative References

     [RFC-1704] N. Haller & R. Atkinson, "On Internet Authentication",
                RFC-1704, October 1994.

     [RFC-2082] F. Baker & R. Atkinson, "RIP-2 MD5 Authentication",
                RFC-2082, January 1997. (Obsoleted by RFC-4822.)

     [RFC-3567] T. Li & R. Atkinson, "Intermediate System to
                Intermediate System (IS-IS) Cryptographic



Atkinson              Expires in 6 months                       [Page 9]

Internet Draft         Smooth Key Rollover  14 Feb 2014


                Authentication", RFC-3567, July 2003.
                (Obsoleted by RFC-5304.)

Authors' Addresses

   RJ Atkinson
   Consultant
   McLean, VA, 22103
   USA

   Email: rja.lists@gmail.com








































Atkinson              Expires in 6 months                      [Page 10]