RFC 7211

Operations Model for Router Keying

📅 published June 2014, from ietf

Operations Model for Router Keying 🎀

Okay bestie, first the title block, because it has the important facts 💅 This is RFC 7211, titled Operations Model for Router Keying. It's from the Internet Engineering Task Force (IETF) and was written by S. Hartman of Painless Security and D. Zhang of Huawei Technologies Co. Ltd. It's Informational, so it's published for information and isn't an Internet Standards Track spec. It's dated June 2014 and has ISSN 2070-1721. It doesn't obsolete or update any other RFCs 🦋

Abstract ✨

Okay so the IETF is working on checking how secure routing protocol authentication is, using the design guidelines in RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines". Here's the thing: building an operational and management model that works with all the routing protocols is going to be critical for these efforts to actually get deployed 😭 This document gives recommendations to operators and implementors about managing and running router authentication. It also helps protocol designers see the management issues they're going to run into 🧚

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published for informational purposes.

It's a product of the IETF, it reflects the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. Not every IESG-approved document is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the full story.

For info on the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7211.

Copyright Notice 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for 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 they're 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

1. Introduction 💖

The Keying and Authentication of Routing Protocols (KARP) working group is improving the cryptographic authentication of IETF routing protocols. These improvements include making integrity functions better handled inside each protocol, plus designing an automated key management solution. Iconic work 🔥

This document talks about the issues to think about when you're building the operational and management model for KARP. Every implementation gets to take its own approach to management, and that's one area where vendors can stand out ✨ Still, it's really desirable to have a common baseline for management objects, so administrators, security architects, and protocol designers can know which management capabilities they can count on across mixed environments. Designing and deploying the protocol is also easier when everyone's thinking about a shared operational model. This will help later when NETCONF schemas or MIBs get written. This document gives recommendations to help set up that baseline 🫶

It also gives recommendations on how management and operational issues can be handled as protocols get revised and as support gets added for the key table [RFC7210].

Routing security has challenges that some other security domains don't have. Routers need to be working in order to set up network connectivity. Because of that, centralized services typically can't be used for authentication or other security tasks; see Section 4.4. On top of that, a router's role affects how new routers get installed and how problems get 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 config covers the key material used to authenticate routers, plus the parameters needed to use those keys. It also includes the info needed to use an automated key management protocol to set up router keying. The key table [RFC7210] describes the config needed for manual keying. Config for automated key management is still a work in progress 🚧

There are a bunch of ways to structure configuration info. One big factor is the scope of the config. Several protocols are peer-to-peer routing protocols, where a different key could potentially be used for each neighbor. Other protocols require the same group key for all nodes in an administrative domain or routing area. In other cases, the same group key has to be used for all routers on an interface, but each interface can use a different group key 🌈

When a per-interface, per-area, or per-peer key can be used for manually configured long-term keys, that flexibility may not actually be desirable operationally. Take OSPF [RFC2328] as an example. Every router on an OSPF link needs to use the same authentication config, including the set of keys for reception and the set of keys for transmission. It can still use different keys for different links. The most general management model would be to configure keys per link. But when the area uses the same key, it's strongly desirable to configure the key as a property of the area instead. If keys are configured per link, they can get out of sync 😭 To support general config and common operational situations, it would be desirable to have some kind of inheritance, where default configs are set per area unless they're overridden per interface 💅

As described in [RFC7210], the cryptographic keys are separated from the interface configuration and live in their own config store. Each routing protocol is responsible for defining the form of the peer specification it uses. That means each routing protocol needs to define the scope of its keys. For group keying, the peer specification names the group. A protocol could define a peer specification that says the key has a link scope, plus a separate peer specification for scoping a key to a specific area. For link-scoped keys, it's generally best to define a single peer specification saying the key has a link scope, and then use interface restrictions to limit the key to the right 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, configuring separate keys per interface would be inappropriate for a protocol that requires per-area keys. This restriction can be enforced by rules each routing protocol specifies for validating key table entries. So these implementation requirements are best addressed by taking care in how routing protocols specify their use of the key tables 🙈

3.1. Integrity of the Key Table 🔐

