RFC 4593

Generic Threats to Routing Protocols

📅 published October 2006, from ietf

RFC 4593: Generic Threats to Routing Protocols 🦋

okay bestie, this one is RFC 4593 and it's giving threat model realness 💅 It's an Informational doc from the Network Working Group, dated October 2006. The authors are A. Barbir (Nortel), S. Murphy (Sparta, Inc.), and Y. Yang (Cisco Systems). The header doesn't list anything it obsoletes or updates 🎀

Status of This Memo ✨

this memo is just giving info to the Internet community 🌸 it does not specify an Internet standard of any kind, and distribution of it is unlimited 💖

Copyright (C) The Internet Society (2006). 🫶

Abstract 💜

okay so routing protocols can get attacked, and that can hurt individual users or the whole network's operations 😭 this doc gives a description and a summary of generic threats that affect routing protocols in general. it covers threats, including threat sources and capabilities, threat actions, and threat consequences, plus a breakdown of routing functions that might get attacked separately 🧚

Table of Contents

   1. Introduction ....................................................2
   2. Routing Functions Overview ......................................3
   3. Generic Routing Protocol Threat Model ...........................4
      3.1. Threat Definitions .........................................4
           3.1.1. Threat Sources ......................................4
                  3.1.1.1. Adversary Motivations ......................5
                  3.1.1.2. Adversary Capabilities .....................5
           3.1.2. Threat Consequences .................................7
                  3.1.2.1. Threat Consequence Scope ...................9
                  3.1.2.2. Threat Consequence Zone ...................10
                  3.1.2.3. Threat Consequence Periods ................10
   4. Generally Identifiable Routing Threat Actions ..................11
      4.1. Deliberate Exposure .......................................11
      4.2. Sniffing ..................................................11
      4.3. Traffic Analysis ..........................................12
      4.4. Spoofing ..................................................12
      4.5. Falsification .............................................13
           4.5.1. Falsifications by Originators ......................13
                  4.5.1.1. Overclaiming ..............................13
                  4.5.1.2. Misclaiming ...............................16
           4.5.2. Falsifications by Forwarders .......................16
                  4.5.2.1. Misstatement ..............................16
      4.6. Interference .........................................17
      4.7. Overload .............................................18
   5. Security Considerations ........................................18
   6. References .....................................................18
      6.1. Normative References ......................................18
   Appendix A. Acknowledgments .......................................20
   Appendix B. Acronyms ..............................................20

1. Introduction 🎀

okay so routing protocols get hit with threats and attacks that can harm individual users or the network operations as a whole 😤 this doc gives a summary of generic threats that affect routing protocols. specifically, it identifies generic threats that include threat sources, threat actions, and threat consequences, and it breaks down the routing functions that might be attacked separately 🦋

this work should be seen as a precursor to building a common set of security requirements for routing protocols 💅 it's well known that bad, incomplete, or poor implementations of routing protocols may, by themselves, cause routing problems or failures, or may raise the risk of a network getting attacked successfully 💀 but those issues aren't considered here. this document only looks at attacks against robust, well-considered implementations of routing protocols, like the ones specified in Open Shortest Path First (OSPF) [4], Intermediate System to Intermediate System (IS-IS) [5][8], RIP [6], and BGP [7] 👑 attacks against implementation-specific weaknesses and vulnerabilities are out of scope for this document, no debate 🙅‍♀️

the doc is organized like this: Section 2 reviews routing functions. Section 3 defines threats. In Section 4, there's a discussion of generally identifiable routing threat actions. Section 5 covers security considerations ✨

2. Routing Functions Overview 🧚

this section gives an overview of common functions shared among various routing protocols. in general, routing protocols share these functions:

  • Transport Subsystem: The routing protocol transmits messages to its neighbors using some underlying protocol. For example, OSPF uses IP, while other protocols may run over TCP. 🚀
  • Neighbor State Maintenance: Neighboring relationship formation is the first step for topology determination. For this reason, routing protocols may need to maintain state information. Each routing protocol may use a different mechanism for determining its neighbors in the routing topology. Some protocols have distinct exchanges through which they establish neighboring relationships, e.g., Hello exchanges in OSPF. 🤝
  • Database Maintenance: Routing protocols exchange network topology and reachability information. The routers collect this information in routing databases with varying detail. The maintenance of these databases is a significant portion of the function of a routing protocol. 🗂️

