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