The routing key table [RFC7210] provides a very general mechanism for abstracting how keys get stored for routing protocols. To avoid misconfiguration and make problem determination simpler, the router MUST verify the internal consistency of entries added to the table. Routing protocols describe how they interact with the key table, including what validation MUST be performed. At a minimum, the router MUST verify:

The cryptographic algorithms are valid for the protocol.
The key derivation function is valid for the protocol.
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 that session key MUST be specified as "both".
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 haven't been configured yet. It may also be desirable to share portions of a key table across devices even when their current config doesn't require an adjacency with a particular peer, for uniform config or to prepare for fail-over. For these reasons, these additional checks are generally undesirable 💜

3.2. Management of Key Table ✨

okay so, management interfaces are gonna be super common 💅 For service provider deployments, the configuration management system can just update the key table, easy. But for smaller deployments? Efficient management interfaces that don't need a configuration management system are a big deal 🎀 In those setups, config interfaces built right into the router (like web interfaces and command-line interfaces) are gonna be key for managing the router without the drama 🫶

When you add a new key, it's typically desirable to set an expiration time for the old one 🍓 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 you add a key, it's desirable to push it out to the nodes that will need it, so they can use it for receiving packets first and then later for enabling transmit 🦋 This can happen automatically by putting a delay between when a key becomes valid for reception and when it becomes valid for transmission. However, some environments can't predict when all the necessary changes will get made 😭 In those cases, having a way 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 keep using the expired key they were established with. 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 💀 It's a whole vibe, trust.

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, which means you need really careful coordination of global key IDs. Interactions with the peer key ID field might make this easier, but 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's extra complexity in key management protocols that can be avoided if key IDs are not global. So, lowkey, not making them global is the move 🌸

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 those VPNs. Each VRF will require its own routing key table. Separate tables, separate lives 💜

4. Credentials and Authorization ✨

Several methods for authentication have been proposed for KARP. The simplest one 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, so it's giving classic 🎀

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 combines 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. It's also 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 is that a router only contains its own keying material, which limits the scope of a compromise. The disadvantage is that when a router is added to 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 here 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. The key differences include how authorization is handled and how identity works. This section discusses these differences 🦋

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 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 can thus 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, and 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, because 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 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. Honestly, that's a very reasonable take 💖

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's no significant advantage 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 matters 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's 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 on 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. If independent keys are used, though, the scope of a compromise may be more limited 🔐✨

4.1.2. Key Separation and Protocol Design ✨

okay so this one is sneaky 🙈 Two protocols that use the same traffic keys can end up working together in ways nobody planned, and that lets one protocol be used to attack the other 💀 Picture two made-up protocols. Protocol A starts its messages with a bunch of extensions that get ignored if you don't understand them. Protocol B has a fixed header at the front but ends its messages with extension info. The same message could be totally valid for both, and an attacker might trick a router into generating that message under conditions where only one protocol would normally produce it. Iconic villain behavior, honestly 😤 This example is super simplified, and real attacks on key separation weaknesses get way more complicated and depend on the specific properties of the cryptographic functions involved. The big takeaway is that whenever the same key is used in multiple protocols, attacks might be possible. So every protocol involved needs to be analyzed to understand how much damage could happen 🫶

Key separation attacks also show up in the KARP operational model in a bunch of ways. Administrators need to know when using the same manual traffic key with two different protocols (or the same protocol in different contexts) opens up attack opportunities 🎀 Design teams should think about how their protocol might interact with other routing protocols, and they should describe any attacks they find so admins can understand what it means for operations 💅 When we design automated key management or new cryptographic authentication for routing protocols, we have to remember that admins expect to reuse the same preshared keys in multiple contexts. So we should use appropriate key derivation functions, which means different cryptographic keys get used even when the same starting input key shows up 🔐✨

4.2. Asymmetric Keys

okay public keys! 🦋 Outside of a PKI, public keys are expected to be known by the hash of a key or by a (potentially self-signed) certificate. The Session Description Protocol already has a standardized way of naming keys (certificates, in that case) using hashes, which is in Section 5 of [RFC4572] 🌸 KARP SHOULD adopt this approach or some other approach already standardized within the IETF, instead of inventing a brand new mechanism for naming public keys. Why reinvent the wheel when the wheel is already slay? 💖