in a routing protocol, there are message exchanges meant for controlling the state of the protocol. for example, neighbor maintenance messages carry that kind of information. on the other hand, there are messages used to exchange information meant for the forwarding function, like messages that maintain the database. these messages affect the data (information) part of the routing protocol 🍓

3. Generic Routing Protocol Threat Model 💖

the model developed in this section can be used to identify threats to any routing protocol 🔥

routing protocols get threatened at various levels 😳 for example, threats can hit the transport subsystem, where the routing protocol can be attacked through its underlying protocol. an attacker may also go after messages that carry control information in a routing protocol to break a neighboring (e.g., peering, adjacency) relationship. this kind of attack can impact network routing behavior in the affected routers and likely the surrounding neighborhood too. for example, in BGP, if a router receives a CEASE message, it will break its neighboring relationship to its peer and potentially send new routing information to any remaining peers 💀

an attacker may also go after messages that carry data information, in order to break a database exchange between two routers or to affect the database maintenance functionality. for example, the information in the database must be authentic and authorized. an attacker who can introduce bogus data can have a strong effect on routing behavior in the neighborhood. for example, if an OSPF router sends LSAs with the wrong Advertising Router, the receivers will compute a Shortest Path First (SPF) tree that is incorrect, and it might not forward the traffic. if a BGP router advertises a Network Layer Reachability Information (NLRI) it isn't authorized to advertise, then receivers might forward that NLRI's traffic toward that router, and the traffic wouldn't be deliverable. a Protocol Independent Multicast (PIM) router might transmit a JOIN message to receive multicast data it would otherwise not receive 🫠

3.1. Threat Definitions 🌸

in [1], a threat is defined as a potential for violation of security. it exists when there is a circumstance, capability, action, or event that could breach security and cause harm. threats can be categorized as threat sources, threat actions, threat consequences, threat consequence zones, and threat consequence periods ✨

part 1 done, bestie 🌈 the threat model is about to get SO juicy, so stay tuned 💜

3.1.1. Threat Sources 🕵️‍♀️

okay so, a threat source is basically a motivated, capable adversary 😤 (when we're talking about deliberate attacks). If we figure out what they WANT (their attack goals) and what they're CAPABLE of, we can work out what kinds of attacks they could pull off, and therefore what countermeasures will be required to handle them. main character planning fr 🎀

3.1.1.1. Adversary Motivations 🦋

bestie, we assume the most common goal of an adversary deliberately attacking routing is to cause inter-domain routing to malfunction 💀. A routing malfunction means traffic follows a path (a sequence of autonomous systems, in the case of BGP) that's different from the one the routing protocol would have computed if it were working properly, meaning if it weren't under attack.

As a result of an attack, a route might end at a router other than the one that legitimately represents the destination address of the traffic, or it might pass through routers other than the ones it normally would have. Either way, a routing malfunction can let an adversary wiretap traffic passively, or pull off man-in-the-middle (MITM) active attacks, which includes discarding traffic (denial of service) 🙈.

A routing malfunction might also be done for financial gain tied to traffic volume (vs. the content of the routed traffic), for example to mess with settlements among ISPs 💸.

Another possible goal is damaging the network infrastructure itself, either on a targeted or a wide-scale basis 🔥. So attacks that cause excessive transmission of UPDATE or other management messages, plus all the router processing that comes with them, could be motivated by these goals.

Irrespective of the goals above, an adversary may or may not be averse to detection and identification 🫣. This trait shapes some of the ways attacks can be carried out.

3.1.1.2. Adversary Capabilities 🧚

Different adversaries have different capabilities, so let's break it down 💅:

  • All adversaries are presumed to be able to direct packets to routers from remote locations, and they can assert a false IP source address with each packet (IP address spoofing) 🎭. The goal is to get the targeted router to accept and process the packet as though it came from the indicated source. Spoofing can trick routers into acting on bogus messages to cause misrouting, or those messages can be used to overwhelm a router's management processor for DoS. Protection from such adversaries must not rely on the claimed identity in routing packets that the protocol receives.
  • Some adversaries can monitor links that carry routing traffic and emit packets that mimic data in legitimate routing traffic on those links, so they can actively join message exchanges with the legitimate routers 👀. This makes it easier for them to generate bogus routing traffic that a router might accept, leading to misrouting or DoS. Replaying previously delivered management traffic (replay attacks) is a great example of this capability. Because of this, protection from such adversaries ought not to rely on the secrecy of unencrypted data in packet headers or payloads.
  • Some adversaries can pull off MITM attacks against routing traffic, for example by actively wiretapping a link between two routers 🕷️. This is the ultimate wiretapping capability for an adversary. Protection from such adversaries must not rely on the integrity of inter-router links to authenticate traffic, unless cryptographic measures are used to detect unauthorized modification.
  • Some adversaries can subvert routers, or the management workstations used to control them 😱. These Byzantine failures are the most serious form of attack capability, because they result in legitimate routers emitting bogus traffic. So protection from such adversaries must not rely on the correct operation of neighbor routers. Protection measures should adopt the principle of least privilege to minimize the impact of this kind of attack. To counter Byzantine attacks, routers ought not to trust management traffic just because of its source (e.g., based on its source). Instead, each router should independently authenticate management traffic before acting on it 🛡️.

We will assume that any cryptographic countermeasures used to secure BGP will employ algorithms and modes that are resistant to attack, even from sophisticated adversaries. So, we will ignore cryptanalytic attacks 🔐.

Deliberate attacks can be mimicked by failures that are random and unintentional 🎲. In particular, a Byzantine failure in a router may happen because the router is faulty in hardware or software, or because it's misconfigured. As described in [3], "A node with a Byzantine failure may corrupt messages, forge messages, delay messages, or send conflicting messages to different nodes". Byzantine routers, whether faulty, misconfigured, or subverted, have the context to provide believable and very damaging bogus routing information 😬. They may also claim another legitimate peer's identity. Since they're peers, they might even slip past the authentication protections, if those protections can only detect that a source is one of the legitimate peers (e.g., when the router uses the same cryptographic key to authenticate all peers).

So we split threat sources into two groups 🫶:

  • Outsiders: These attackers may be anywhere on the Internet, 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 🌍. They are not legitimate participants in the routing protocol.
  • Byzantine: These attackers are faulty, misconfigured, or subverted routers. In other words, they're legitimate participants in the routing protocol 🤭.

3.1.2. Threat Consequences 💥

A threat consequence is a security violation that results from a threat action [1]. For a routing protocol, a security violation is a compromise of some aspect of the correct behavior of the routing system. That compromise can damage the data traffic meant for a particular network or host, or it can damage the operation of the network's routing infrastructure as a whole 😩.

There are four types of general threat consequences: disclosure, deception, disruption, and usurpation [1]. Let's go through them 📝:

  • Disclosure: Disclosure of routing information happens when an attacker accesses the information without being authorized 👁️. Outsiders who can observe or monitor a link may cause disclosure if routing exchanges lack confidentiality. Byzantine routers can cause disclosure as long as they're successfully involved in the routing exchanges. Inappropriate disclosure of routing information can pose a security threat or be part of a later, larger, or higher-layer attack, but confidentiality is not generally a design goal of routing protocols 🤷‍♀️.
  • Deception: This consequence happens when a legitimate router receives a forged routing message and believes it's authentic 🎭. Both outsiders and Byzantine routers can cause this if the receiving router can't check routing message integrity or origin authentication 😵.
  • Disruption: This consequence occurs when a legitimate router's operation is interrupted or prevented 🚧. Outsiders can cause this by inserting, corrupting, replaying, delaying, or dropping routing messages, or by breaking routing sessions between legitimate routers. Byzantine routers can cause it by sending false routing messages, interfering with normal routing exchanges, or flooding unnecessary routing protocol messages. (DoS is a common threat action causing disruption 🙃.)
  • Usurpation: This consequence happens when an attacker gains control over the services or functions a legitimate router provides to others 👑. Outsiders can cause this by delaying or dropping routing exchanges, or by fabricating or replaying routing information. Byzantine routers can cause it by sending false routing information or interfering with routing exchanges.
Note: An attacker doesn't have to control a router directly to control its services 👀. For example, in Figure 1, Network 1 is dual-homed through Router A and Router B, and Router A is preferred. However, Router B gets compromised and advertises a better metric. So devices on the Internet choose the path through Router B to reach Network 1. In this way, Router B steals the data traffic, and Router A loses control of its services to Router B. This is depicted in Figure 1.
                   +-------------+   +-------+
                   |  Internet   |---| Rtr A |
                   +------+------+   +---+---+
                          |              |
                          |              |
                          |              |
                          |            *-+-*
                   +-------+           /     \
                   | Rtr B |----------*  N 1  *
                   +-------+           \     /
                                        *---*

                  Figure 1.  Dual-homed network

Several threat consequences can come from a single threat action 🌈. In Figure 1, there are at least two consequences: routers using Router B to reach Network 1 are deceived, and Router A is usurped 😭.

3.1.2.1. Threat Consequence Scope 🎀

okay so, like we said before, an attack can mess up the data traffic meant for one particular network or host, OR it can mess up how the routing infrastructure of the whole network runs 😭 Damage from attacks on the whole network can look like this:

  • Network congestion. More data traffic gets forwarded through some part of the network than would otherwise need to carry it 🚗💨
  • Blackhole. Huge amounts of traffic get unnecessarily redirected to go through one router, and that router drops many/most/all of the packets 🕳️
  • Looping. Data traffic gets forwarded along a route that loops, so the data is never delivered (which causes network congestion too) 🔁
  • Partition. Some part of the network thinks it's cut off from the rest of the network when it actually isn't 🙈
  • Churn. The forwarding in the network changes (unnecessarily) at a rapid pace, so the data delivery patterns jump around a lot (and that messes with congestion control techniques) 🌪️
  • Instability. The protocol becomes unstable, so the network never converges on a global forwarding state 💀
  • Overcontrol. The routing protocol messages themselves become a big chunk of the traffic the network carries 📨
  • Clog. A router gets an excessive number of routing protocol messages, which makes it run out of some resource (e.g., memory, CPU, battery) 🥵

The damage that might result from attacks against a particular host or network address can look like this:

  • Starvation. Data traffic destined for the network or host gets forwarded to a part of the network that can't deliver it 🍽️
  • Eavesdrop. Data traffic gets forwarded through a router or network that otherwise wouldn't see it, which gives the attacker a chance to see the data or at least the data delivery pattern 👀
  • Cut. Some part of the network thinks it has no route to the host or network, even though it's actually connected ✂️
  • Delay. Data traffic destined for the network or host gets forwarded along a route that is somehow inferior to the route it would otherwise take 🐌
  • Looping. Data traffic for the network or host gets forwarded along a route that loops, so the data is never delivered 🔁

It is important to consider all consequences, because some security solutions can protect against one consequence but not the others 💅 It might be possible to design a security solution that protects one destination's traffic from eavesdropping without protecting against churn in the network. Similarly, it is possible to design a security solution that prevents a starvation attack against one host, but not a clogging attack against a router. The security requirements must be clear about which consequences are being avoided and which consequences must be addressed by other means (e.g., by administrative means outside the protocol) 📋✨

3.1.2.2. Threat Consequence Zone 🌍

A threat consequence zone covers the area where network operations have been affected by threat actions. Possible threat consequence zones can be classified as a single link or router, multiple routers (within a single routing domain), a single routing domain, multiple routing domains, or the global Internet 🗺️ The threat consequence zone depends on the threat action and on the position of the attack's target. Similar threat actions that happen in different locations may result in totally different threat consequence zones, which is so wild to me 🤯 For example, when an outsider breaks the routing session between a distribution router and a stub router, only reachability to and from the network devices attached to the stub router will be impaired. In other words, the threat consequence zone is a single router. In another case, if the outsider is located between a customer edge router and its corresponding provider edge router, that action might cause the whole customer site to lose its connection. In this case, the threat consequence zone might be a single routing domain 🏢

3.1.2.3. Threat Consequence Periods ⏳

A threat consequence period is the portion of time during which network operations are impacted by the threat consequences. The threat consequence period is influenced by, but not totally dependent on, the duration of the threat action. Sometimes the network gets back to normal as soon as the threat action stops. Other times, though, the threat consequences can stick around longer than the threat action did 😩 For example, in the original Advanced Research Projects Agency Network (ARPANET) link-state algorithm, some errors in a router introduced three instances of a Link-State Announcement (LSA). All of them flooded through the network continuously until the entire network was power cycled [2]. Iconic chaos energy 🔌💀

4. Generally Identifiable Routing Threat Actions ✨

This section covers generally identifiable and recognized threat actions against routing protocols. The threat actions aren't necessarily specific to individual protocols, but they may be present in one or more of the common routing protocols in use today 🧩

4.1. Deliberate Exposure 📢

Deliberate exposure happens when an attacker takes control of a router and intentionally releases routing information to other entities (e.g., the attacker, a web page, a mail posting, other routers) that otherwise should not receive the exposed information 😤

The consequence of deliberate exposure is the disclosure of routing information.

The threat consequence zone of deliberate exposure depends on the routing information the attackers have exposed. The more knowledge they expose, the bigger the threat consequence zone gets 📈

The threat consequence period of deliberate exposure might be longer than the duration of the action itself. The exposed routing information won't be outdated until there's a topology change in the exposed network 🫠

4.2. Sniffing 👃

Sniffing is an action where attackers monitor and/or record the routing exchanges between authorized routers in order to sniff out routing information. Attackers can also sniff data traffic information (however, this is out of scope of the current work) 🙅‍♀️

The consequence of sniffing is the disclosure of routing information.

The threat consequence zone of sniffing depends on the attacker's location, the routing protocol type, and the routing information that has been recorded. For example, if the outsider is sniffing a link in an OSPF totally stubby area, the threat consequence zone should be limited to the whole area. An attacker sniffing a link in an External Border Gateway Protocol (EBGP) session can gain knowledge of multiple routing domains 👀

The threat consequence period might be longer than the duration of the action. If an attacker stops sniffing a link, their acquired knowledge won't be outdated until there's a topology change in the affected network ⏰

4.3. Traffic Analysis 📊

Traffic analysis is an action where attackers gain routing information by analyzing the characteristics of the data traffic on a subverted link. Traffic analysis threats can affect any data that is sent over a communication link. This threat isn't peculiar to routing protocols, but it's included here for completeness 🧐

The consequence of data traffic analysis is the disclosure of routing information. For example, the source and destination IP addresses of the data traffic, plus the type, magnitude, and volume of traffic, can be disclosed 🕵️‍♀️

The threat consequence zone of traffic analysis depends on the attacker's location and on what data traffic has passed through. An attacker at the network core should be able to gather more information than its counterpart at the edge, so it would have to analyze traffic patterns across a wider area 🌐

The threat consequence period might be longer than the duration of the traffic analysis. After the attacker stops traffic analysis, its knowledge won't be outdated until there's a topology change in the disclosed network 💅

4.4. Spoofing 🎭

Spoofing happens when an illegitimate device assumes the identity of a legitimate one. Spoofing by itself is often not the true attack. What makes it special is that it can be used to carry out other threat actions, causing other threat consequences. An attacker can use spoofing as a means of launching other types of attacks. For example, if an attacker succeeds in spoofing the identity of a router, the attacker can send out unrealistic routing information that might disrupt network services 😈

There are a few cases where spoofing can be an attack in and of itself. For example, messages from an attacker that spoof the identity of a legitimate router may cause a neighbor relationship to form, and deny the formation of the relationship with the legitimate router 🙃

The consequences of spoofing are as follows:

  • The disclosure of routing information. The spoofing router will be able to access the routing information.
  • The deception of peer relationship. The authorized routers that exchange routing messages with the spoofing router don't realize they're neighboring a router that is faking another router's identity 🤥

The threat consequence zone is as follows:

  • The consequence zone of the fake peer relationship will be limited to those routers trusting the attacker's claimed identity.
  • The consequence zone of the disclosed routing information depends on the attacker's location, the routing protocol type, and the routing information that has been exchanged between the attacker and its deceived neighbors.

Note: This section focuses on addressing spoofing as a threat on its own. However, spoofing creates conditions for other threat actions. The other threat actions are considered falsifications and are treated in the next section 📝

4.5. Falsification 🚫

Falsification is an action where an attacker sends false routing information. To falsify routing information, an attacker has to be either the originator or a forwarder of that information. It cannot be a receiver-only. False routing information describes the network in an unrealistic fashion, whether or not the authoritative network administrator intended it 🤡

4.5.1. Falsifications by Originators 🧑‍💻

An originator of routing information can launch the falsifications that are described in the next sections ✨

4.5.1.1. Overclaiming

Okay so overclaiming is when a Byzantine router or an outsider flexes control over some network resources it totally does not control (or the claim just isn't authorized), and it's giving main character lies 💅. Figures 2 and 3 show it. 🦋

        +-------------+   +-------+   +-------+
        | Internet    |---| Rtr B |---| Rtr A |
        +------+------+   +-------+   +---+---+
               |                          .
               |                          |
               |                          .
               |                        *-+-*
           +-------+                   /     \
           | Rtr C |------------------*  N 1  *
           +-------+                   \     /
                                        *---*

                Figure 2.  Overclaiming-1


        +-------------+   +-------+   +-------+
        |  Internet   |---| Rtr B |---| Rtr A |
        +------+------+   +-------+   +-------+
               |
               |
               |
               |                        *---*
           +-------+                   /     \
           | Rtr C |------------------*  N 1  *
           +-------+                   \     /
                                        *---*

                Figure 3.  Overclaiming-2

So in these figures, Router A is the attacker, and it's hooked up to the Internet through Router B 🫶. Router C is the one that's actually allowed to advertise its link to Network 1. In Figure 2, Router A does control a link to Network 1, but it is not authorized to advertise it 🙈. In Figure 3, Router A doesn't control any such link at all. Either way though, Router A advertises the link to the Internet through Router B 😭.

Both Byzantine routers and outsiders can overclaim network resources, and the consequences are lowkey wild:

  • Usurpation of the overclaimed network resources. In Figures 2 and 3, Network 1 can get usurped when Router B (or other routers on the Internet that aren't drawn) thinks Router A has the best path to reach Network 1 🌸. So routers send data traffic destined for Network 1 over to Router A. The best case is the traffic takes an unauthorized path, like in Figure 2. The worst case is the data never reaches Network 1 at all, like in Figure 3 💀. The ultimate result is that Router A ends up controlling Network 1's services just by controlling the traffic 👑.
  • Usurpation of the legitimate advertising routers. In Figures 2 and 3, Router C is the legit advertiser of Network 1. Because of the overclaim, Router A also controls (partially or totally) the services and functions that Router C provides 🎀. (This is NOT a disruption, btw, since Router C is operating the way the authoritative network administrator intended 🧚.)
  • Deception of other routers. In Figures 2 and 3, Router B, or other routers on the Internet, might get fooled into believing the path through Router A is the best 🦋.
  • Disruption of data planes on some routers. This might happen to routers sitting on a path that other routers use to reach the overclaimed resources through the attacker. In Figures 2 and 3, once the other routers on the Internet get deceived, they forward data traffic to Router B, which might end up overloaded 😩.

The threat consequence zone changes depending on which consequence we're talking about:

  • Where usurpation is concerned, the consequence zone covers the network resources that the attacker overclaimed (Network 1 in Figures 2 and 3), plus the routers that are authorized to advertise those resources but lose the competition to the attacker (Router C in Figures 2 and 3) 🥺.
  • Where deception is concerned, the consequence zone covers the routers that believe the attacker's advertisement and use the attacker to reach the claimed networks (Router B and the other deceived routers on the Internet in Figures 2 and 3) 💜.
  • Where disruption is concerned, the consequence zone includes the routers on the path of the misdirected data traffic (Router B in Figures 2 and 3, plus other routers on the Internet along the path of the misdirected traffic) 🌈.

The threat consequence will NOT stop just because the attacker stops overclaiming 🙅. It only totally disappears once the routing tables have converged. So the consequence period ends up being longer than the overclaiming itself ⏳.

4.5.1.2. Misclaiming

Misclaiming is when an attacker advertises network resources that it IS authorized to control, but in a way the authoritative network administrator did not intend 🙃. For example, it might advertise inappropriate link costs in an OSPF LSA. An attacker can eulogize or disparage these network resources when advertising them (the drama is real 😭). Byzantine routers can misclaim network resources too 🫠.

The threat consequences of misclaiming are pretty similar to the consequences of overclaiming ✨.

The consequence zone and period are also similar to those of overclaiming 💅.

4.5.2. Falsifications by Forwarders

Okay, so in every routing protocol, routers that forward routing protocol messages are supposed to leave some fields alone and only modify other fields in certain limited ways 🎀. Which fields get modified, what the new contents can be, how those get computed from the original fields, which fields have to stay untouched, and so on, are all spelled out in the protocol specification 📖. Those rules can change depending on what the router does or what its network environment looks like 🌈. For example, in RIP, the forwarder has to modify the routing information by increasing the hop count by 1 🧚. On the flip side, a forwarder must NOT modify any field of the type 1 LSA in OSPF except the age field 🙅. In general, forwarders in distance vector routing protocols are authorized to modify the routing information (and they must), while most forwarders in link state routing protocols are NOT authorized to modify most routing information (and must not) 💖.

As a forwarder that's allowed to modify routing messages, an attacker could also falsify things by NOT forwarding routing information to other authorized routers when it's supposed to 😤.

4.5.2.1. Misstatement

This is when an attacker modifies route attributes in an incorrect way 🙈. For example, in RIP, the attacker might increase the path cost by two hops instead of one 💀. In BGP, the attacker might delete some AS numbers from the AS PATH 🍓.

Where forwarding routing information should NOT be modified, an attacker can pull off these falsifications:

  • Deletion. The attacker deletes valid data in the routing message 🥀.
  • Insertion. The attacker inserts false data into the routing message 😈.
  • Substitution. The attacker replaces valid data in the routing message with false data 🔁.

A forwarder can also falsify data by replaying out-dated data in the routing message as if it's current 🕰️.

All types of attackers, outsiders and Byzantine routers alike, can falsify routing information when they forward routing messages 🫣.

The threat consequences of these falsifications by forwarders are pretty much like the ones caused by originators: usurpation of some network resources and related routers, deception of routers using false paths, and disruption of the data planes of routers on those false paths 🌸. The threat consequence zone and period are similar too ✨.

4.6. Interference

Interference is a threat action where an attacker inhibits the exchanges between legit routers 🚫. The attacker can do this by adding noise, by not forwarding packets, by replaying out-dated packets, by inserting or corrupting messages, by delaying responses, by denying receipts, or by breaking synchronization 📡.

Byzantine routers can slow down their routing exchanges or induce flapping in the routing sessions of legit neighboring routers 🌊.

The consequence of interference is disruption of routing operations 💥.

The consequence zone of interference depends on how severe the interference is. If it results in consequences at the neighbor maintenance level, there may be changes in the database, which can lead to network-wide consequences 🌐.

The threat consequences might disappear as soon as the interference stops, or they might not totally disappear until the networks have converged. So the consequence period is equal to or longer than the duration of the interference ⏰.

4.7. Overload

Overload is a threat action where attackers place excess burden on legit routers 🥵. For example, an attacker can trigger a router to create an excessive amount of state that other routers in the network can't handle 🤯. Similarly, an attacker can overload database routing exchanges and thus influence routing operations 🫠.

5. Security Considerations

This entire document is security related, bestie 🔐. It specifically addresses the security of routing protocols as they relate to threats against those protocols 🛡️. In a larger context, this work builds on the IETF community's recognition that the signaling and control/management planes of networked devices need strengthening 💪. Routing protocols can be considered part of that signaling and control plane 🧠. However, to date, routing protocols have mostly been left unprotected and open to malicious attacks 😱. This document discusses the inter- and intra-domain routing protocol threats that are currently known, and it lays the foundation for other documents that will discuss security requirements for routing protocols 🏗️. This document is protocol independent 🦋.

6. References

6.1. Normative References

  • [1] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
  • [2] Rosen, E., "Vulnerabilities of network control protocols: An example", RFC 789, July 1981.
  • [3] Perlman, R., "Network Layer Protocols with Byzantine Robustness", PhD thesis, MIT LCS TR-429, October 1988.
  • [4] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
  • [5] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
  • [6] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
  • [7] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
  • [8] ISO 10589, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002.

Appendix A. Acknowledgments ✨

This document would not have been possible save for the excellent efforts and teamwork of the amazing people listed here 🫶.

  • Dennis Beard, Nortel 🌷
  • Ayman Musharbash, Nortel 🌷
  • Jean-Jacques Puig, int-evry, France 🌷
  • Paul Knight, Nortel 🌷
  • Elwyn Davies, Nortel 🌷
  • Ameya Dilip Pandit, Graduate student, University of Missouri 🎓
  • Senthilkumar Ayyasamy, Graduate student, University of Missouri 🎓
  • Stephen Kent, BBN 🌷
  • Tim Gage, Cisco Systems 🌷
  • James Ng, Cisco Systems 🌷
  • Alvaro Retana, Cisco Systems 🌷

Appendix B. Acronyms 🌸

okay so this is the glossary bit, bestie 📖 here's what the shorthand means:

  • AS - Autonomous system 🦋 a set of routers under one technical administration. Each AS normally runs a single interior gateway protocol (IGP) and metrics to spread routing info around its routers. Also called a routing domain.
  • AS-Path - In BGP, the route to a destination 🛣️ it's the list of AS numbers for all the routers a packet has to pass through to get where it's going.
  • BGP - Border Gateway Protocol 🌐 an exterior gateway protocol used to swap routing info between routers in different autonomous systems. iconic, honestly.
  • LSA - Link-State Announcement ⭐
  • NLRI - Network Layer Reachability Information 💜 info carried in BGP packets that MBGP uses.
  • OSPF - Open Shortest Path First 👑 a link-state IGP that picks routes using the shortest-path-first (SPF) algorithm, also known as the Dijkstra algorithm. the math is so clean ngl 🧚

Authors' Addresses 💌

here's where to find the authors, lowkey the best part of any doc 🫶

Abbie Barbir
Nortel
3500 Carling Avenue
Nepean, Ontario  K2H 8E9
Canada

EMail: abbieb@nortel.com


Sandy Murphy
Sparta, Inc.
7110 Samuel Morse Drive
Columbia, MD
USA

Phone: 443-430-8000
EMail: sandy@sparta.com


Yi Yang
Cisco Systems
7025 Kit Creek Road
RTP, NC  27709
USA

EMail: yiya@cisco.com

okay the legal stuff, but make it cute 🎀

Copyright (C) The Internet Society (2006). 💖

This document is subject to the rights, licenses and restrictions in BCP 78. except for what that says, the authors keep all their rights 🔒

This document and everything in it is handed over "AS IS" 🤷‍♀️ The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied. that covers, but isn't limited to, not infringing any rights, plus implied warranties of merchantability or fitness for a particular purpose. no promises, bestie 😭

Intellectual Property 🧠

the IETF doesn't take a side on whether any IPR or other rights claimed around the tech in this doc are valid or how far they reach, and it doesn't say licenses are or aren't available 🤐 it also hasn't done any independent digging to find those rights. info on how rights work for RFC docs is in BCP 78 and BCP 79 📜

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that'll be available, and the results of anyone trying to get a general license or permission for implementers or users are all findable in the IETF's online IPR repository at http://www.ietf.org/ipr. 🔍

the IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🙏

funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💜✨

📦 where this page comes from