RFC 6952

RFC 6952: Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide 🎀

okay bestie, title block first 💅 This one came from the Internet Engineering Task Force (IETF), and it's published as an Informational doc, not a Standards Track spec 🌸 It's dated May 2013 and its ISSN is 2070-1721 ✨ Three authors wrote it: M. Jethanandani from Ciena Corporation, K. Patel from Cisco Systems, Inc, and L. Zheng from Huawei Technologies 🫶 The header has no "Obsoletes" or "Updates" line, so it doesn't replace or change any other RFC 🦋

Abstract

ok so this doc takes a look at four TCP-based routing protocols 🧚 They are the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP) 💜 The analysis follows the guidelines in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", which is RFC 6518 🔥

Status of This Memo

this is not an Internet Standards Track spec, it's just published for info 🍓 It's a product of the IETF and represents what the IETF community agreed on ✨ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 💅

You can find the current status of this doc, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc6952 🌈

Copyright Notice

© 2013 IETF Trust and the people listed as the authors 💖 All rights reserved 🦋

This doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date 🫶 Read them carefully, because they explain your rights and restrictions 🙈 Any code pulled out of this doc needs to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and it comes with no warranty, as the Simplified BSD License says 🔥

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
2.  Current Assessment of BGP, LDP, PCEP, and MSDP  . . . . . . .   5
  2.1.  Transport Layer . . . . . . . . . . . . . . . . . . . . .   5
  2.2.  Keying Mechanisms . . . . . . . . . . . . . . . . . . . .   6
  2.3.  BGP . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
  2.4.  LDP . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
    2.4.1.  Spoofing Attacks  . . . . . . . . . . . . . . . . . .   7
    2.4.2.  Denial-of-Service Attacks . . . . . . . . . . . . . .   8
  2.5.  PCEP  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
  2.6.  MSDP  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
3.  Optimal State for BGP, LDP, PCEP, and MSDP  . . . . . . . . .  10
  3.1.  LDP . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
4.  Gap Analysis for BGP, LDP, PCEP, and MSDP . . . . . . . . . .  11
  4.1.  LDP . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
  4.2.  PCEP  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
5.  Transition and Deployment Considerations  . . . . . . . . . .  13
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  14

1. Introduction ✨

okay so back in March 2006 the IAB ran a workshop on unwanted traffic 🧚 In their report, [RFC4948], the Internet Architecture Board (IAB) described an attack on core routing infrastructure as the "ideal attack", meaning the one that does the most damage 💀 They also suggested ways to tighten things up against it 🔥 There were four main steps for that tightening:

1. Create secure mechanisms and practices for operating routers.
2. Clean up the Internet Routing Registry (IRR) repository, and secure both the database and the access, so that it can be used for routing verifications.
3. Create specifications for cryptographic validation of routing message content.
4. Secure the routing protocols' packets on the wire.

so to secure the routing protocols 💅 this doc does an initial analysis of where four TCP-based protocols are right now: BGP [RFC4271], LDP [RFC5036], PCEP [RFC5440], and MSDP [RFC3618] 🌈 The check is based on the requirements in the KARP Design Guidelines [RFC6518] 🫶 Section 4.2 of that doc uses the word "state", and this doc calls it the "state of the security method" 🦋 So a term like "Define Optimal State" becomes "Define Optimal State of the Security Method" 💖

this doc builds on a couple of earlier efforts into routing security 🎀

• "Issues with Existing Cryptographic Protection Methods for Routing Protocols" [RFC6039] describes issues with existing cryptographic protection methods for routing protocols.
• Analysis of OSPF Security According to the KARP Design Guide [RFC6863] analyzes Open Shortest Path First (OSPF) security according to the KARP Design Guide.

the rest of the doc goes like this 🍓 Section 2 looks at the current state of the security method for BGP, LDP, PCEP, and MSDP ✨ Section 3 looks at what the optimal state would be for those four protocols, using the KARP Design Guidelines [RFC6518] 👑 Section 4 covers the gap between the current state and the optimal state, and points out where things need to get better 🔥

1.1. Abbreviations

