Internet DRAFT - draft-rja-smooth-rollover
draft-rja-smooth-rollover
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]
