RFC 6862

Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements

📅 published March 2013, from ietf

RFC 6862 🦋 Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements

okay bestie, let's start with the title block 💖 because it tells us everything about who wrote this and why it exists:

  • Series: IETF, Request for Comments 6862 ✨
  • Authors: G. Lebovitz, M. Bhatia (Alcatel-Lucent), and B. Weis (Cisco Systems) 🫶
  • Category: Informational 🌸
  • ISSN: 2070-1721
  • Date: March 2013
  • Obsoletes/Updates: the header has no Obsoletes or Updates line, so this doc isn't listed as replacing or changing anything else 🧚

Abstract 💅

so routing protocols all secure their packets on the wire in different ways 🫠 most of them already have some way to do cryptographic message authentication, but honestly? a lot of those methods are dated, vulnerable to attack, and use cryptographic algorithms that have been deprecated 💀 the "Keying and Authentication for Routing Protocols" (KARP) effort is here to overhaul and improve all of that 🔥

this document does not contain protocol specifications 🙈 instead, it defines the areas where protocol specification work is needed. it's a companion to RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" 💜 together, these two form the guidance and instruction the KARP design teams will use to review and overhaul routing protocol transport security. main character energy, fr fr 👑

Status of This Memo ✨

this document is not an Internet Standards Track specification 💅 it's published for informational purposes, so no, it isn't a standard you're forced to follow 🌈

it is a product of the Internet Engineering Task Force (IETF) 🦋 it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶 not every document the IESG approves is a candidate for any level of Internet Standard, though. see Section 2 of RFC 5741 for that one 🤓

for info on the current status of this document, any errata, and how to give feedback on it, check out http://www.rfc-editor.org/info/rfc6862 🍓

copyright (c) 2013 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. please read these carefully, bestie, because they spell out your rights and restrictions for this document 🫶 any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
  1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  7
2.  KARP Effort Overview . . . . . . . . . . . . . . . . . . . . .  7
  2.1.  KARP Scope . . . . . . . . . . . . . . . . . . . . . . . .  7
  2.2.  Incremental Approach . . . . . . . . . . . . . . . . . . .  8
  2.3.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  2.4.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . . 12
  2.5.  Audience . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.  Threats  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  3.1.  Threat Sources . . . . . . . . . . . . . . . . . . . . . . 13
    3.1.1.  OUTSIDERS  . . . . . . . . . . . . . . . . . . . . . . 13
    3.1.2.  Unauthorized Key Holder  . . . . . . . . . . . . . . . 14
      3.1.2.1.  Terminated Employee  . . . . . . . . . . . . . . . 15
    3.1.3.  BYZANTINE  . . . . . . . . . . . . . . . . . . . . . . 15
  3.2.  Threat Actions In Scope  . . . . . . . . . . . . . . . . . 16
  3.3.  Threat Actions Out of Scope  . . . . . . . . . . . . . . . 17
4.  Requirements for KARP Work Phase 1: Update to a Routing
    Protocol's Existing Transport Security . . . . . . . . . . . . 18
5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
  7.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
  7.2.  Informative References . . . . . . . . . . . . . . . . . . 24

1. Introduction ✨

okay so in March 2006, the Internet Architecture Board (IAB) held a workshop on the topic "Unwanted Internet Traffic" 🌸 the report from that workshop is documented in [RFC4948] 📚 Section 8.1 of that document says, "A simple risk analysis would suggest that an ideal attack target of minimal cost but maximal disruption is the core routing infrastructure" 😭 and Section 8.2 calls for "[t]ightening the security of the core routing infrastructure" 🔒 four main steps were identified for that tightening:

  • Create secure mechanisms and practices for operating routers. 🛠️
  • Clean up the Internet Routing Registry (IRR) repository, and secure both the database and the access to it, so that it can be used for routing verification. 🧹
  • Create specifications for cryptographic validation of routing message content. ✅
  • Secure the routing protocols' packets on the wire 🦋

the first bullet is being handled in the OPSEC working group 💅 the second bullet should be handled through liaisons with the people running the IRRs globally 🌍 the third bullet is being handled in other IETF efforts. for example, BGP message content validity is being addressed in the SIDR working group 🧚

this document covers the last item on that list: securing the transmission of routing protocol packets on the wire 🎀 more precisely, it focuses on securing the transport systems that routing protocols use, including any mechanisms built into the protocols themselves to authenticate packets. this effort is called Keying and Authentication for Routing Protocols, or "KARP" 💜 KARP is concerned with the issues and techniques for protecting messages between directly communicating peers. this type of protection may overlap with protection designed to make sure routing information is properly authorized relative to its source, but it is strongly distinct from it 🫶 those assurances come from other mechanisms and are outside the scope of this document 🙅‍♀️

this document is one of two that together form the guidance and instructions for KARP design teams working to overhaul routing protocol transport security. the other one is the KARP Design Guide [RFC6518] 🌈

this document does not contain protocol specifications 🙈 its goal is to define the areas where protocol specification work is needed, and to give KARP design teams a set of requirements to follow as they update a routing protocol's existing transport security (see Work Phase 1 in Section 4.1 of [RFC6518]) 🍓

this document has three main parts 🧁 the first part, in Section 2, gives an overview of the KARP effort ✨ the second part, in Section 3, lists the threats from "Generic Threats To Routing Protocols" [RFC4593] that are in scope for per-packet authentication for routing protocol transport systems 😤 so this document does not contain a complete threat model. it just points to the parts of the governing threat model that KARP design teams must address, and it explicitly states which parts are out of scope for them 💅 the third part, in Section 4, lists the requirements that routing protocol specifications must meet when addressing the threats related to KARP's Work Phase 1, the update to a routing protocol's existing transport security 👑 ("Work Phase 2", a framework and usage of a Key Management Protocol (KMP), will be addressed in a future document[s]) 🔮