• AES - Advanced Encryption Standard
• AO - Authentication Option
• AS - Autonomous System
• BGP - Border Gateway Protocol
• CMAC - Cipher-Based Message Authentication Code
• DoS - Denial of Service
• GTSM - Generalized Time-to-Live (TTL) Security Mechanism
• HMAC - Hash-Based MAC
• KARP - Key and Authentication for Routing Protocols
• KDF - Key Derivation Function
• KEK - Key Encrypting Key
• KMP - Key Management Protocol
• LDP - Label Distribution Protocol
• LSR - Label Switching Routers
• MAC - Message Authentication Code
• MKT - Master Key Table
• MSDP - Multicast Source Distribution Protocol
• MD5 - Message Digest Algorithm 5
• OSPF - Open Shortest Path First
• PCEP - Path Computation Element Communication Protocol
• PCC - Path Computation Client
• PCE - Path Computation Element
• SHA - Secure Hash Algorithm
• TCP - Transmission Control Protocol
• TTL - Time-to-Live
• UDP - User Datagram Protocol
• WG - Working Group

2. Current Assessment of BGP, LDP, PCEP, and MSDP 🦋

this section checks the transport protocols for any authentication or integrity mechanisms they use 💅 It also describes the current security mechanisms, if there are any, that BGP, LDP, PCEP, and MSDP use 🫶

2.1. Transport Layer 🌸

at the transport layer, routing protocols get hit with a bunch of DoS attacks, as laid out in "Internet Denial-of-Service Considerations" [RFC4732] 😭 These attacks can make a routing protocol congested, so the routing updates arrive too slowly to be useful 💀 In extreme cases they stop routers from converging after a change 🙈

routing protocols have a few ways to protect themselves 🧚 The ones that use TCP use access lists so that only known sources get in 🔥 These lists also help protect edge routers from attacks that start outside the protected domain ✨ On top of that, for edge routers running the External Border Gateway Protocol (eBGP), TCP LISTEN only runs on interfaces where peers have been discovered or where routing sessions are expected, as set in router configuration databases 💅

"Generalized TTL Security Mechanism (GTSM)" [RFC5082] describes a generalized Time-to-Live (TTL) security mechanism that protects a protocol stack from CPU-utilization-based attacks 👑 TCP Robustness [RFC5961] recommends some TCP-level mitigations against spoofing attacks aimed at long-lived routing protocol sessions 🌈

even when BGP, LDP, PCEP, and MSDP sessions use access lists, they're still open to spoofing and man-in-the-middle attacks 😭 Authentication and integrity checks let the receiver of a routing protocol update know that the message really came from the node that says it sent it, and whether the message got changed along the way 🫶 Sometimes routers get slammed with a huge number of authentication and integrity requests, which uses up connection resources on the router and could end up blocking genuine requests 💀

TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925] 🥀 Even so, it's still used a lot to authenticate TCP-based routing protocols like BGP 💖 It gives you a way to carry an MD5 digest in a TCP segment 🎀 The digest is computed using information only the endpoints know, and that's what gives authenticity and integrity for messages ✨ The MD5 key used to compute the digest is stored locally on the router 🧚 This option lets routing protocols protect a session at the session level against spoofed TCP segments being slipped into existing TCP streams, especially TCP Reset segments 🔥 TCP MD5 doesn't give you a generic way to do key rollover, and it doesn't support algorithm agility either 🙈

the MACs used by TCP MD5 are considered too weak, for two reasons: the hash function itself, and the way the secret key is managed 💀 TCP MD5 also doesn't support any algorithm agility 😭 TCP-AO [RFC5925] and its companion doc Cryptographic Algorithms for TCP-AO [RFC5926] describe steps toward fixing both the MAC weakness and the way secret keys are managed 🫶 Those steps require that two MAC algorithms be supported: HMAC-SHA-1-96, as specified in HMAC [RFC2104], and AES-128-CMAC-96, as specified in NIST-SP800-38B [NIST-SP800-38B] 🌈 Cryptographic research suggests that both of these MAC algorithms are fairly secure 💅 Because TCP-AO supports multiple MAC algorithms, it has algorithm agility, and it also lets additional MACs get added in the future 👑

2.2. Keying Mechanisms ✨

okay so, for TCP-AO [RFC5925] there's no Key Management Protocol (KMP) 🔑 running around managing the keys that generate the MAC. TCP-AO just talks about coordinating keys pulled from the Master Key Table (MKT) between endpoints, and a master key can be configured manually or handled through an out-of-band mechanism. 🦋

ngl, it's kind of wild that most routers configured with static keys have never changed the key. 💀 The usual excuse is that coordinating a change between pairs of routers is a pain when you're using TCP MD5. But the longer the same key sticks around, the bigger the chance someone guesses it or it leaks, like when an admin who knows the keys leaves the company. 🙈

For point-to-point key management, the IKEv2 protocol [RFC5996] handles automated key exchange under a Security Association (SA) 👑 and can be a full KMP solution for routers. IKEv2 works for both IPsec SAs [RFC4301] and other types of SAs. For example, Fibre Channel SAs [RFC4595] are negotiated with IKEv2 right now. Using IKEv2 to negotiate TCP-AO is a possible option. 🌈

2.3. BGP

all BGP communication happens over TCP 🎀, so every security vulnerability for BGP falls into one of two buckets: the security of the transport protocol itself, or somebody compromising individual routers and the data they handle. This document looks at the transport protocol issues, while the SIDR Working Group (WG) works on ways to sign and secure the data exchanged in BGP, as described in "An Infrastructure to Support Secure Internet Protocol" [RFC6480]. 💅

2.4. LDP

"Security Framework for MPLS and GMPLS Networks" [RFC5920] lays out the security aspects that matter for MPLS and GMPLS. It covers the security threats, the defensive techniques that go with them, and the mechanism for detection and reporting. 🧚

Section 5 of LDP [RFC5036] says LDP is open to two kinds of attacks: spoofing and denial-of-service attacks. 😭

2.4.1. Spoofing Attacks

a spoofing attack against LDP can happen during the discovery phase and also during the session communication phase. 🌸

2.4.1.1. Discovery Exchanges using UDP

Label Switching Routers (LSRs) say "hi, I'm up for LDP sessions" by sending Hello messages on a regular basis. When a Hello message comes in, it either creates a brand new "Hello adjacency" (if there isn't one already) or refreshes the existing one. 🫶

there are two flavors of discovery. The Basic Discovery mechanism finds LSR neighbors that are directly connected at the link level, and the Extended Discovery mechanism is for LSRs that are more than one hop away. 🔥

here's the tea ☕: unlike every other LDP message, Hello messages are sent using UDP. That means they can't benefit from the security mechanisms that TCP has. LDP [RFC5036] doesn't provide any security mechanisms for Hello messages, except for some configuration that may help protect against bogus discovery events. Those configurations include directly connected links and interfaces. Routers that don't use directly connected links have to use the Extended Discovery mechanism, and they won't be able to use configuration to protect against bogus discovery events. 😤

spoofing a Hello packet for an existing adjacency can make that adjacency time out and terminate the associated session. This can happen when the spoofed Hello message specifies a small Hold Time, so the receiver expects Hello messages within that short interval, while the real neighbor keeps sending them at the lower, previously agreed frequency. 💀

spoofing a Hello packet can also terminate the LDP session. This can happen when the spoofed Hello specifies a different Transport Address from the one the neighbors previously agreed on. Spoofed Hello messages are observed and reported as a real problem in production networks. 🚨

2.4.1.2. Session Communication using TCP

LDP, like other TCP-based routing protocols, uses the TCP MD5 Signature Option to provide authenticity and integrity for session messages. As stated in Section 2.1 of this document and in Section 2.9 of LDP [RFC5036], MD5 authentication is considered too weak for this job, as outlined in MD5 and HMAC-MD5 Security Considerations [RFC6151]. It also doesn't support algorithm agility. 🙅‍♀️ A stronger hashing algorithm, e.g., SHA1, which is supported by TCP-AO [RFC5925], could be deployed to fix that weakness. 🌟

Alternatively, you could move to TCP-AO, which offers stronger MAC algorithms, makes it easier to set up manual keys, and protects against replay attacks. 🦋

2.4.2. Denial-of-Service Attacks

LDP is vulnerable to Denial-of-Service (DoS) attacks in both discovery mode and session mode. The potential targets are documented in Section 5.3 of LDP [RFC5036]. 🎯

2.5. PCEP

for effective selection by Path Computation Clients (PCCs), a PCC needs to know where the Path Computation Elements (PCEs) are in its domain, along with some info relevant to PCE selection. That PCE info can be learned through manual configuration on each PCC, along with the capabilities of the PCE, or automatically through a PCE discovery mechanism as outlined in Requirements for PCE Discovery [RFC4674]. 🗺️

attacks on PCEP [RFC5440] can cause damage to active networks. These include computation responses, which if changed can make protocols like RSVP-TE [RFC3209] set up suboptimal or inappropriate LSPs. On top of that, the PCE itself can be a target for a whole range of DoS attacks. These can make path computations arrive too slowly to be of any value, especially when it comes to recovery or establishing LSPs. 😱

finally, PCE discovery, as outlined in OSPF Protocol Extensions for PCE Discovery [RFC5088] and IS-IS Protocol Extensions for PCE Discovery [RFC5089], is a big deal for getting PCEP to work in large networks. These mechanisms let PCCs discover the existence of PCEs within the network. If the discovery mechanism gets compromised, it will hurt the nodes' ability to function as described below. 🥀

as RFC 5440 says, PCEP (which uses TCP as its transport) could be the target of the following attacks:

• Spoofing (PCC or PCE implementation)
• Snooping (message interception)
• Falsification
• Denial of Service

in inter-Autonomous System (inter-AS) scenarios, where PCE-to-PCE communication is required, these attacks can be especially serious, with commercial and service-level agreement implications. 💸

snooping PCEP requests and responses can also tell an attacker a lot about how the network runs. 👀 By viewing PCEP messages, an attacker can figure out the pattern of service establishment in the network and see where traffic is being routed. That makes the network susceptible to targeted attacks, and the data inside specific LSPs becomes vulnerable. 🚫

ensuring PCEP communication privacy is super important, especially in an inter-AS context, where the PCEP communication endpoints don't reside in the same AS. An attacker who intercepts a PCE message could get sensitive info about computed paths and resources. 🔐

when PCEP was documented in [RFC5440], TCP-AO hadn't been fully specified yet. So [RFC5440] mandates that PCEP implementations include support for TCP MD5, and that use of the function should be configurable by the operator. [RFC5440] also describes the vulnerabilities and weaknesses of TCP MD5, as noted in this document. Then it goes on to say PCEP implementations should include support for TCP-AO as soon as that specification is complete. Since TCP-AO [RFC5925] has now been published, new PCEP implementations should fully support TCP-AO. ✅

2.6. MSDP

similar to BGP and LDP, the Multicast Source Distribution Protocol (MSDP) uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5 option. But with weak MD5 authentication, TCP MD5 isn't considered strong enough for this application. It also doesn't support algorithm agility. 🙃

MSDP advocates imposing a limit on the number of source address and group address (S,G) pairs that can be cached within the protocol, to help mitigate state explosion caused by denial of service and other attacks. 🛡️

---

3. Optimal State for BGP, LDP, PCEP, and MSDP ✨

the ideal state for the security method of BGP, LDP, PCEP, and MSDP is when they can withstand any of the known types of attacks. The protocols also need to support algorithm agility, i.e., they must not hardwire themselves to one algorithm. 🧠

on top of that, the KMP for the routing sessions should help negotiate unique, pair-wise random keys without administrator involvement. It should also negotiate the Security Association (SA) parameters needed for the session connection, including key lifetimes. It should keep track of those lifetimes and negotiate new keys and parameters before they expire, and do all of that without administrator involvement. If there's a breach, including when an administrator who knows the keys leaves the company, the keys should be changed immediately. 🔑💥

the DoS attacks on BGP, LDP, PCEP, and MSDP are attacks on the transport protocol: TCP for the most part, and UDP in the case of the LDP discovery phase. TCP and UDP should be able to withstand any of the DoS scenarios by dropping attack packets in a way that doesn't affect legitimate packets. 🛡️✨

the routing protocols should provide a mechanism to authenticate the routing information carried within the payload, and administrators should enable it. 🫡

3.1. LDP

to address LDP's current vulnerability to spoofing attacks, LDP needs an upgrade so that an implementation can determine the authenticity of the neighbors sending the Hello message. 🕵️‍♀️

labels are similar to routing information, which is distributed in the clear. However, there's currently no requirement that labels be encrypted. That kind of requirement is out of scope for this document. 🙈

similarly, it's important to make sure that routers exchanging labels are mutually authenticated, and that there are no rogue or unauthenticated peers that could compromise the stability of the network. 🌈

4. Gap Analysis for BGP, LDP, PCEP, and MSDP ✨

okay so this section is the gap analysis 🔍 it spells out the difference between where security for routing protocols is right now and where it's supposed to be, as laid out in Section 4.2 of the KARP Design Guidelines [RFC6518]. as that doc says, these routing protocols are one-to-one peering messages 🫶 so they'll use peer keying protocols. we're covering the stuff all four protocols have in common here, and the protocol-specific bits live in the subsections 💅

At the transport level, these protocols deal with some of the same attacks that TCP apps deal with, like DoS and spoofing attacks 😭 "Internet Denial-of-Service Considerations" [RFC4732] has some solutions. "Defending TCP Against Spoofing Attacks" [RFC4953] recommends ways to prevent spoofing. And the recommendations in [RFC5961] should also be followed and implemented to beef up TCP 💪

Routers lack comprehensive key management and derived keys they can use to authenticate data 💀 for example, TCP-AO [RFC5925] talks about coordinating keys derived from the Master Key Table (MKT) between endpoints, but the MKT itself has to be configured manually or through an out-of-band mechanism. also, TCP-AO doesn't address connectionless reset as it applies to routers that don't store the MKT across reboots 🙈

Authentication, integrity protection, and encryption all need keys used by the sender and receiver. so an automated KMP has to include a way to distribute key material between two endpoints with little or no administrative overhead 🎀 It has to cover automatic key rollover. It's expected that authentication will cover the packet, i.e., the payload and the TCP header, and will not cover the frame, i.e., the layer 2 header.

There are two methods of automatic key rollover. Implicit key rollover can kick off after a certain volume of data gets exchanged or when a certain time has elapsed ⏰ it doesn't need explicit signaling, and nor should it result in a reset of the TCP connection in a way that the links/adjacencies are affected. On the other hand, explicit key rollover needs an out-of-band key signaling mechanism 🔑 it can be triggered by either side, and it can happen anytime a security parameter changes, e.g., an attack has happened, or a system administrator with access to the keys has left the company 😱 an example of this is IKEv2 [RFC5996], but it could be any other new mechanisms too.

As stated earlier, TCP-AO [RFC5925] and its accompanying document, Cryptographic Algorithms for TCP-AO [RFC5926], require that two MAC algorithms be supported. They are HMAC-SHA-1-96, as specified in HMAC [RFC2104], and AES-128-CMAC-96, as specified in NIST-SP800-38B [NIST-SP800-38B]. Therefore, TCP-AO meets the algorithm agility requirement ✅

There is a need to protect the authenticity and validity of the routing/label information carried in the payload of the sessions. However, that's outside the scope of this document and is being addressed by the SIDR WG. Similar mechanisms could be used for intra-domain protocols 👀

Finally, replay protection is required 🔁 The replay mechanism needs to be sufficient to stop an attacker from creating a denial of service or disrupting the integrity of the routing protocol by replaying packets. It's important that an attacker can't disrupt service by capturing packets and waiting for replay state to be lost.

4.1. LDP

As described in LDP [RFC5036], the threat of spoofed Basic Hellos can be reduced by only accepting Basic Hellos on interfaces that LSRs trust, employing GTSM [RFC5082], and ignoring Basic Hellos not addressed to the "all routers on this subnet" multicast group.

Spoofing attacks via Targeted Hellos are potentially a more serious threat 😬 An LSR can reduce the threat of spoofed Extended Hellos by filtering them and accepting Hellos from sources permitted by access lists. However, filtering with access lists requires LSR resources, and the LSR is still vulnerable to IP source address spoofing. Spoofing attacks can be solved by being able to authenticate the Hello messages, and an LSR can be configured to only accept Hello messages from specific peers when authentication is in use.

LDP Hello Cryptographic Authentication [HELLO-CRYPTO] suggests a new Cryptographic Authentication TLV that can be used as an authentication mechanism to secure Hello messages 🔐

4.2. PCEP

Path Computation Element (PCE) discovery, according to [RFC5440], is a significant feature for the successful deployment of PCEP in large networks ✨ This mechanism lets a Path Computation Client (PCC) discover suitable PCEs within the network without needing any configuration. It should be obvious that, where PCEs are discovered and not configured, the PCC cannot know the correct key to use 🙃 There are different approaches to keep some aspect of security, but all of them require the use of keys and a keying mechanism, the need for which has been discussed above.

5. Transition and Deployment Considerations 🦋

As stated in the KARP Design Guidelines [RFC6518], it is imperative that the new authentication, security mechanisms, and key management protocol support incremental deployment, because it's not feasible to deploy the new routing protocol authentication mechanism overnight 🌙

Typically, authentication and security in a peer-to-peer protocol requires that both parties agree to the mechanisms that will be used. If an agreement isn't reached, the setup of the new mechanism will fail or be deferred. Upon failure, the routing protocols can fall back to the mechanisms that were already in place, e.g., use static keys if that was the mechanism in place. The fallback should be configurable on a per-node or per-interface basis. It's usually not possible for one end to use the new mechanism while the other end uses the old. Policies can be put in place to retry upgrading after a said period of time, so manual coordination isn't required 🫶

If the automatic KMP requires use of Public Key Infrastructure Certificates [RFC5280] to exchange key material, the required Certificate Authority (CA) root certificates may need to be installed to verify the authenticity of requests initiated by a peer. That step doesn't require coordination with the peer, except to decide which CA authority will be used 🏆

6. Security Considerations 🔐

this section is super important, so read it closely bestie 🚨

This section describes security considerations that BGP, LDP, PCEP, and MSDP should try to meet. As with all routing protocols, they need protection from both on-path and off-path blind attacks 😈 A better way to protect them would be with per-packet protection using a cryptographic MAC. To provide for the MAC, keys are needed.

The routing protocols need to support algorithm agility, i.e., they must not hardwire themselves to one algorithm 🧩

Once keys are used, mechanisms are required to support key rollover. They should cover both manual and automatic key rollover. Multiple approaches could be used. However, since the existing mechanisms provide a protocol field to identify the key, as well as management mechanisms to introduce and retire new keys, focusing on the existing mechanism as a starting point is prudent 📋

Furthermore, it is strongly suggested that these routing protocols support algorithm agility. It has been proven that algorithms weaken over time. Supporting algorithm agility assists in smooth transitions from old to new algorithms 🔄

7. Acknowledgements 🧚

we would like to thank Brian Weis for encouraging us to write this document, and thanks to Anantha Ramaiah and Mach Chen for providing comments on it 🫶

8. References 📚

8.1. Normative References

[RFC5926]  Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
           for the TCP Authentication Option (TCP-AO)", RFC 5926,
           June 2010.

[RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
           Routing Protocols (KARP) Design Guidelines", RFC 6518,
           February 2012.

[RFC6863]  Hartman, S. and D. Zhang, "Analysis of OSPF Security
           According to the Keying and Authentication for Routing
           Protocols (KARP) Design Guide", RFC 6863, March 2013.

8.2. Informative References ✨

okay bestie, this is the reading list 📚💅 these are the extra docs the spec leans on for background, not the must-reads, but they're the receipts for everything the main text is referencing 🫶

• [HELLO-CRYPTO] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", Work in Progress, January 2013. 🔐
• [NIST-SP800-38B] Dworking, , "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", May 2005. 🧁
• [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. 🔑
• [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. 🛡️
• [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 🚇
• [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. 📡
• [RFC4271] Rekhter, Y., Li, T., and S. Hares, "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. 🏰
• [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006. 🧩
• [RFC4674] Le Roux, J.L., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006. 🗺️
• [RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 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. 🗑️
• [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007. 👀
• [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. 🏷️
• [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. ⏱️
• [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. 🔎
• [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. 🔍
• [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. 📜
• [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. 💬
• [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. 🧱
• [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. 🪪
• [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010. 💪
• [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 🗝️
• [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010. 🧐
• [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011. 🕰️
• [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. 🏛️

---

Authors' Addresses 🎀

and that's the whole squad! here's how to reach each of them 💖

Mahesh Jethanandani
Ciena Corporation
1741 Technology Drive
San Jose, CA  95110
USA

Phone: +1 (408) 436-3313
EMail: mjethanandani@gmail.com

Keyur Patel
Cisco Systems, Inc
170 Tasman Drive
San Jose, CA  95134
USA

Phone: +1 (408) 526-7183
EMail: keyupate@cisco.com

Lianshu Zheng
Huawei Technologies
China

Phone: +86 (10) 82882008
EMail: vero.zheng@huawei.com