A public key is typically expected to belong to one peer. As a peer generates new keys and retires old ones, its public key may change 🔄 So from a management standpoint, peers should be thought of as being associated with multiple public keys, not as having a single public-key hash stored as an attribute of the peer object. Main character energy for peers means they can have a whole rotation of keys 💜

Authorization of public keys could be done either by key hash or by peer identity. Doing authorizations by peer identity should make it easier to update a peer's key without risking the loss of that peer's authorizations 🧚 That said, management interfaces need to be carefully designed so this extra layer of indirection doesn't get complicated for operators 🙏

4.3. Public Key Infrastructure

when there's a PKI, certificates are the way to go 🎀 The certificate binds a key to a peer's name. The key management protocol is responsible for exchanging certificates and validating them back to a trust anchor 🫡

Authorization needs to be done in terms of peer identities, not in terms of keys. The reason is that when a peer changes its key, the new certificate has to be enough for authentication to keep working, even though that key has never been seen before 🔑

Authorization could also potentially be done in terms of groups of peers instead of single peers. The upside is that it may be possible to add a new router without any authentication-related configuration on 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 allowed to join the IGP. Just like in setups where cryptographic authentication isn't used, automatic discovery of that router can establish the right adjacencies 🤩

Assuming routers that want to use public keys but don't need a PKI use self-signed certificates, then PKI and the "infrastructure-less" mode of public-key operation from the previous section can work really well together 🌈 One router could identify its peers by name and use certificate validation. Another router could use hashes of certificates. This could be super useful for border routers between two organizations. Smaller organizations could use public keys, and larger organizations could use PKI 🍓

A PKI does come with real operational concerns, including certification practices, handling revocation, and operational practices around certificate validation 😭 The Routing PKI (RPKI) has tackled 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, so that's a story for another day 📖

4.4. The Role of Central Servers

okay so central servers like RADIUS or directories are something to explore 👀 Routers need to operate securely in order to provide network routing services. But routers generally can't contact a central server while they're establishing routing, because the router might not have a working route to that service until after routing is already up 😵 So a system where keys get pushed down from a central management system is an undesirable result for router keying 🙅‍♀️ That said, central servers may still 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 they aren't required during routine operation or a cold-start of the network 🚨 They're more likely to help with enrollment of new peers or with key migration and compromise situations 🛟

Another area where central servers may play a role is 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 let operators choose which key servers will generate traffic keys. The quality of random numbers [RFC4086] is likely to differ between systems, so operators may have preferences about where keys get generated 🎲✨

5. Grouping Peers Together

one big management consideration is grouping the management objects needed to figure out who is authorized to act as a peer for a given routing action 🫧 As discussed previously, the following objects are potentially required:

Key objects are required. Symmetric keys may be preshared, and knowing 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 too. During key transitions, more than one key may refer to a given peer. Group preshared keys may refer to multiple peers 🔑
Peer objects are required. A peer is a router that this router might want to communicate with. Peers may be identified by names or by keys 👯
Objects representing peer groups are required. Groups of peers may be authorized for a given routing protocol 🫂

Building a management model is hard because of the complicated 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 like an IGP and for one-to-one protocols where the same key gets used administratively. In some of these situations it may be undesirable to explicitly list every peer 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 by key. If peers are identified by key, it's strongly desirable from an operational standpoint to treat any peer identifiers or names as a local matter, so they don't have to be synchronized 🙌 Obviously, if peers are identified by names (for example, with certificates in a PKI), identifiers do need to be synchronized between the authorized peer and the peer making the authorization decision 📝

In a lot of cases, peers will be explicitly identified in routing protocol configuration. In those cases, it's possible to attach the authorization information (keys or identifiers) to the peer's configuration object 🗂️ Two cases don't involve listing peers. The first is when preshared keys are shared among a group of peers. From a management standpoint, this case can probably be treated as a single peer representing all the peers that share the keys. The other case is when certificates in a PKI are used to introduce peers to a router. Here, instead of configuring peers, the router needs to be configured with information about 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's 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's desirable to be able to roll that key out to each peer that will use it, even if in the stable state the key is configured for a peer group 🔄

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 just its authorization information and 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