1.1. Terminology

okay so bestie, first we need to agree on what words mean 💅 This doc says "on the wire" a lot, and it's the info routing protocols' transport systems use to talk, like the packets actually flying around 🦋 It's a super common RFC phrase, but people use it a few different ways, so this doc uses it for two things: info that routing peers swap with each other, AND the underlying protocols that might need protecting in certain situations. Individual protocol analysis docs will need to get more specific with it 🧚

Also, in this doc, these words mean the stuff listed below when they start with a capital letter or are ALL CAPS 👑 If they're lowercase, they just mean their normal everyday English vibe ✨

Identifier 🎀 The type and value a peer uses during an authenticated message exchange to show who it is to another peer. The receiver uses the Identifier as an index into a table that holds more info about that peer, which is needed to keep processing the message, like a Security Association (SA) or keys 🔑

Identity Authentication 🫶 Once the identity is verified, there must be a cryptographic proof of it, so we know the peer really is who it claims to be. 😤 There are a few ways to set this up among peers, like symmetric and asymmetric pre-shared keys, or an asymmetric key inside a certificate. Certificates can work without any extra supporting systems outside the routers themselves! For example, self-signed certificates plus a flat file list of "approved thumbprints" 📃 The different identity verification options vary in ease of deployment, ease of ongoing management, startup effort, security strength, and what happens if secrets leak from one part of the system to the rest. Like, they differ in how well they resist a breach, and how much effort it takes to recover after one 😭 The main point: there are options, and lots of them are pretty simple to use and deploy ✨

KDF (Key Derivation Function) 🌸 A KDF is a function where an input key plus other input data get used to generate keying material that cryptographic algorithms can use 🧪 The key you feed into a KDF is called a key derivation key. KDFs can generate one or more keys from (i) a random or pseudorandom seed value, or (ii) the result of the Diffie-Hellman exchange, or (iii) a non-uniform random source (for example, from a non-deterministic random bit generator), or (iv) a pre-shared key that may or may not be memorable by a human 🧠

KMP (Key Management Protocol) 💜 KMP is a protocol that sets up a shared symmetric key between a pair (or among a group) of users. It decides how secret keys get made available to the users, and sometimes also how the secret keys get generated 🔐 In some routing protocols, the routing protocol derives the traffic keys from a master key. In that case, KMP handles the master-key generation AND decides when the master key should be renewed. In other cases there are only traffic keys and no master key 🙈 Then KMP handles traffic key generation and the renewal mechanism instead.

KMP Function 🍓 Any KMP used in the general KARP solution framework.

Peer Key 🦋 Peer keys are keys peers use as a basis for identifying one another 🫶 They may or may not be connection specific, depending on how they were set up and which forms of identity and identity authentication mechanism the system uses. A peer key would generally be provided by a KMP, and later used to derive fresh traffic keys ✨

PSK (Pre-Shared Key) 🎀 A PSK is a key used to talk to one or more peers in a secure configuration. It's always distributed out of band before the first connection 📦

Replayed Messages 🙈 Replayed messages are genuine messages that an attacker has re-sent 😤 They can be replayed within a session (that's intra-session) or replayed from a different session (that's inter-session). For non-TCP-based protocols like OSPF [RFC2328] and IS-IS [RFC1195], two routers are said to have a session up if they can exchange protocol packets, meaning the peers have an adjacency 🤝 Messages replayed during an adjacency are intra-session replays. A message replayed between two peers who re-establish an adjacency after a reboot or loss of connectivity is an inter-session replay 💀

Routing Protocol 🌈 This term refers to a Routing Protocol that a KARP team is working on to improve the security of its packets on the wire 🛣️

SA (Security Association) 💅 An SA is a relationship set up between two or more entities so they can protect the data they exchange 🔒 Attributes that may be associated with an SA include Identifier, PSK, Traffic Key, cryptographic algorithms, and key lifetimes ⏳

Threat Source ⭐ A threat source is a motivated, capable adversary 😈

Traffic Key 👑 A Traffic Key is the key (or one of a set of keys) used to protect routing protocol traffic 🔐 A traffic key should not be a fixed value in a device configuration. It should be known only to the participants in a connection, so that compromising a stored key (which might be available to a terminated or turned employee) does not expose traffic keys 🚪 If a server or other data store gets stolen or compromised, attackers gain no access to current traffic keys. They might get access to key-derivation material, like a PSK, but not the traffic keys currently in use 🛡️

Additional terminology specific to threats is listed and defined below in Section 3 🕵️

1.2. Requirements Language

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 RFC 2119 [RFC2119] 📜

When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC 2119 ✨

2. KARP Effort Overview 🌷

2.1. KARP Scope

Three basic principles can be used to secure any piece of data as it's transmitted over the wire: confidentiality, authenticity, and integrity 🔐 The focus for the KARP working group will be message authentication and message integrity ONLY 🎯 At this time, this work explicitly excludes confidentiality. Non-repudiation is also excluded as a goal at this time 🙅‍♀️ Since the objective of most routing protocols is to broadly advertise the routing topology, routing protocol packets are commonly sent in the clear. So confidentiality is not normally required for routing protocols 🫣 BUT ensuring that routing peers are authentically identified, and that no rogue peers or unauthenticated packets can compromise the stability of the routing environment, is critical, and thus in scope 🚨 Confidentiality and non-repudiation may be addressed in future work 🔮

OSPF [RFC5709], IS-IS [RFC5310], LDP [RFC5036], and RIP [RFC2453] [RFC4822] already incorporate mechanisms for cryptographically authenticating and integrity checking the messages on the wire 💪 Products and code that use these mechanisms already exist and have been optimized for these existing security mechanisms 🛠️ Rather than turn away from these mechanisms, this document aims to enhance them, updating them to modern and more secure levels 🚀

Therefore, the scope of KARP's roadmap of work includes:

  • Making use of existing routing protocol transport security mechanisms, where they have been specified, and enhancing or updating them as necessary for modern cryptographic best practices. [RFC6518], Section 4.1 labels this KARP's Work Phase 1 🥇
  • Developing a framework for using automatic key management in order to ease deployment, lower cost of operation, and allow for rapid responses to security breaches. [RFC6518], Section 4.1 labels this KARP's Work Phase 2 🥈
  • Specifying an automated key management protocol that may be combined with Routing Protocol mechanisms. [RFC6518], Section 4.1 labels this KARP's Work Phase 2 🥈

Neither this document nor [RFC6518] contains protocol specifications 📝 Instead, they define the areas where protocol specification work is needed, and they set a direction, a set of requirements, and priorities for tackling that specification work 🗺️

There's a set of threats to routing protocols that are considered in scope for KARP, and a set considered out of scope. These are described in detail in Section 3 🔍 ✨

2.2. Incremental Approach 🐢➡️🏃

Okay bestie, this section is the Routing Area and the Security Area making a pinky promise 🤝 about what gets done first and how the KARP roadmap above gets rolled out step by step. The vibe is "crawl, walk, run" 🍼👟, so routing protocol authentication mechanisms may not jump straight from where they are now to the best, most modern security practices. That's the whole plot. Sometimes the perfect security is off the table, and something that's way better than what we have now but not the absolute best wins, because that's how we make real progress toward a more secure Internet 🌈. This document is going to point out every place where everyone agreed on those trade-offs ✨.

Incremental steps are needed for a few very practical reasons. First, a lot of routing devices are already deployed in live networks, and they can't run the most modern cryptographic mechanisms without big, unacceptable performance penalties 😩. The roadmap for any routing protocol MUST allow for incremental improvements on those existing operational devices. Second, routing protocol performance on deployed devices has been built up over the last 20 years through lots of tuning of software and hardware, and vendors and operators are constantly trying to make it better 💪. New security mechanisms shake up that performance balance, so the performance impact of any incremental security improvement has to be weighed by the community and introduced in a way that gives vendors and operators a path to adoption that keeps reasonable performance metrics 📈. That's why certain specification elements may be introduced with "SHOULD" guidance, with the plan that the same mechanism will carry a "MUST" in a future release of the specification 🧠. This gives vendors and implementors the guidance they need to tune their software and hardware over time 🛠️. Last, some security mechanisms need other operational support systems to be built out first, and that takes time ⏳.

An example of all three of these steps in action is the improvement of BGP's [RFC4271] security through the TCP Authentication Option (TCP-AO) [RFC5925] effort 🦋. It would have been ideal, and would have matched best common security practice, to have a fully specified key management protocol for negotiating the TCP-AO keying material, for example using certificates for peer authentication 🔐. But in the spirit of incremental deployment, the IETF first handled issues like cryptographic algorithm agility, replay attacks, and the resetting of TCP sessions in the base TCP-AO protocol, and then later started working on layering key management on top of those 🎀.

2.3. Goals 🎯

Here are the goals and general guidance for the KARP work, no cap 💅:

  1. Provide authentication and integrity protection for messages on the wire for existing routing protocols.
  2. Define a path to incrementally improve security of the routing infrastructure as explained in Section 2.2.
  3. Ensure that the improved security solutions are deployable on current routing infrastructure. This requires consideration of the current state of processing power available on routers in the network today.
  4. Operational deployability 🚀: a solution's acceptability also gets measured by how deployable it is for operator teams, with consideration for their deployment processes and infrastructures. KARP design teams will try to make these solutions fit as well as possible into current operational practices and router deployment methodologies. That depends heavily on operator input during KARP design efforts. Hopefully operator input leads to a more deployable solution, which will in turn lead to more production deployments. Deployment of incrementally more secure routing infrastructure in the Internet is the final measure of success 👑. We'd love to see more respondents to surveys such as [ISR2008] report deployment of the updated authentication and integrity mechanisms in their networks, and a sharp rise in usage of these mechanisms across a greater percentage of their network's routers 📊.

Interviews with operators show several things about routing security 👀. First, according to [ISR2008], over 70% of operators have deployed transport connection protection via TCP MD5 [RFC3562] on their External Border Gateway Protocol (eBGP) sessions. Over 55% also deploy TCP MD5 on their Internal Border Gateway Protocol (iBGP) connections, and 50% use TCP MD5 offered on some other internal gateway protocol (IGP). The same survey states that "a considerable increase was observed over previous editions of the survey for use of TCP MD5 with external peers (eBGP), internal peers (iBGP) and MD5 extensions for IGPs." The report doesn't capture this, but the authors believe anecdotally that of those who have deployed TCP MD5 somewhere in their network, only about 25-30% of the routers in their network have the authentication enabled 😬. None report using IPsec [RFC4301] to protect the routing protocol, which was a decline from the few that reported doing so in the previous year's report 📉. Anecdotal evidence from operators using MD5 shows that almost all of them use one manually distributed key throughout the entire network 🔑. These same operators report that the single key has not been changed since it was originally installed, sometimes five or more years ago 💀. When asked why, especially for protecting BGP sessions using TCP MD5, the following reasons came up a lot:

  • A. Changing the keys triggers a TCP reset, and thus the links/adjacencies bounce, undermining Service Level Agreements (SLAs).
  • B. For external peers, it is difficult to coordinate with the other organization, and in practice the coordination is very cumbersome and tedious to execute. Once the operator finds the correct contact at the other organization (not always so easy), the coordination function is serialized and performed on a per-peer or per-AS basis.
  • C. Keys must be changed at precisely the same time, or at least within 60 seconds (as supported by two major vendors) in order to limit the duration of a connectivity outage. This is incredibly difficult to do operationally, especially between different organizations.
  • D. Key change is perceived as a relatively low priority compared to other operational issues.
  • E. Staff levels are insufficient to implement the changes on a device-by-device basis.
  • F. There are three use cases for operational peering at play: peers and interconnection with other operators, iBGP and other routing sessions within a single operator, and operator-to-customer devices. All three have very different properties, and all are reported as cumbersome to manage securely. One operator reported that the same key is used for all customer premise equipment (CPE). The same operator reported that if the customer mandated it, a unique key could be created, although the last time this occurred, it created such an operational headache that the administrators now usually tell customers that the option doesn't even exist, to avoid the difficulties. These customer-unique keys are never changed, unless the customer demands it. The main threat here is that a terminated employee from such an operator who had access to the one (or several) keys used for authentication in these environments could wage an attack. Alternatively, the operator could offer the keys to others who would wage the attack. In either case, the attacker could then bring down many of the adjacencies, thus destabilizing the routing system 😱.
  1. Whatever mechanisms KARP specifies need to be easier to deploy than the current methods, and should provide obvious operational efficiency gains along with significantly better security ✨. This combination of value may be enough to drive much broader adoption 🌸.
  2. Address the threats enumerated below in "Threats" (Section 3) for each routing protocol. Not all threats may be able to be addressed in the first specification update for any one protocol. Roadmaps will be defined so that both the Security Area and the Routing Area agree on how the threats will be addressed completely over time 🗺️.
  3. Create a reusable architecture, framework, and guidelines for various IETF working groups that will address these security improvements for various routing protocols 🧩. The crux of KARP is to reuse the architecture, framework, and guidelines as much as possible across relevant routing protocols. For example, designers should aim to reuse the key management protocol that will be defined for BGP, which will establish keys for TCP-AO, for as many other routing protocols with similar characteristics and properties as possible 🫶.
  4. Bridge any gaps between the IETF Routing and Security Areas by recording agreements on work items, roadmaps, and guidance from the cognizant Area Directors and the Internet Architecture Board (IAB) 🌉.

2.4. Non-Goals 🙅‍♀️

The following goals are considered out of scope for this effort, so don't even try 🙈:

  • Confidentiality and non-repudiation of the packets on the wire. Once the goals of this roadmap are realized, work on confidentiality may be considered.
  • Non-repudiation of the packets on the wire.
  • Message content validity (routing database validity). This work is being addressed in other IETF efforts. For example, BGP message content validity is being addressed in the SIDR working group 🍓.

2.5. Audience

okay so who's actually reading this? 🎀 here's the crew:

  • Routing Area working group chairs and participants 💅 - These people are charged with updating Routing Protocol specifications. Any and all cryptographic authentication work on these specifications will occur in Routing Area working groups, in close partnership with the Security Area. Co-advisors from the Security Area may often be named for these partnership efforts.
  • Security Area reviewers of Routing Area documents 🔍 - These people are tasked by the Security Area Directors to perform reviews on routing protocol specifications as they pass through working group last call or IESG review. Their particular attention to the use of cryptographic authentication and newly specified security mechanisms for the routing protocols is appreciated. They also help to ensure that incremental security improvements are being made, in line with this roadmap.
  • Security Area engineers 🛡️ - These people partner with Routing Area authors/designers on the security mechanisms in routing protocol specifications. Some of these Security Area engineers will be assigned by the Security Area Directors, while others will be interested parties in the relevant working groups.
  • Operators 🧚 - The operators are a key audience for this work, as the work is considered to have succeeded only if operators deploy the technology. It is anticipated that deployment will take place only if operators perceive that the improved security offered by the Routing Protocol updates warrants the complexity and cost of deployment and operation. Conversely, the work will be considered a failure if operators do not deploy it, either due to a lack of perceived value or due to perceived operational complexity. As a result, the GROW and OPSEC working groups should be kept squarely in the loop as well.

3. Threats 👑

okay so this section is where we get into the scary stuff 💀 but make it organized. This document uses the definition of "threat" from RFC 4949 [RFC4949]:

"[a] potential for violation of security, which exists
when there is an entity, circumstance, capability, action, or event
that could cause harm."

This section defines the threats that are in scope for the KARP effort. It also lists those threats that are explicitly out of scope for the KARP effort. Threats are discussed assuming that no protection (i.e., message authentication and message integrity) has been applied to routing protocol messages.

This document leverages the model described in "Generic Threats to Routing Protocols" [RFC4593]. Specifically, the threats listed below were derived by reviewing [RFC4593], analyzing how the threats applied to the KARP problem space, and listing the threats that are applicable to the work for the KARP design team. This document categorizes [RFC4593] threats into those in scope and those out of scope for KARP. Each in-scope threat is discussed below, and its applicability to the KARP problem space is described. As such, the following text intentionally is not a comprehensive threat analysis. Rather, it describes the applicability of the existing threat analysis in [RFC4593] to KARP.

Note: terms from [RFC4593] appear capitalized below -- e.g. OUTSIDERS -- so as to make explicit the term's origin, and to enable rapid cross referencing to the source RFC.

For convenience, a terse definition of most [RFC4593] terms is offered here. Those interested in a more thorough description of routing protocol threat sources, motivations, consequences, and actions will want to read [RFC4593] before continuing here.

3.1. Threat Sources 🦋

3.1.1. OUTSIDERS

One of the threats that will be addressed in this roadmap is the situation in which the source is an OUTSIDER. An OUTSIDER attacker may reside anywhere in the Internet, may have the ability to send IP traffic to the router, may be able to observe the router's replies, and may even control the path for a legitimate peer's traffic. OUTSIDERS are not legitimate participants in the routing protocol.

The use of message authentication and integrity protection specifically aims to identify packets originating from OUTSIDERS.

KARP design teams will consider two specific use cases of OUTSIDERS: those on path, and those off path.

  • On Path 🕵️ - These attackers have control of a network resource or a tap that sits along the path between two routing peers. A "Man in the Middle" (MitM) is an on-path attacker. From this vantage point, the attacker can conduct either active or passive attacks. An active attack occurs when the attacker places packets on the network as part of the attack. One active MitM attack relevant to KARP, an active wiretapping attack, occurs when the attacker tampers with packets moving between two legitimate router peers in such a way that both peers think they are talking to each other directly, when in fact they are actually talking to the attacker. Protocols conforming to this roadmap will use cryptographic mechanisms to detect MitM attacks and reject packets from such attacks (i.e., discard them as being not authentic). Passive on-path attacks occur when the attacker silently gathers data and analyzes it to gain advantage. Passive activity by an on-path attacker may lead to an active attack.
  • Off Path 🌙 - These attackers sit on some network outside of that over which the packets between two routing peers run. The source may be one or several hops away. Off-path attackers can launch active attacks, such as SPOOFING or denial-of-service (DoS) attacks, to name a few.

3.1.2. Unauthorized Key Holder

This threat source exists when an unauthorized entity somehow manages to gain access to keying material. Using this material, the attacker could send packets that pass the authenticity checks based on Message Authentication Codes (MACs). The resulting traffic might appear to come from router A and be destined for router B, and thus the attacker could impersonate an authorized peer. The attacker could then adversely affect network behavior by sending bogus messages that appear to be authentic. The attack source possessing the unauthorized keys could be on path, off path, or both.

The obvious mitigation for an unauthorized key holder is to change the keys currently in use by the legitimate routing peers. This mitigation can be either reactive or proactive. Reactive mitigation occurs when keys are changed only after one has discovered that the previous keys have fallen into the possession of unauthorized users. The reactive mitigation case is highlighted here in order to explain a common operational situation where new keying material will need to be put in place with little or no advanced warning. In such a case, new keys must be able to be installed and put into use very quickly, and with little operational expense. Proactive mitigation occurs when an operator assumes that unauthorized possession will occur from time to time without being discovered, and the operator moves to new keying material in order to cut short an attacker's window of opportunity to use the stolen keys effectively.

KARP design teams can address this type of attack by creating specifications that make it practical for the operator to quickly change keys without disruption to the routing system and with minimal operational overhead. Operators can further mitigate threats from unauthorized key holders by regularly changing keys.

3.1.2.1. Terminated Employee 🥀

A terminated employee is an important example of an unauthorized key holder. Staff attrition is a reality in routing operations and is therefore a potential threat source. The threat source risk arises when a network operator who had been granted access to keys ceases to be an employee. If new keys are deployed immediately, the situation of a terminated employee can become an "unauthorized key holder, proactive" case, as described above, rather than an "unauthorized key holder, reactive mitigation" case. It behooves the operator to change the keys, to enforce the revocation of authorization of the old keys, in order to minimize the threat source's window of opportunity.

A terminated employee is a valid unauthorized key holder threat source for KARP, and designs should address the associated threats. For example, new keys must be able to be installed and made operational in the routing protocols very quickly, with zero impact to the routing system, and with little operational expense. The threat actions associated with a terminated employee also motivate the need to change the keys quickly, also with little operational expense.

3.1.3. BYZANTINE 🐝

According to [RFC4593], Section 3.1.1.2, BYZANTINE "attackers are faulty, misconfigured, or subverted routers; i.e., legitimate participants in the routing protocol", whose messages cause routing to malfunction.

[RFC4593] goes on to say that "[s]ome adversaries can subvert routers, or the management workstations used to control these routers. These Byzantine failures represent the most serious form of attack capability in that they result in emission of bogus traffic by legitimate routers."

[RFC4593] explains that "[d]eliberate attacks are mimicked by failures that are random and unintentional. In particular, a Byzantine failure in a router may occur because the router is faulty in hardware or software or is misconfigured", and thus routing malfunctions unintentionally. Although not malicious, such occurrences still disrupt network operation.

Whether faulty, misconfigured, or subverted, Byzantine routers have an empowered position from which to provide believable yet bogus routing messages that are damaging to the network. 💖

3.2. Threat Actions In Scope ✨

Okay so these are the THREAT ACTIONS that are in scope for KARP 💖

  • SPOOFING: when an unauthorized device pretends to be an authorized one 🎭. SPOOFING is lowkey special because it can be used to pull off other threat actions that cause other threat consequences. For example, it can inject malicious routing information that disrupts network services 💀. It can also be used to form a neighbor relationship that then blocks the formation of the relationship with a legitimate router 🙅‍♀️.
  • DoS attacks
    • A. At the transport layer: this happens when an attacker sends packets aimed at halting or preventing the underlying protocol that the routing protocol runs over 😭. The attacker could use SPOOFING, FALSIFICATION, or INTERFERENCE (see below) to make the DoS attack happen. For example, BGP running over Transport Layer Security (TLS) will still not solve the problem of an attacker sending a spoofed TCP FIN or TCP RST and knocking the BGP session offline. Since these attacks depend on spoofing, operators are encouraged to deploy proper authentication mechanisms to stop them 🔐. Specification work should make sure Routing Protocols can operate over transport subsystems in a way that holds up against these DoS attacks 🛡️.
    • B. Using the authentication mechanism: this includes an attacker causing INTERFERENCE, which blocks exchanges between legitimate routers. The attack is often done by sending packets that confuse or overwhelm the security mechanism itself 🌪️. One example is sending an overwhelming flood of spoofed routing protocol packets that contain a MAC (i.e., INSERTING MESSAGES), so the receiver burns substantial CPU resources checking the MAC, only to throw the spoofed packet away 🥲. Other types of INTERFERENCE include REPLAYING OUT-DATED PACKETS, CORRUPTING MESSAGES, and BREAKING SYNCHRONIZATION.
  • FALSIFICATION: an action where an attacker sends false routing information 🙃. This document only targets FALSIFICATION from OUTSIDERS, which can happen by tampering with packets in flight or by sending completely fake messages. FALSIFICATION from BYZANTINES (see Section 3.3) is not addressed by the KARP effort, so that's a no-go for us 🚫.
  • Brute-Force Attacks Against Password/Keys: this includes online or offline attacks where attempts are made over and over with different keys or passwords until one matches 🔑. It's impossible to make brute-force attacks on keys completely useless, but good design can make them way harder to pull off 💪. For example, current guidance for the security strength of an algorithm with a particular key length should be deemed acceptable for a period of 10 years. (Section 10 of [SP.800-131A] is one source for guidance.) Using per-session keys is another popular method for cutting down brute-force attacks, since it makes the keys really hard to guess 🧩.

3.3. Threat Actions Out of Scope 🙅‍♀️

BYZANTINE sources -- be they faulty, misconfigured, or subverted -- are out of scope for this roadmap 🚧. KARP works to cryptographically make sure that received routing messages came from authorized peers and that the message wasn't altered in transit 🔏. Forming a bogus message by a valid and authorized peer falls outside the KARP scope 🫠. Any of the attacks described in Section 3.2 that a BYZANTINE source might carry out are therefore also out of scope, e.g. FALSIFICATION from BYZANTINE sources or unauthorized message content by a legitimate authorized peer.

These other attack actions are also out of scope for this work:

  • SNIFFING (passive wiretapping): passive observation of route message contents in flight 👀. Data confidentiality, which data encryption provides, is the usual way to prevent SNIFFING. It's super useful, especially for stopping the gathering of data needed for an off-path packet injection attack, but data encryption is out of scope for KARP 🤷‍♀️.
  • INTERFERENCE due to:
    • A. NOT FORWARDING PACKETS: cannot be prevented with cryptographic authentication. Note: if sequence numbers with sliding windows are used in the solution (as is done, for example, in Bidirectional Forwarding Detection (BFD) [RFC5880]), a receiver can at least detect that this attack is happening 👁️.
    • B. DELAYING MESSAGES: cannot be prevented with cryptographic authentication. Note: timestamps can be used to detect delays ⏰.
    • C. DENIAL OF RECEIPT (non-repudiation): cannot be prevented with cryptographic authentication 📭.
    • D. UNAUTHORIZED MESSAGE CONTENT: covered by the work of the IETF's SIDR working group (http://www.ietf.org/html.charters/sidr-charter.html) 📜.
    • E. DoS attacks not involving the routing protocol: for example, a flood of traffic that fills the link ahead of the router, so the router is rendered unusable and unreachable by valid packets, is NOT an attack that KARP will address 🌊. Many such examples could be contrived.

4. Requirements for KARP Work Phase 1: Update to a Routing Protocol's Existing Transport Security 🎀

Section 4.1 of the KARP Design Guide [RFC6518] describes two distinct work phases for the KARP effort 🗺️. This section covers the requirements for only the first work phase, Work Phase 1, which is the update to a routing protocol's existing transport security. Work Phase 2, the framework and usage of a KMP, will be addressed in a future document(s) 🔮.

The following list of requirements SHOULD be addressed by a KARP Work Phase 1 security update to any Routing Protocol (according to section 4.1 of the KARP Design Guide [RFC6518] document). It is RECOMMENDED that any Work Phase 1 security update to a Routing Protocol contain a section of the specification document that describes how each of the following requirements is met 📝. It is further RECOMMENDED that justification be presented for any requirements that are NOT addressed 🙏.

  1. Clear definitions of which elements of the transmitted data (frame, packet, segment, etc.) are protected by an authentication/integrity mechanism 🔍.
  2. Strong cryptographic algorithms, as defined and accepted by the IETF security community, MUST be specified. The use of non-standard or unpublished algorithms MUST be avoided 🙅‍♀️.
  3. Algorithm agility for the cryptographic algorithms used in the authentication MUST be specified, and protocol specifications MUST be clear regarding how new algorithms are specified and used within the protocol 🔄. This requirement exists because research identifying weaknesses in cryptographic algorithms can cause the security community to reduce confidence in some algorithms. Breaking a cipher isn't a matter of if, but when it will occur 😬. Having the ability to specify alternate algorithms (algorithm agility) within the protocol specification to support such an event is essential. Additionally, more than one algorithm MUST be specified. Mandating support for two algorithms (i.e., one mandatory to implement algorithm and one or more backup algorithms to guide transition) provides both redundancy and a mechanism for enacting that redundancy 🫶.
  4. Secure use of PSKs, offering both operational convenience and a baseline level of security, MUST be specified 🔑.
  5. Routing Protocols (or the transport or network mechanism protecting routing protocols) SHOULD be able to detect and reject replayed intra-session and inter-session messages. Packets captured from one session MUST NOT be able to be resent and accepted during a later session (i.e., inter-session replay). Additionally, replay mechanisms MUST work correctly even in the presence of routing protocol packet prioritization by the router ⏪.

There is a specific case of replay attack combined with spoofing that must be addressed 🚨. Several routing protocols (e.g., OSPF [RFC2328], IS-IS [RFC1195], BFD [RFC5880], RIP [RFC2453], etc.) require all speakers to share the same authentication and message association key on a broadcast segment. It is important that an integrity check associated with a message fails if an attacker has replayed the message with a different origin 🕵️‍♀️.

  1. A change of security parameters MUST force a change of session traffic keys. The specific security parameters for the various routing protocols will differ and will be defined by each protocol design team. Some examples may include master key, key lifetime, and cryptographic algorithm. If one of these configured parameters changes, then a new session traffic key MUST immediately be established using the updated parameters. The routing protocol security mechanisms MUST support this behavior 🔁.
  2. Security mechanisms MUST specify a means to affect intra-session rekeying without disrupting a routing session. This should be accomplished without data loss, if possible. Keys may need to be changed periodically based on policy or when an administrator who had access to the keys leaves an organization 🚪. A rekeying mechanism enables operators to execute the change without productivity loss ✨.
  3. Rekeying SHOULD be supported in such a way that it can occur during a session without the peer needing to use multiple keys to validate a given packet. The rare exception will occur if a routing protocol's design team can find no other way to rekey and still adhere to the other requirements in this section. The specification SHOULD include a key identifier, which allows receivers to choose the correct key (or determine that they are not in possession of the correct key) 🗝️.
  4. New mechanisms MUST resist DoS attacks described as in scope in Section 3.2. Routers protect the control plane by implementing mechanisms to reject completely or rate-limit traffic not required at the control-plane level (i.e., unwanted traffic). Typically, line-rate packet-filtering capabilities look at information in the IP and transport (TCP or UDP) headers, but do not include higher-layer information. Therefore, the new mechanisms should neither hide nor encrypt the information carried in the IP and transport layers in control-plane packets 🛡️💅.

4. Requirements for KARP Work Phase 1: Update to a Routing Protocol's ✨

  1. Okay, so every routing protocol security mechanism MUST come with its mandatory cryptographic algorithms and mechanisms spelled out 🔐. No vibes-based crypto allowed! The protocol spec ALSO MUST define default security mechanism settings that every implementation uses when nobody has configured anything. Why does this matter? Picture a routing protocol that mandates three different cryptographic algorithms for a MAC operation. Company A makes algorithm 1 its default, and Company B makes algorithm 2 its default. Now two operators switch on the security mechanism with just a PSK and no other config, and boom, connection failure 💀. Every implementation having all three mandatory algorithms is NOT enough, though. You need one agreed-upon default too, for the best out-of-the-box interoperability 💖.
  2. For backward-compatibility reasons, manual keying MUST be supported 🗝️.
  3. The specification MUST consider and allow for future use of a KMP 🔮.
  4. The authentication mechanism in a Routing Protocol MUST be decoupled from the key management system used 🧩. The authentication protocol MUST include a specification for agreeing on keying material. This is what lets both manual keying and KMPs fit in comfortably 🫶.
  5. Convergence times of the Routing Protocols SHOULD NOT be materially affected ⏱️. Changes in convergence time are immediately and independently verifiable by the convergence performance test beds already in use (for example, the ones maintained by router vendors, service providers, and researchers) 🔍. An increase in convergence time of more than 5% is likely to be considered by network operators as having materially affected convergence 😬. A bunch of other factors can also change convergence over time, like how fast the processors on individual routing peers are, processing power gains from Moore's law, and implementation specifics 🌈. So implementors need to account for the effect an authentication mechanism has on Routing Protocols. Protocol designers should look at the impact on convergence times as a function of both the total number of protocol packets that must be exchanged and the computational processing required for individual messages in the specification. Keep in mind that the operator community's threshold for an increase in convergence times is very low, as noted above 👀.
  6. The changes to, or additions of, security mechanisms SHOULD NOT cause a refresh of route advertisements or cause additional route advertisements to be generated 📣.
  7. Router implementations give prioritized treatment to certain protocol packets 🚦. For example, OSPF Hello and Acknowledgement packets get prioritized for processing above other OSPF packets. The security mechanism SHOULD NOT interfere with the ability to observe and enforce that prioritization. Any effect on those priority mechanisms MUST be explicitly documented and justified 📝. Replay protection mechanisms provided by the routing protocols MUST work even when certain protocol packets are offered prioritized treatment 🛡️.
  8. The Routing Protocol MUST send minimal information about the authentication mechanisms and associated parameters in its protocol packets 🤫. This keeps the Routing Protocols as clean and focused as possible, and it pushes security negotiations into the KMP as much as possible. It also avoids exposing security negotiation information to possible attackers on the path for no good reason 🙈.
  9. Routing Protocols that rely on the IP header (or on information separate from the routing protocol payload) to identify the neighbor that originated the packet MUST either protect the IP header or provide some other means to authenticate the neighbor 🪪. [RFC6039] describes some attacks that motivate this requirement 💅.
  10. Every new KARP-developed security mechanisms MUST support incremental deployment 🌱. Nobody can deploy a new Routing Protocol authentication mechanism across a whole network instantly. It may not even be feasible to deploy such a mechanism to all routers in a large autonomous system (AS) within a bounded timeframe. So proposed solutions MUST support an incremental deployment method that benefits those who participate 🎀. Because of this, there are several requirements that any proposed KARP mechanism should consider.
    • A. The Routing Protocol security mechanism MUST enable each router to configure use of the security mechanism on a per-peer basis, where the communication is peer to peer (unicast) 🤝.
    • B. Every new KARP-developed security mechanism MUST provide backward compatibility with respect to message formatting, transmission, and processing of routing information carried through secure and non-secure security environments 🔁. Message formatting in a fully secured environment MAY be handled in a non-backward-compatible fashion, though care must be taken to ensure that routing protocol packets can traverse intermediate routers that don't support the new format 🧭.
    • C. In an environment where both secured and non-secured routers are interoperating, a mechanism MUST exist for secured systems to identify whether a peer intended the messages to be secured 🔎.
    • D. In an environment where secured service is in the process of being deployed, a mechanism MUST exist to support a transition free of service interruption (caused by the deployment per se) 🌸.
  11. The introduction of mechanisms to improve routing security may increase the processing a router has to do 🧮. Since most of the currently deployed routers don't have hardware to accelerate cryptographic operations, these operations could impose a significant processing burden under some circumstances 🥵. So proposed solutions SHOULD be evaluated carefully for the processing burden they may impose. Deployment may be impeded if network operators perceive that a solution will impose a burden that either incurs substantial capital expense or threatens to degrade router performance 💸.
  12. New authentication and security mechanisms should not rely on systems external to the routing system (the equipment that is performing forwarding) in order for the routing system to be secure 🏰. To ensure the rapid initialization and/or return to service of failed nodes, it's important to reduce reliance on these external systems as much as possible ⚡. Proposed solutions SHOULD NOT require connections to external systems, beyond those directly involved in peering relationships, in order to return to full service. It is, however, acceptable for proposed solutions to require post-initialization synchronization with external systems in order to fully synchronize security associations 🔄.

If authentication and security mechanisms rely on systems external to the routing system, then there MUST be one or more options available to avoid circular dependencies 🌀. It is not acceptable to have a routing protocol (e.g., unicast routing) depend upon correct operation of a security protocol that, in turn, depends upon correct operation of the same instance of that routing protocol (i.e., the unicast routing). That is a no-go 🚫. However, it is acceptable to have operation of a routing protocol (e.g., multicast routing) depend upon operation of a security protocol, which depends upon an independent routing protocol (e.g., unicast routing). Similarly, it would be okay to have the operation of a routing protocol depend upon a security protocol, which in turn uses an out-of-band network to exchange information with remote systems 🧚.

5. Security Considerations 🔒

This document is mostly about security considerations for the KARP efforts, both the threats and the requirements for addressing those threats. More detailed security considerations are provided in the Security Considerations section of the KARP Design Guide [RFC6518]document. This part is serious, bestie, so pay attention 🫶.

The use of a group key between a set of Routing Protocol peers has special security considerations 🚨. Possession of the group key itself is used for identity validation, and no other identity check is used. Under these conditions, an attack exists when one peer masquerades as a neighbor by using the neighbor's source IP address 😱. This type of attack is well documented in the group-keying problem space, and it is non-trivial to solve. Solutions do exist within the group-keying realm, but they come with significant increases in complexity and computational intensity 🧠.

6. Acknowledgements 🙏

The majority of the text for the initial draft of this document was taken from "Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire", authored by Gregory M. Lebovitz 💜.

Brian Weis provided significant assistance in handling the many comments that came back during IESG review, including making textual edits directly to the XML. For his extensive efforts, he was added as an author 👑.

We would like to thank the following people for their thorough reviews and comments: Brian Weis, Yoshifumi Nishida, Stephen Kent, Vishwas Manral, Barry Leiba, Sean Turner, and Uma Chunduri 🌟.

Author Gregory M. Lebovitz was employed at Juniper Networks, Inc. for much of the time he worked on this document, though not at the time of its publishing. Thus, Juniper sponsored much of this effort 🦋.

7. References 📚

7.1. Normative References

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4593]      Barbir, A., Murphy, S., and Y. Yang, "Generic Threats
               to Routing Protocols", RFC 4593, October 2006.

[RFC4948]      Andersson, L., Davies, E., and L. Zhang, "Report from
               the IAB workshop on Unwanted Traffic March 9-10,
               2006", RFC 4948, August 2007.

7.2. Informative References ✨

okay bestie, this is the reading list 📚💅 these aren't required to implement the spec, but they're the receipts behind the design choices, and some of them are literally the origin story of KARP 🦋

  • [ISR2008] McPherson, D. and C. Labovitz, "Worldwide Infrastructure Security Report", October 2008, <http://pages.arbornetworks.com/rs/arbor/images/ISR2008_EN.pdf>. 📊
  • [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. 🌸
  • [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 🧚
  • [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998. 🍓
  • [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003. 🔐
  • [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. 🌐
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 🛡️
  • [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007. 💜
  • [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007. 📖
  • [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. 🎀
  • [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009. 🔥
  • [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009. ✨
  • [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. 🦋
  • [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. 🌈
  • [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010. 🙈
  • [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012. 👑
  • [SP.800-131A] Barker, E. and A. Roginsky, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", United States of America, National Institute of Science and Technology, NIST Special Publication 800-131A, January 2011. 🫶

Authors' Addresses 🎀

meet the squad who wrote this thing 🥹💖

Gregory Lebovitz
Aptos, California  95003
United States

EMail: gregory.ietf@gmail.com


Manav Bhatia
Alcatel-Lucent
Bangalore,
India

EMail: manav.bhatia@alcatel-lucent.com


Brian Weis
Cisco Systems
170 W. Tasman Drive
San Jose, California  95134-1706
United States

EMail: bew@cisco.com
URI:   http://www.cisco.com

periodt, that's the whole spec 🦋✨ thank you for sticking with me through all seven parts, you're the best bestie ever 💅💜

📦 where this page comes from