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]