draft-ietf-karp-ops-model-10.txt   rfc7211.txt 
Network Working Group S. Hartman Internet Engineering Task Force (IETF) S. Hartman
Internet-Draft Painless Security Request for Comments: 7211 Painless Security
Intended status: Informational D. Zhang Category: Informational D. Zhang
Expires: July 13, 2014 Huawei ISSN: 2070-1721 Huawei Technologies Co. Ltd.
January 9, 2014 June 2014
Operations Model for Router Keying Operations Model for Router Keying
draft-ietf-karp-ops-model-10.txt
Abstract Abstract
The IETF is engaged in an effort to analyze security of routing The IETF is engaged in an effort to analyze the security of routing
protocol authentication according to design guidelines discussed in protocol authentication according to design guidelines discussed in
RFC 6518. Developing an operational and management model for routing RFC 6518, "Keying and Authentication for Routing Protocols (KARP)
protocol security that works with all the routing protocols will be Design Guidelines". Developing an operational and management model
critical to the deployability of these efforts. This document gives for routing protocol security that works with all the routing
recommendations to operators and implementors regarding management protocols will be critical to the deployability of these efforts.
and operation of router authentication. These recommendations will This document gives recommendations to operators and implementors
also assist protocol designers in understanding management issues regarding management and operation of router authentication. These
they will face. recommendations will also assist protocol designers in understanding
management issues they will face.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on July 13, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7211.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Breakdown of KARP configuration . . . . . . . . . . . . . . . 5 3. Breakdown of KARP Configuration . . . . . . . . . . . . . . . 3
3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6 3.1. Integrity of the Key Table . . . . . . . . . . . . . . . 5
3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6 3.2. Management of Key Table . . . . . . . . . . . . . . . . . 5
3.3. Interactions with Automated Key Management . . . . . . . . 7 3.3. Interactions with Automated Key Management . . . . . . . 6
3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 7 3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 6
4. Credentials and Authorization . . . . . . . . . . . . . . . . 8 4. Credentials and Authorization . . . . . . . . . . . . . . . . 6
4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10 4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 9
4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11 4.1.2. Key Separation and Protocol Design . . . . . . . . . 10
4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11 4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 10
4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 11
4.4. The role of Central Servers . . . . . . . . . . . . . . . 13 4.4. The Role of Central Servers . . . . . . . . . . . . . . . 12
5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14 5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 12
6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16 6. Administrator Involvement . . . . . . . . . . . . . . . . . . 14
6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16 6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 15
7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18 7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Keying and Authentication of Routing Protocols (KARP) working The Keying and Authentication of Routing Protocols (KARP) working
group is designing improvements to the cryptographic authentication group is designing improvements to the cryptographic authentication
of IETF routing protocols. These improvements include improvements of IETF routing protocols. These improvements include enhancing how
to how integrity functions are handled within each protocol as well integrity functions are handled within each protocol as well as
as designing an automated key management solution. designing an automated key management solution.
This document discusses issues to consider when thinking about the This document discusses issues to consider when thinking about the
operational and management model for KARP. Each implementation will operational and management model for KARP. Each implementation will
take its own approach to management; this is one area for vendor take its own approach to management; this is one area for vendor
differentiation. However, it is desirable to have a common baseline differentiation. However, it is desirable to have a common baseline
for the management objects allowing administrators, security for the management objects allowing administrators, security
architects and protocol designers to understand what management architects, and protocol designers to understand what management
capabilities they can depend on in heterogeneous environments. capabilities they can depend on in heterogeneous environments.
Similarly, designing and deploying the protocol will be easier with Similarly, designing and deploying the protocol will be easier when
thought paid to a common operational model. This will also help with thought is paid to a common operational model. This will also help
the design of NetConf schemas or MIBs later. This document provides with the design of NETCONF schemas or MIBs later. This document
recommendations to help establish such a baseline. provides recommendations to help establish such a baseline.
This document also gives recommendations for how management and This document also gives recommendations for how management and
operational issues can be approached as protocols are revised and as operational issues can be approached as protocols are revised and as
support is added for the key table [I-D.ietf-karp-crypto-key-table]. support is added for the key table [RFC7210].
Routing security faces interesting challenges not present with some Routing security faces interesting challenges not present with some
other security domains. routers need to function in order to other security domains. Routers need to function in order to
establish network connectivity. As a result, centralized services establish network connectivity. As a result, centralized services
cannot typically be used for authentication or other security tasks; cannot typically be used for authentication or other security tasks;
see Section 4.4. In addition, routers' roles affect how new routers see Section 4.4. In addition, routers' roles affect how new routers
are installed and how problems are handleded; see Section 6. are installed and how problems are handled; see Section 6.
2. Requirements notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Breakdown of KARP configuration 3. Breakdown of KARP Configuration
Routing authentication configuration includes configuration of key Routing authentication configuration includes configuration of key
material used to authenticate routers as well as parameters needed to material used to authenticate routers as well as parameters needed to
use these keys. Configuration also includes information necessary to use these keys. Configuration also includes information necessary to
use an automated key management protocol to configure router keying. use an automated key management protocol to configure router keying.
The key table [I-D.ietf-karp-crypto-key-table] describes The key table [RFC7210] describes configuration needed for manual
configuration needed for manual keying. Configuration of automated keying. Configuration of automated key management is a work in
key management is a work in progress. progress.
There are multiple ways of structuring configuration information. There are multiple ways of structuring configuration information.
One factor to consider is the scope of the configuration information. One factor to consider is the scope of the configuration information.
Several protocols are peer-to-peer routing protocols where a Several protocols are peer-to-peer routing protocols where a
different key could potentially be used for each neighbor. Other different key could potentially be used for each neighbor. Other
protocols require the same group key to be used for all nodes in an protocols require that the same group key be used for all nodes in an
administrative domain or routing area. In other cases, the same administrative domain or routing area. In other cases, the same
group key needs to be used for all routers on an interface, but group key needs to be used for all routers on an interface, but
different group keys can be used for each interface. different group keys can be used for each interface.
Within situations where a per-interface, per-area or per-peer key can Within situations where a per-interface, per-area, or per-peer key
be used for manually configured long-term keys, that flexibility may can be used for manually configured long-term keys, that flexibility
not be desirable from an operational standpoint. For example may not be desirable from an operational standpoint. For example,
consider OSPF [RFC2328]. Each router on an OSPF link needs to use consider OSPF [RFC2328]. Each router on an OSPF link needs to use
the same authentication configuration, including the set of keys used the same authentication configuration, including the set of keys used
for reception and the set of keys used for transmission, but may use for reception and the set of keys used for transmission, but it may
different keys for different links. The most general management use different keys for different links. The most general management
model would be to configure keys per link. However for deployments model would be to configure keys per link. However, for deployments
where the area uses the same key it would be strongly desirable to where the area uses the same key, it would be strongly desirable to
configure the key as a property of the area. If the keys are configure the key as a property of the area. If the keys are
configured per-link, they can get out of sync. In order to support configured per link, they can get out of sync. In order to support
generality of configuration and common operational situations, it generality of configuration and common operational situations, it
would be desirable to have some sort of inheritance where default would be desirable to have some sort of inheritance where default
configurations are made per-area unless overridden per-interface. configurations are made per area unless overridden per interface.
As described in [I-D.ietf-karp-crypto-key-table], the cryptographic As described in [RFC7210], the cryptographic keys are separated from
keys are separated from the interface configuration into their own the interface configuration into their own configuration store. Each
configuration store. Each routing protocol is responsible for routing protocol is responsible for defining the form of the peer
defining the form of the Peer specification used by that protocol. specification used by that protocol. Thus, each routing protocol
Thus each routing protocol needs to define the scope of keys. For needs to define the scope of keys. For group keying, the peer
group keying, the Peer specification names the group. A protocol specification names the group. A protocol could define a peer
could define a Peer specification indicating the key had a link scope specification indicating the key had a link scope and also a peer
and also a Peer specification for scoping a key to a specific area. specification for scoping a key to a specific area. For link-scoped
For link-scoped keys it is generally best to define a single Peer keys, it is generally best to define a single peer specification
specification indicating the key has a link scope and to use indicating the key has a link scope and to use interface restrictions
interface restrictions to restrict the key to the appropriate link. to restrict the key to the appropriate link.
Operational Requirements: implementations of this model MUST support Operational Requirements: implementations of this model MUST support
configuration of keys at the most general scope for the underlying configuration of keys at the most general scope for the underlying
protocol; protocols supporting per-peer keys MUST permit protocol; protocols supporting per-peer keys MUST permit
configuration of per-peer keys, protocols supporting per-interface configuration of per-peer keys, protocols supporting per-interface
keys MUST support configuration of per-interface keys, and so on for keys MUST support configuration of per-interface keys, and so on for
any additional scopes. Implementations MUST NOT permit configuration any additional scopes. Implementations MUST NOT permit configuration
of an inappropriate key scope. For example, configuration of of an inappropriate key scope. For example, configuration of
separate keys per interface would be inappropriate to support for a separate keys per interface would be inappropriate to support for a
protocol requiring per-area keys. This restriction can be enforced protocol requiring per-area keys. This restriction can be enforced
by rules specified by each routing protocol for validating key table by rules specified by each routing protocol for validating key table
entries. As such these implementation requirements are best entries. As such, these implementation requirements are best
addressed by care being taken in how routing protocols specify the addressed by care being taken in how routing protocols specify the
use of the key tables. use of the key tables.
3.1. Integrity of the Key Table 3.1. Integrity of the Key Table
The routing key table [I-D.ietf-karp-crypto-key-table] provides a The routing key table [RFC7210] provides a very general mechanism to
very general mechanism to abstract the storage of keys for routing abstract the storage of keys for routing protocols. To avoid
protocols. To avoid misconfiguration and simplify problem misconfiguration and simplify problem determination, the router MUST
determination, the router MUST verify the internal consistency of verify the internal consistency of entries added to the table.
entries added to the table. Routing protocols describe how their Routing protocols describe how their protocol interacts with the key
protocol interacts with the key table including what validation MUST table including what validation MUST be performed. At a minimum, the
be performed. At a minimum, the router MUST verify: router MUST verify:
o The cryptographic algorithms are valid for the protocol. o The cryptographic algorithms are valid for the protocol.
o The key derivation function is valid for the protocol. o The key derivation function is valid for the protocol.
o The direction is valid for the protocol; for example protocols o The direction is valid for the protocol. For example, if a
that require the same session key be used in both directions protocol requires the same session key be used in both directions,
REQUIRE have a direction of both be specified in the key table the direction field in the key table entry associated with the
entry. session key MUST be specified as "both".
o The peer specification is consistent with the protocol. o The peer specification is consistent with the protocol.
Other checks are possible. For example the router could verify that Other checks are possible. For example, the router could verify that
if a key is associated with a peer, that peer is a configured peer if a key is associated with a peer, that peer is a configured peer
for the specified protocol. However, this may be undesirable. It for the specified protocol. However, this may be undesirable. It
may be desirable to load a key table when some peers have not yet may be desirable to load a key table when some peers have not yet
been configured. Also, it may be desirable to share portions of a been configured. Also, it may be desirable to share portions of a
key table across devices even when their current configuration does key table across devices even when their current configuration does
not require an adjacency with a particular peer in the interest of not require an adjacency with a particular peer in the interest of
uniform configuration or preparing for fail-over. For these reasons, uniform configuration or preparing for fail-over. For these reasons,
these additional checks are generally undesirable. these additional checks are generally undesirable.
3.2. Management of Key Table 3.2. Management of Key Table
Several management interfaces will be quite common. For service Several management interfaces will be quite common. For service
provider deployments the configuration management system can simply provider deployments, the configuration management system can simply
update the key table. However, for smaller deployments, efficient update the key table. However, for smaller deployments, efficient
management interfaces that do not require a configuration management management interfaces that do not require a configuration management
system are important. In these environments configuration interfaces system are important. In these environments, configuration
(such as web interfaces and command-line interfaces) provided interfaces (such as web interfaces and command-line interfaces)
directly by the router will be important to easy management of the provided directly by the router will be important for easy management
router. of the router.
As part of adding a new key it is typically desirable to set an As part of adding a new key, it is typically desirable to set an
expiration time for an old key. The management interface SHOULD expiration time for an old key. The management interface SHOULD
provide a mechanism to easily update the expiration time for a provide a mechanism to easily update the expiration time for a
current key used with a given peer or interface. Also when adding a current key used with a given peer or interface. Also, when adding a
key it is desirable to push the key out to nodes that will need it, key, it is desirable to push the key out to nodes that will need it,
allowing use for receiving packets then later enabling transmit. allowing use for receiving packets and then later for enabling
This can be accomplished automatically by providing a delay between transmit. This can be accomplished automatically by providing a
when a key becomes valid for reception and transmission. However, delay between when a key becomes valid for reception and
some environments may not be able to predict when all the necessary transmission. However, some environments may not be able to predict
changes will be made. In these cases having a mechanism to enable a when all the necessary changes will be made. In these cases, having
key for sending is desirable. The management interface SHOULD a mechanism to enable a key for sending is desirable. The management
provide an easy mechanism to update the direction of an existing key interface SHOULD provide an easy mechanism to update the direction of
or to enable a disabled key. an existing key or to enable a disabled key.
Implementations SHOULD permit a configuration in which if no Implementations SHOULD permit a configuration in which if no
unexpired key is available, existing security associations continue unexpired key is available, existing security associations continue
using the expired key with which they were established. using the expired key with which they were established.
Implementations MUST support a configuration in which security Implementations MUST support a configuration in which security
associations fail if no un-expired key is available for them. See associations fail if no unexpired key is available for them. See
Section 6.2 for a discussion of reporting and managing security Section 6.2 for a discussion of reporting and managing security
faults including those related to key expiration. faults including those related to key expiration.
3.3. Interactions with Automated Key Management 3.3. Interactions with Automated Key Management
Consideration is required for how an automated key management Consideration is required for how an automated key management
protocol will assign key IDs for group keys. All members of the protocol will assign key IDs for group keys. All members of the
group may need to use the same key ID. This requires careful group may need to use the same key ID. This requires careful
coordination of global key IDs. Interactions with the peer key ID coordination of global key IDs. Interactions with the peer key ID
field may make this easier; this requires additional study. field may make this easier; this requires additional study.
Automated key management protocols also assign keys for single peers. Automated key management protocols also assign keys for single peers.
If the key ID is global and needs to be coordinated between the If the key ID is global and needs to be coordinated between the
receiver and transmitter, then there is complexity in key management receiver and transmitter, then there is complexity in key management
protocols that can be avoided if key IDs are not global. protocols that can be avoided if key IDs are not global.
3.4. Virtual Routing and Forwarding Instances (VRFs) 3.4. Virtual Routing and Forwarding Instances (VRFs)
Many core and enterprise routers support multiple routing instances. Many core and enterprise routers support multiple routing instances.
For example a router serving multiple VPNs is likely to have a For example, a router serving multiple VPNs is likely to have a
forwarding/routing instance for each of these VPNs. Each VRF will forwarding/routing instance for each of these VPNs. Each VRF will
require its own routing key table. require its own routing key table.
4. Credentials and Authorization 4. Credentials and Authorization
Several methods for authentication have been proposed for KARP. The Several methods for authentication have been proposed for KARP. The
simplest is preshared keys used directly as traffic keys. In this simplest is preshared keys used directly as traffic keys. In this
mode, the traffic integrity keys are directly configured. This is mode, the traffic integrity keys are directly configured. This is
the mode supported by most of today's routing protocols. the mode supported by most of today's routing protocols.
As discussed in [I-D.polk-saag-rtg-auth-keytable], preshared keys can As discussed in [RTG-AUTH], preshared keys can be used as the input
be used as the input to a key derivation function (KDF) to generate to a key derivation function (KDF) to generate traffic keys. For
traffic keys. For example the TCP Authentication Option (TCP-AO) example, the TCP Authentication Option (TCP-AO) [RFC5925] derives
[RFC5925] derives keys based on the initial TCP session state. keys based on the initial TCP session state. Typically, a KDF will
Typically a KDF will combine a long-term key with public inputs combine a long-term key with public inputs exchanged as part of the
exchanged as part of the protocol to form fresh session keys. A KDF protocol to form fresh session keys. A KDF could potentially be used
could potentially be used with some inputs that are configured along with some inputs that are configured along with the long-term key.
with the long-term key. Also, it's possible that inputs to a KDF Also, it's possible that inputs to a KDF will be private and
will be private and exchanged as part of the protocol, although this exchanged as part of the protocol, although this will be uncommon in
will be uncommon in KARP's uses of KDFs. KARP's uses of KDFs.
Preshared keys could also be used by an automated key management Preshared keys could also be used by an automated key management
protocol. In this mode, preshared keys would be used for protocol. In this mode, preshared keys would be used for
authentication. However traffic keys would be generated by some key authentication. However, traffic keys would be generated by some
agreement mechanism or transported in a key encryption key derived key-agreement mechanism or transported in a key encryption key
from the preshared key. This mode may provide better replay derived from the preshared key. This mode may provide better replay
protection. Also, in the absence of active attackers, key agreement protection. Also, in the absence of active attackers, key-agreement
strategies such as Diffie-Hellman can be used to produce high-quality strategies such as Diffie-Hellman can be used to produce high-quality
traffic keys even from relatively weak preshared keys. These key- traffic keys even from relatively weak preshared keys. These key-
agreement mechanisms are valuable even when active attackers are agreement mechanisms are valuable even when active attackers are
present, although an active attacker can mount a man-in-the-middle present, although an active attacker can mount a man-in-the-middle
attack if the preshared key is sufficiently weak. attack if the preshared key is sufficiently weak.
Public keys can be used for authentication within an automated key Public keys can be used for authentication within an automated key
management protocol. The design guide [I-D.ietf-karp-design-guide] management protocol. The KARP design guide [RFC6518] describes a
describes a mode in which routers have the hashes of peer routers' mode in which routers have the hashes of peer routers' public keys.
public keys. In this mode, a traditional public-key infrastructure In this mode, a traditional public-key infrastructure is not
is not required. The advantage of this mode is that a router only required. The advantage of this mode is that a router only contains
contains its own keying material, limiting the scope of a compromise. its own keying material, limiting the scope of a compromise. The
The disadvantage is that when a router is added or deleted from the disadvantage is that when a router is added or deleted from the set
set of authorized routers, all routers that peer need to be updated. of authorized routers, all routers in that set need to be updated.
Note that self-signed certificates are a common way of communicating Note that self-signed certificates are a common way of communicating
public-keys in this style of authentication. public keys in this style of authentication.
Certificates signed by a certification authority or some other PKI Certificates signed by a certification authority or some other PKI
could be used for authentication within an automated key management could be used for authentication within an automated key management
protocol. The advantage of this approach is that routers may not protocol. The advantage of this approach is that routers may not
need to be directly updated when peers are added or removed. The need to be directly updated when peers are added or removed. The
disadvantage is that more complexity and cost is required. disadvantage is that more complexity and cost are required.
Each of these approaches has a different set of management and Each of these approaches has a different set of management and
operational requirements. Key differences include how authorization operational requirements. Key differences include how authorization
is handled and how identity works. This section discusses these is handled and how identity works. This section discusses these
differences. differences.
4.1. Preshared Keys 4.1. Preshared Keys
In the protocol, manual preshared keys are either unnamed or named by In the protocol, manual preshared keys are either unnamed or named by
a small integer (typically 16 or 32 bits) key ID. Implementations a key ID (which is a small integer -- typically 16 or 32 bits).
that support multiple keys for protocols that have no names for keys Implementations that support multiple keys for protocols that have no
need to try all possible keys before deciding a packet cannot be names for keys need to try all possible keys before deciding a packet
validated [RFC4808]. Typically key IDs are names used by one group cannot be validated [RFC4808]. Typically key IDs are names used by
or peer. one group or peer.
Manual preshared keys are often known by a group of peers rather than Manual preshared keys are often known by a group of peers rather than
just one other peer. This is an interesting security property: just one other peer. This is an interesting security property:
unlike with digitally signed messages or protocols where symmetric unlike with digitally signed messages or protocols where symmetric
keys are known only to two parties, it is impossible to identify the keys are known only to two parties, it is impossible to identify the
peer sending a message cryptographically. However, it is possible to peer sending a message cryptographically. However, it is possible to
show that the sender of a message is one of the parties who knows the show that the sender of a message is one of the parties who knows the
preshared key. Within the routing threat model the peer sending a preshared key. Within the routing threat model, the peer sending a
message can be identified only because peers are trusted and thus can message can be identified only because peers are trusted and thus can
be assumed to correctly label the packets they send. This contrasts be assumed to correctly label the packets they send. This contrasts
with a protocol where cryptographic means such as digital signatures with a protocol where cryptographic means such as digital signatures
are used to verify the origin of a message. As a consequence, are used to verify the origin of a message. As a consequence,
authorization is typically based on knowing the preshared key rather authorization is typically based on knowing the preshared key rather
than on being a particular peer. Note that once an authorization than on being a particular peer. Note that once an authorization
decision is made, the peer can assert its identity; this identity is decision is made, the peer can assert its identity; this identity is
trusted just as the routing information from the peer is trusted. trusted just as the routing information from the peer is trusted.
Doing an additional check for authorization based on the identity Doing an additional check for authorization based on the identity
included in the packet would provide little value: an attacker who included in the packet would provide little value: an attacker who
somehow had the key could claim the identity of an authorized peer somehow had the key could claim the identity of an authorized peer,
and an attacker without the key should be unable to claim the and an attacker without the key should be unable to claim the
identity of any peer. Such a check is not required by the KARP identity of any peer. Such a check is not required by the KARP
threat model: inside attacks are not in scope. threat model: inside attacks are not in scope.
Preshared keys used with key derivation function similarly to manual Preshared keys used with key derivation work similarly to manual
preshared keys. However to form the actual traffic keys, session or preshared keys. However, to form the actual traffic keys, session-
peer specific information is combined with the key. From an or peer-specific information is combined with the key. From an
authorization standpoint, the derivation key works the same as a authorization standpoint, the derivation key works the same as a
manual key. An additional routing protocol step or transport step manual key. An additional routing protocol step or transport step
forms the key that is actually used. forms the key that is actually used.
Preshared keys that are used via automatic key management have not Preshared keys that are used via automatic key management have not
yet been specified for KARP although ongoing work suggests they will yet been specified for KARP, although ongoing work suggests they will
be needed. Their naming and authorization may differ from existing be needed. Their naming and authorization may differ from existing
uses of preshared keys in routing protocols. In particular, such uses of preshared keys in routing protocols. In particular, such
keys may end up being known only by two peers. Alternatively they keys may end up being known only by two peers. Alternatively, they
may also be known by a group of peers. Authorization could may also be known by a group of peers. Authorization could
potentially be based on peer identity, although it is likely that potentially be based on peer identity, although it is likely that
knowing the right key will be sufficient. There does not appear to knowing the right key will be sufficient. There does not appear to
be a compelling reason to decouple the authorization of a key for be a compelling reason to decouple the authorization of a key for
some purpose from authorization of peers holding that key to perform some purpose from the authorization of peers holding that key to
the authorized function. perform the authorized function.
4.1.1. Sharing Keys and Zones of Trust 4.1.1. Sharing Keys and Zones of Trust
Care needs to be taken when symmetric keys are used for multiple Care needs to be taken when symmetric keys are used for multiple
purposes. Consider the implications of using the same preshared key purposes. Consider the implications of using the same preshared key
for two interfaces: it becomes impossible to cryptographically for two interfaces: it becomes impossible to cryptographically
distinguish a router on one interface from a router on another distinguish a router on one interface from a router on another
interface. So, a router that is trusted to participate in a routing interface. So, a router that is trusted to participate in a routing
protocol on one interface becomes implicitly trusted for the other protocol on one interface becomes implicitly trusted for the other
interfaces that share the key. For many cases, such as link-state interfaces that share the key. For many cases, such as link-state
routers in the same routing area, there is no significant advantage routers in the same routing area, there is no significant advantage
that an attacker could gain from this trust within the KARP threat that an attacker could gain from this trust within the KARP threat
model. However, other protocols such as BGP and RIP, permit routes model. However, other protocols, such as BGP and RIP, permit routes
to be filtered across a trust boundary. For these protocols, to be filtered across a trust boundary. For these protocols,
participation in one interface might be more advantageous than participation in one interface might be more advantageous than
another. Operationally, when this trust distinction is important to another. Operationally, when this trust distinction is important to
a deployment, different keys need to be used on each side of the a deployment, different keys need to be used on each side of the
trust boundary. Key derivation can help prevent this problem in trust boundary. Key derivation can help prevent this problem in
cases of accidental misconfiguration. However, key derivation cannot cases of accidental misconfiguration. However, key derivation cannot
protect against a situation where a system was incorrectly trusted to protect against a situation where a system was incorrectly trusted to
have the key used to perform the derivation. This question of trust have the key used to perform the derivation. This question of trust
is important to the KARP threat model because it is essential to is important to the KARP threat model because it is essential to
determining whether a party is an insider for a particular routing determining whether a party is an insider for a particular routing
protocol. A customer router that is an an insider for a BGP peering protocol. A customer router that is an insider for a BGP peering
relationship with a service provider is not typically an insider when relationship with a service provider is not typically an insider when
considering the security of that service provider's IGP. Similarly, considering the security of that service provider's IGP. Similarly,
To the extent that there are multiple zones of trust and a routing to the extent that there are multiple zones of trust and a routing
protocol is determining whether a particular router is within a protocol is determining whether a particular router is within a
certain zone, the question of untrusted actors is within the scope of certain zone, the question of untrusted actors is within the scope of
the routing threat model. the routing threat model.
Key derivation can be part of a management solution to a desire to Key derivation can be part of a management solution for having
have multiple keys for different zones of trust. A master key could multiple keys for different zones of trust. A master key could be
be combined with peer, link or area identifiers to form a router- combined with peer, link, or area identifiers to form a router-
specific preshared key that is loaded onto routers. Provided that specific preshared key that is loaded onto routers. Provided that
the master key lives only on the management server and not the the master key lives only on the management server and not the
individual routers, trust is preserved. However in many cases, individual routers, trust is preserved. However, in many cases,
generating independent keys for the routers and storing the result is generating independent keys for the routers and storing the result is
more practical. If the master key were somehow compromised, all the more practical. If the master key were somehow compromised, all the
resulting keys would need to be changed. However if independent keys resulting keys would need to be changed. However, if independent
are used, the scope of a compromise may be more limited. keys are used, the scope of a compromise may be more limited.
4.1.2. Key Separation and Protocol Design 4.1.2. Key Separation and Protocol Design
More subtle problems with key separation can appear in protocol More subtle problems with key separation can appear in protocol
design. Two protocols that use the same traffic keys may work design. Two protocols that use the same traffic keys may work
together in unintended ways permitting one protocol to be used to together in unintended ways permitting one protocol to be used to
attack the other. Consider two hypothetical protocols. Protocol A attack the other. Consider two hypothetical protocols. Protocol A
starts its messages with a set of extensions that are ignored if not starts its messages with a set of extensions that are ignored if not
understood. Protocol B has a fixed header at the beginning of its understood. Protocol B has a fixed header at the beginning of its
messages but ends messages with extension information. It may be messages but ends messages with extension information. It may be
that the same message is valid both as part of protocol A and that the same message is valid both as part of protocol A and
protocol B. An attacker may be able to gain an advantage by getting a protocol B. An attacker may be able to gain an advantage by getting
router to generate this message with one protocol under situations a router to generate this message with one protocol under situations
where the other protocol would not generate the message. This where the other protocol would not generate the message. This
hypothetical example is overly simplistic; real-world attacks hypothetical example is overly simplistic; real-world attacks
exploiting key separation weaknesses tend to be complicated and exploiting key separation weaknesses tend to be complicated and
involve specific properties of the cryptographic functions involved. involve specific properties of the cryptographic functions involved.
The key point is that whenever the same key is used in multiple The key point is that whenever the same key is used in multiple
protocols, attacks may be possible. All the involved protocols need protocols, attacks may be possible. All the involved protocols need
to be analyzed to understand the scope of potential attacks. to be analyzed to understand the scope of potential attacks.
Key separation attacks interact with the KARP operational model in a Key separation attacks interact with the KARP operational model in a
number of ways. Administrators need to be aware of situations where number of ways. Administrators need to be aware of situations where
skipping to change at page 11, line 44 skipping to change at page 10, line 44
aware that administrators expect to be able to use the same preshared aware that administrators expect to be able to use the same preshared
keys in multiple contexts. As a result, we should use appropriate keys in multiple contexts. As a result, we should use appropriate
key derivation functions so that different cryptographic keys are key derivation functions so that different cryptographic keys are
used even when the same initial input key is used. used even when the same initial input key is used.
4.2. Asymmetric Keys 4.2. Asymmetric Keys
Outside of a PKI, public keys are expected to be known by the hash of Outside of a PKI, public keys are expected to be known by the hash of
a key or (potentially self-signed) certificate. The Session a key or (potentially self-signed) certificate. The Session
Description Protocol provides a standardized mechanism for naming Description Protocol provides a standardized mechanism for naming
keys (in that case certificates) based on hashes (section 5 keys (in that case, certificates) based on hashes (Section 5 of
[RFC4572]). KARP SHOULD adopt this approach or another approach [RFC4572]). KARP SHOULD adopt this approach or another approach
already standardized within the IETF rather than inventing a new already standardized within the IETF rather than inventing a new
mechanism for naming public keys. mechanism for naming public keys.
A public key is typically expected to belong to one peer. As a peer A public key is typically expected to belong to one peer. As a peer
generates new keys and retires old keys, its public key may change. generates new keys and retires old keys, its public key may change.
For this reason, from a management standpoint, peers should be For this reason, from a management standpoint, peers should be
thought of as associated with multiple public keys rather than as thought of as associated with multiple public keys rather than as
containing a single public key hash as an attribute of the peer containing a single public-key hash as an attribute of the peer
object. object.
Authorization of public keys could be done either by key hash or by Authorization of public keys could be done either by key hash or by
peer identity. Performing authorizations by peer identity should peer identity. Performing authorizations by peer identity should
make it easier to update the key of a peer without risk of losing make it easier to update the key of a peer without risk of losing
authorizations for that peer. However management interfaces need to authorizations for that peer. However, management interfaces need to
be carefully designed to avoid making this extra level of indirection be carefully designed to avoid making this extra level of indirection
complicated for operators. complicated for operators.
4.3. Public Key Infrastructure 4.3. Public Key Infrastructure
When a PKI is used, certificates are used. The certificate binds a When a PKI is used, certificates are used. The certificate binds a
key to a name of a peer. The key management protocol is responsible key to a name of a peer. The key management protocol is responsible
for exchanging certificates and validating them to a trust anchor. for exchanging certificates and validating them to a trust anchor.
Authorization needs to be done in terms of peer identities not in Authorization needs to be done in terms of peer identities not in
terms of keys. One reason for this is that when a peer changes its terms of keys. One reason for this is that when a peer changes its
key, the new certificate needs to be sufficient for authentication to key, the new certificate needs to be sufficient for authentication to
continue functioning even though the key has never been seen before. continue functioning even though the key has never been seen before.
Potentially authorization could be performed in terms of groups of Potentially, authorization could be performed in terms of groups of
peers rather than single peers. An advantage of this is that it may peers rather than single peers. An advantage of this is that it may
be possible to add a new router with no authentication related be possible to add a new router with no authentication-related
configuration of the peers of that router. For example, a domain configuration of the peers of that router. For example, a domain
could decide that any router with a particular keyPurposeID signed by could decide that any router with a particular keyPurposeID signed by
the organization's certificate authority is permitted to join the the organization's certificate authority is permitted to join the
IGP. Just as in configurations where cryptographic authentication is IGP. Just as in configurations where cryptographic authentication is
not used, automatic discovery of this router can establish not used, automatic discovery of this router can establish
appropriate adjacencies. appropriate adjacencies.
Assuming that self-signed certificates are used by routers that wish Assuming that self-signed certificates are used by routers that wish
to use public keys but that do not need a PKI, then PKI and the to use public keys but that do not need a PKI, then PKI and the
infrastructureless mode of public-key operation described in the "infrastructure-less" mode of public-key operation described in the
previous section can work well together. One router could identify previous section can work well together. One router could identify
its peers based on names and use certificate validation. Another its peers based on names and use certificate validation. Another
router could use hashes of certificates. This could be very useful router could use hashes of certificates. This could be very useful
for border routers between two organizations. Smaller organizations for border routers between two organizations. Smaller organizations
could use public keys and larger organizations could use PKI. could use public keys and larger organizations could use PKI.
A PKI has significant operational concerns including certification A PKI has significant operational concerns including certification
practices, handling revocation and operational practices around practices, handling revocation, and operational practices around
certificate validation. The Routing PKI (RPKI) has addressed these certificate validation. The Routing PKI (RPKI) has addressed these
concerns within the scope of BGP and validation of address ownership. concerns within the scope of BGP and the validation of address
Adapting these practices to routing protocol authentication is ownership. Adapting these practices to routing protocol
outside the scope of this document. authentication is outside the scope of this document.
4.4. The role of Central Servers 4.4. The Role of Central Servers
An area to explore is the role of central servers like RADIUS or An area to explore is the role of central servers like RADIUS or
directories. Routers need to securely operate in order to provide directories. Routers need to securely operate in order to provide
network routing services. Routers cannot generally contact a central network routing services. Routers cannot generally contact a central
server while establishing routing because the router might not have a server while establishing routing because the router might not have a
functioning route to the central service until after routing is functioning route to the central service until after routing is
established. As a result, a system where keys are pushed by a established. As a result, a system where keys are pushed by a
central management system is an undesirable result for router keying. central management system is an undesirable result for router keying.
However central servers may play a role in authorization and key However, central servers may play a role in authorization and key
rollover. For example a node could send a hash of a public key to a rollover. For example, a node could send a hash of a public key to a
RADIUS server. RADIUS server.
If central servers do play a role it will be critical to make sure If central servers do play a role, it will be critical to make sure
that they are not required during routine operation or a cold-start that they are not required during routine operation or a cold-start
of a network. They are more likely to play a role in enrollment of of a network. They are more likely to play a role in enrollment of
new peers or key migration/compromise. new peers or key migration/compromise.
Another area where central servers may play a role is for group key Another area where central servers may play a role is for group key
agreement. As an example, [I-D.liu-ospfv3-automated-keying-req] agreement. As an example, [OSPF-AUTO] discusses the potential need
discusses the potential need for key agreement servers in OSPF. for key-agreement servers in OSPF. Other routing protocols that use
Other routing protocols that use multicast or broadcast such as IS-IS multicast or broadcast such as IS-IS are likely to need a similar
are likely to need a similar approach. Multicast key agreement approach. Multicast key-agreement protocols need to allow operators
protocols need to allow operators to choose which key servers will to choose which key servers will generate traffic keys. The quality
generate traffic keys. The quality of random numbers [RFC4086] is of random numbers [RFC4086] is likely to differ between systems. As
likely to differ between systems. As a result, operators may have a result, operators may have preferences for where keys are
preferences for where keys are generated. generated.
5. Grouping Peers Together 5. Grouping Peers Together
One significant management consideration will be the grouping of One significant management consideration will be the grouping of
management objects necessary to determine who is authorized to act as management objects necessary to determine who is authorized to act as
a peer for a given routing action. As discussed previously, the a peer for a given routing action. As discussed previously, the
following objects are potentially required: following objects are potentially required:
o Key objects are required. Symmetric keys may be preshared and o Key objects are required. Symmetric keys may be preshared, and
knowledge of the key used as the decision factor in authorization. knowledge of the key may be used as the decision factor in
Knowledge of the private key corresponding to Asymmetric public authorization. Knowledge of the private key corresponding to
keys may be used directly for authorization as well. During key asymmetric public keys may be used directly for authorization as
transitions more than one key may refer to a given peer. Group well. During key transitions, more than one key may refer to a
preshared keys may refer to multiple peers. given peer. Group preshared keys may refer to multiple peers.
o Peer objects are required. A peer is a router that this router o Peer objects are required. A peer is a router that this router
might wish to communicate with. Peers may be identified by names might wish to communicate with. Peers may be identified by names
or keys. or keys.
o Objects representing peer groups are required. Groups of peers o Objects representing peer groups are required. Groups of peers
may be authorized for a given routing protocol. may be authorized for a given routing protocol.
Establishing a management model is difficult because of the complex Establishing a management model is difficult because of the complex
relationships between each set of objects. As discussed there may be relationships between each set of objects. As discussed, there may
more than one key for a peer. However in the preshared key case, be more than one key for a peer. However, in the preshared key case,
there may be more than one peer for a key. This is true both for there may be more than one peer for a key. This is true both for
group security association protocols such as an IGP or one-to-one group security association protocols such as an IGP or one-to-one
protocols where the same key is used administratively. In some of protocols where the same key is used administratively. In some of
these situations, it may be undesirable to explicitly enumerate the these situations, it may be undesirable to explicitly enumerate the
peers in the configuration; for example IGP peers are auto-discovered peers in the configuration; for example, IGP peers are auto-
for broadcast links but not for non-broadcast multi-access links. discovered for broadcast links but not for non-broadcast multi-access
links.
Peers may be identified either by name or key. If peers are Peers may be identified either by name or key. If peers are
identified by key it is strongly desirable from an operational identified by key, it is strongly desirable from an operational
standpoint to consider any peer identifiers or name to be a local standpoint to consider any peer identifiers or names to be a local
matter and not require the names or identifiers to be synchronized. matter and not require the identifiers or names to be synchronized.
Obviously if peers are identified by names (for example with Obviously, if peers are identified by names (for example, with
certificates in a PKI), identifiers need to be synchronized between certificates in a PKI), identifiers need to be synchronized between
the authorized peer and the peer making the authorization decision. the authorized peer and the peer making the authorization decision.
In many cases peers will explicitly be identified in routing protocol In many cases, peers will explicitly be identified in routing
configuration. In these cases it is possible to attach the protocol configuration. In these cases, it is possible to attach the
authorization information (keys or identifiers) to the peer's authorization information (keys or identifiers) to the peer's
configuration object. Two cases do not involve enumerating peers. configuration object. Two cases do not involve enumerating peers.
The first is the case where preshared keys are shared among a group The first is the case where preshared keys are shared among a group
of peers. It is likely that this case can be treated from a of peers. It is likely that this case can be treated from a
management standpoint as a single peer representing all the peers management standpoint as a single peer representing all the peers
that share the keys. The other case is one where certificates in a that share the keys. The other case is one where certificates in a
PKI are used to introduce peers to a router. In this case, rather PKI are used to introduce peers to a router. In this case, rather
than configuring peers, , the router needs to be configured with than configuring peers, the router needs to be configured with
information on which certificates represent acceptable peers. information on which certificates represent acceptable peers.
Another consideration is which routing protocols share peers. For Another consideration is which routing protocols share peers. For
example it may be common for LDP peers to also be peers of some other example, it may be common for LDP peers to also be peers of some
routing protocol. Also, RSVP-TE may be associated with some TE-based other routing protocol. Also, RSVP - Traffic Engineering (RSVP-TE)
IGP. In some of these cases it would be desirable to use the same may be associated with some TE-based IGP. In some of these cases, it
authorization information for both routing protocols. would be desirable to use the same authorization information for both
routing protocols.
Finally, as discussed in Section 7, it is sometimes desirable to Finally, as discussed in Section 7, it is sometimes desirable to
override some aspect of the configuration for a peer in a group. As override some aspect of the configuration for a peer in a group. As
an example, when rotating to a new key, it is desirable to be able to an example, when rotating to a new key, it is desirable to be able to
roll that key out to each peer that will use the key even if in the roll that key out to each peer that will use the key, even if in the
stable state the key is configured for a peer group. stable state the key is configured for a peer group.
In order to develop a management model for authorization, the working In order to develop a management model for authorization, the working
group needs to consider several questions. What protocols support group needs to consider several questions. What protocols support
auto-discovery of peers? What protocols require more configuration auto-discovery of peers? What protocols require more configuration
of a peer than simply the peer's authorization information and of a peer than simply the peer's authorization information and
network address? What management operations are going to be common network address? What management operations are going to be common
as security information for peers is configured and updated? What as security information for peers is configured and updated? What
operations will be common while performing key transitions or while operations will be common while performing key transitions or while
migrating to new security technologies? migrating to new security technologies?
skipping to change at page 16, line 15 skipping to change at page 14, line 19
6. Administrator Involvement 6. Administrator Involvement
One key operational question is what areas will administrator One key operational question is what areas will administrator
involvement be required. Likely areas where involvement may be involvement be required. Likely areas where involvement may be
useful include enrollment of new peers. Fault recovery should also useful include enrollment of new peers. Fault recovery should also
be considered. be considered.
6.1. Enrollment 6.1. Enrollment
One area where the management of routing security needs to be One area where the management of routing security needs to be
optimized is the deployment of a new router. In some cases a new optimized is the deployment of a new router. In some cases, a new
router may be deployed on an existing network where routing to router may be deployed on an existing network where routing to
management servers is already available. In other cases, routers may management servers is already available. In other cases, routers may
be deployed as part of connecting or creating a site. Here, the be deployed as part of connecting or creating a site. Here, the
router and infrastructure may not be available until the router has router and infrastructure may not be available until the router has
securely authenticated. securely authenticated.
In general, security configuration can be treated as an additional In general, security configuration can be treated as an additional
configuration item that needs to be set up to establish service. configuration item that needs to be set up to establish service.
There is no significant security value in protecting routing protocol There is no significant security value in protecting routing protocol
keys more than administrative password or Authentication, keys more than administrative password or Authentication,
Authorization and Accounting (AAA) secrets that can be used to gain Authorization, and Accounting (AAA) secrets that can be used to gain
login access to a router. These existing secrets can be used to make login access to a router. These existing secrets can be used to make
configuration changes that impact routing protocols as much as configuration changes that impact routing protocols as much as
disclosure of a routing protocol key. Operators already have disclosure of a routing protocol key. Operators already have
procedures in place for these items. So, it is appropriate to use procedures in place for these items. So, it is appropriate to use
similar procedures for routing protocol keys. It is reasonable to similar procedures for routing protocol keys. It is reasonable to
improve existing configuration procedures and the routing protocol improve existing configuration procedures and the routing protocol
procedures over time. However it is more desirable to deploy KARP procedures over time. However, it is more desirable to deploy KARP
with security similar to that used for managing existing secrets than with security similar to that used for managing existing secrets than
to delay deploying KARP. to delay deploying KARP.
Operators MAY develop higher assurance procedures for dealing with Operators MAY develop higher assurance procedures for dealing with
keys. For example, asymmetric keys can be generated on a router and keys. For example, asymmetric keys can be generated on a router and
never exported from the router. Operators can evaluate the cost vs never exported from the router. Operators can evaluate the cost vs.
security and availability tradeoffs of these procedures. security and the availability tradeoffs of these procedures.
6.2. Handling Faults 6.2. Handling Faults
Faults may interact with operational practice in at least two ways. Faults may interact with operational practice in at least two ways.
First, security solutions may introduce faults. For example if First, security solutions may introduce faults. For example, if
certificates expire in a PKI, previous adjacencies may no longer certificates expire in a PKI, previous adjacencies may no longer
form. Operational practice will require a way of repairing these form. Operational practice will require a way of repairing these
errors. This may end up being very similar to repairing other faults errors. This may end up being very similar to repairing other faults
that can partition a network. that can partition a network.
Notifications will play a critical role in avoiding security faults. Notifications will play a critical role in avoiding security faults.
Implementations SHOULD use appropriate mechanisms to notify operators Implementations SHOULD use appropriate mechanisms to notify operators
as security resources are about to expire. Notifications can include as security resources are about to expire. Notifications can include
messages to consoles, logged events, SNMP traps, or notifications messages to consoles, logged events, Simple Network Management
within a routing protocol. One strategy is to have increasing Protocol (SNMP) traps, or notifications within a routing protocol.
escalations of notifications. One strategy is to have increasing escalations of notifications.
Monitoring will also play an important role in avoiding security Monitoring will also play an important role in avoiding security
faults such as certificate expiration. Some classes of security faults such as certificate expiration. Some classes of security
fault, including issues with certificates, will affect only key fault, including issues with certificates, will affect only key
management protocols. other security faults can affect routing management protocols. Other security faults can affect routing
protocols directly. However, the protocols MUST still have adequate protocols directly. However, the protocols MUST still have adequate
operational mechanisms to recover from these situations. Also, some operational mechanisms to recover from these situations. Also, some
faults, such as those resulting from a compromise or actual attack on faults, such as those resulting from a compromise or actual attack on
a facility are inherent and may not be prevented. a facility, are inherent and may not be prevented.
A second class of faults is equipment faults that impact security. A second class of faults is equipment faults that impact security.
For example if keys are stored on a router and never exported from For example, if keys are stored on a router and never exported from
that device, failure of a router implies a need to update security that device, failure of a router implies a need to update security
provisioning on the replacement router and its peers. provisioning on the replacement router and its peers.
One approach, recommended by work on securing BGP One approach, recommended by work on securing BGP [KEYING] is to
[I-D.ietf-sidr-rtr-keying] is to maintain the router's keying maintain the router's keying material so that when a router is
material so that when a router is replaced the same keys can be used. replaced the same keys can be used. Router keys can be maintained on
Router keys can be maintained on a central server. These approaches a central server. These approaches permit the credentials of a
permit the credentials of a router to be recovered. This provides router to be recovered. This provides valuable options in case of
valuable options in case of hardware fault. The failing router can hardware fault. The failing router can be recovered without changing
be recovered without changing credentials on other routers or waiting credentials on other routers or waiting for keys to be certified.
for keys to be certified. One disadvantage of this approach is that One disadvantage of this approach is that even if public-key
even if public-key cryptography is used, the private keys are located cryptography is used, the private keys are located on more than just
on more than just the router. a system in which keys were generated the router. A system in which keys were generated on a router and
on a router and never exported from that router would typically make never exported from that router would typically make it more
it more difficult for an attacker to obtain the keys. For most difficult for an attacker to obtain the keys. For most environments,
environments the ability to quickly replace a router justifies the ability to quickly replace a router justifies maintaining keys
maintaining keys centrally. centrally.
More generally keying is another item of configuration that needs to More generally, keying is another item of configuration that needs to
be restored to restore service when equipment fails. Operators be restored to reestablish service when equipment fails. Operators
typically perform the minimal configuration necessary to get a router typically perform the minimal configuration necessary to get a router
back in contact with the management server. The same would apply for back in contact with the management server. The same would apply for
keys. Operators who do not maintain copies of key material for keys. Operators who do not maintain copies of key material for
performing key recovery on routers would need to perform a bit more performing key recovery on routers would need to perform a bit more
work to regain contact with the management server. It seems work to regain contact with the management server. It seems
reasonable to assume that management servers will be able to cause reasonable to assume that management servers will be able to cause
keys to be generated or distributed sufficiently to fully restore keys to be generated or distributed sufficiently to fully restore
service. service.
7. Upgrade Considerations 7. Upgrade Considerations
skipping to change at page 18, line 22 skipping to change at page 16, line 29
disrupting routing. Today, many operators do not update keys because disrupting routing. Today, many operators do not update keys because
the perceived risk of an attack is lower than the cost of an update the perceived risk of an attack is lower than the cost of an update
combined with the potential cost of routing disruptions during the combined with the potential cost of routing disruptions during the
update. Even when a routing protocol has technical mechanisms that update. Even when a routing protocol has technical mechanisms that
permit an update with no disruption in service, there is still a permit an update with no disruption in service, there is still a
potential cost of service disruptions as operational procedures and potential cost of service disruptions as operational procedures and
practices need to correctly use the technical mechanisms. practices need to correctly use the technical mechanisms.
For peer-to-peer protocols such as BGP, upgrading to automated key For peer-to-peer protocols such as BGP, upgrading to automated key
management can be relatively easy. First, code that supports management can be relatively easy. First, code that supports
automated key management needs to be loaded on both peers. Then the automated key management needs to be loaded on both peers. Then, the
adjacency can be upgraded. The configuration can be updated to adjacency can be upgraded. The configuration can be updated to
switch to automated key management when the second router reboots. switch to automated key management when the second router reboots.
Alternatively, if the key management protocols involved can detect Alternatively, if the key management protocols involved can detect
that both peers now support automated key management, then a key can that both peers now support automated key management, then a key can
potentially be negotiated for an existing session. potentially be negotiated for an existing session.
The situation is more complex for organizations that have not The situation is more complex for organizations that have not
upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option
[RFC5925]. Today, routers typically need to understand whether a [RFC5925]. Today, routers typically need to understand whether a
given peer supports TCP MD5 or TCP-AO before opening a TCP given peer supports TCP MD5 or TCP-AO before opening a TCP
connection. In addition, many implementations support grouping connection. In addition, many implementations support grouping
configuration of related peers including security configuration configuration (including security configuration) of related peers
together. Implementations make it challenging to move from TCP-MD5 together. Implementations make it challenging to move from TCP MD5
to TCP-AO before all peers in the group are ready. Operators to TCP-AO before all peers in the group are ready. Operators
perceive it as high risk to update the configuration of a large perceive it as high risk to update the configuration of a large
number of peers. One particularly risky situation is upgrading the number of peers. One particularly risky situation is upgrading the
configuration of iBGP peers. configuration of Internal BGP (iBGP) peers.
The situation is more complicated for multicast protocols. It's The situation is more complicated for multicast protocols. It's
typically not desirable to bring down an entire link to reconfigure typically not desirable to bring down an entire link to reconfigure
it as using automated key management. Two approaches should be it as using automated key management. Two approaches should be
considered. One is to support key table rows supporting the considered. One is to support key table rows that enable the
automated key management and manually configured keying for the same automated key management and manually configured keying for the same
link at the same time. Coordinating this may be challenging from an link at the same time. Coordinating this may be challenging from an
operational standpoint. Another possibility is for the automated key operational standpoint. Another possibility is for the automated key
management protocol to actually select the same traffic key that is management protocol to actually select the same traffic key that is
being used manually. This could be accomplished by having an option being used manually. This could be accomplished by having an option
in the key management protocol to export the current manual group key in the key management protocol to export the current manual group key
through the automated key management protocol. Then after all nodes through the automated key management protocol. Then after all nodes
are configured with automated key management, manual key entries can are configured with automated key management, manual key entries can
be removed. The next re-key after all nodes have manual entries be removed. The next re-key after all nodes have manual entries
removed will generate a new fresh key. Group key management removed will generate a new fresh key. Group key management
skipping to change at page 20, line 14 skipping to change at page 17, line 26
8. Security Considerations 8. Security Considerations
This document does not define a protocol. It does discuss the This document does not define a protocol. It does discuss the
operational and management implications of several security operational and management implications of several security
technologies. technologies.
Close synchronization of time can impact the security of routing Close synchronization of time can impact the security of routing
protocols in a number of ways. Time is used to control when keys MAY protocols in a number of ways. Time is used to control when keys MAY
begin being used and when they MUST NOT be used any longer as begin being used and when they MUST NOT be used any longer as
described in [I-D.ietf-karp-crypto-key-table]. Routers need to have described in [RFC7210]. Routers need to have tight enough time
tight enough time synchronization that receivers permit a key to be synchronization that receivers permit a key to be utilized for
utilized for validation prior to the first use of that key for validation prior to the first use of that key for generation of
generation of integrity-protected messages or availability will be integrity-protected messages; otherwise, availability will be
impacted. If time synchronization is too loose, then a key can be impacted. If time synchronization is too loose, then a key can be
used beyond its intended lifetime. The Network Time Protocol (NTP) used beyond its intended lifetime. The Network Time Protocol (NTP)
can be used to provide time synchronization. For some protocols, can be used to provide time synchronization. For some protocols,
time synchronization is also important for replay detection. time synchronization is also important for replay detection.
9. IANA Considerations 9. Acknowledgments
This document has no actions for IANA.
10. Acknowledgments
Funding for Sam Hartman's work on this memo is provided by Huawei. Funding for Sam Hartman's work on this memo is provided by Huawei.
The authors would like to thank Bill Atwood , Randy Bush, Wes George, The authors would like to thank Bill Atwood, Randy Bush, Wes George,
Gregory Lebovitz, and Russ White for valuable reviews. Gregory Lebovitz, and Russ White for valuable reviews.
11. References 10. References
11.1. Normative References
[I-D.ietf-karp-crypto-key-table] 10.1. Normative References
Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-10 (work in progress),
December 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", RFC
7210, April 2014.
[I-D.ietf-karp-design-guide] 10.2. Informative References
Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines",
draft-ietf-karp-design-guide-10 (work in progress),
December 2011.
[I-D.ietf-sidr-rtr-keying] [KEYING] Turner, S., Patel, K., and R. Bush, "Router Keying for
Turner, S., Patel, K., and R. Bush, "Router Keying for BGPsec", Work in Progress, May 2014.
BGPsec", draft-ietf-sidr-rtr-keying-04 (work in progress),
December 2013.
[I-D.liu-ospfv3-automated-keying-req] [OSPF-AUTO]
Liu, Y., "OSPFv3 Automated Group Keying Requirements", Liu, Y., "OSPFv3 Automated Group Keying Requirements",
draft-liu-ospfv3-automated-keying-req-01 (work in Work in Progress, July 2007.
progress), July 2007.
[I-D.polk-saag-rtg-auth-keytable]
Polk, T. and R. Housley, "Routing Authentication Using A
Database of Long-Lived Cryptographic Keys",
draft-polk-saag-rtg-auth-keytable-05 (work in progress),
November 2010.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC
RFC 4808, March 2007. 4808, March 2007.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518,
February 2012.
[RTG-AUTH] Polk, T. and R. Housley, "Routing Authentication Using A
Database of Long-Lived Cryptographic Keys", Work in
Progress, November 2010.
Authors' Addresses Authors' Addresses
Sam Hartman Sam Hartman
Painless Security Painless Security
Email: hartmans-ietf@mit.edu EMail: hartmans-ietf@mit.edu
Dacheng Zhang Dacheng Zhang
Huawei Huawei Technologies Co. Ltd.
Email: zhangdacheng@huawei.com EMail: zhangdacheng@huawei.com
 End of changes. 103 change blocks. 
287 lines changed or deleted 273 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/