okay last section of this part! 🎬 One key operational question is which areas will need administrator involvement. Likely areas where involvement may be useful include enrollment of new peers 🙋‍♀️ Fault recovery should also be considered 🛠️✨

6.1. Enrollment ✨

Okay so deploying a new router is where routing security needs the biggest glow-up 💅. Sometimes the router shows up on a network where management servers are already reachable. Other times routers come along with connecting or building a site, and the router and its infrastructure might not be reachable until the router has securely authenticated 🔐.

Security config is basically just one more config item you need before service can start 🧚. Protecting routing protocol keys isn't more valuable than admin passwords or AAA secrets that can log you into a router 🙈. Those can mess with routing just as much as a leaked routing protocol key can. Operators already have procedures for them, so it makes sense to reuse similar ones for routing keys. Improving config and routing procedures over time is totally reasonable, but deploying KARP with security similar to how existing secrets are handled is more desirable than waiting around to deploy 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 it 🔒. Operators can weigh the cost vs. security and availability tradeoffs of these procedures.

6.2. Handling Faults

Faults can interact with operational practice in at least two ways 💀. First, security solutions can introduce faults themselves. If certificates expire in a PKI, for example, previous adjacencies may no longer form. Operational practice will need a way to repair these errors, and that might end up looking a lot like fixing other faults that can split a network.

Notifications are a huge deal for avoiding security faults 📣. Implementations SHOULD use appropriate mechanisms to notify operators as security resources are about to expire. Notifications can be messages to consoles, logged events, Simple Network Management Protocol (SNMP) traps, or notifications within a routing protocol. One strategy is increasing escalations of notifications.

Monitoring matters too, especially for stuff like certificate expiration 👀. Some classes of security fault, including certificate issues, only affect key management protocols. Other security faults can hit routing protocols directly. However, the protocols MUST still have adequate operational mechanisms to recover from these situations. Also, some faults, like ones from a compromise or an 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, a router failure means security provisioning needs updating 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 let a router's credentials be recovered, which is super valuable in case of a hardware fault. The failing router can be recovered without changing credentials on other routers or waiting for keys to be certified. The downside is that even if public-key cryptography is used, the private keys end up on more than just the router. A system where keys are generated on a router and never exported from it would typically make it harder for an attacker to get the keys. For most environments, though, being able to quickly replace a router justifies keeping keys centrally 🔑.

More generally, keying is another bit of configuration that needs restoring to get service back when equipment fails. Operators typically do the minimal configuration needed to get a router back in contact with the management server, and the same would apply to keys. Operators who don't keep copies of key material for recovering routers would need to do a bit more work to regain contact with the management server. It seems reasonable to assume management servers will be able to cause keys to be generated or distributed enough to fully restore service 💜.

7. Upgrade Considerations 🎀

It needs to be possible to deploy automated key management in an organization without disabling existing security or disrupting routing. That means it needs to be possible to do 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. Right now, a lot of operators don't 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's still a potential cost of service disruptions, because operational procedures and practices need to correctly use those 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 haven't 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. Also, many implementations support grouping configuration (including security configuration) of related peers together. That makes it challenging to move from TCP MD5 to TCP-AO before all peers in the group are ready. Operators see 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 even more complicated for multicast protocols 🌈. It's typically not desirable to bring down an entire link to reconfigure it for automated key management. Two approaches should be considered. One is to support key table rows that enable 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 doesn't define a protocol, so no need to panic 🌸. It does discuss the operational and management implications of several security technologies, and those implications are no joke.

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 tight enough time synchronization that receivers permit a key to be used for validation before the first use of that key for generating integrity-protected messages. Otherwise, availability gets hit 💀. If time synchronization is too loose, then a key can be used beyond its intended lifetime, and that's a whole mess. 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. Iconic reviewers, honestly 👑.

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.

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

📦 where this page comes from

ietf: rfc7211 2014-06
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms