RFC 6518

Keying and Authentication for Routing Protocols (KARP) Design Guidelines

📅 published February 2012, from ietf

Keying and Authentication for Routing Protocols (KARP) Design Guidelines 🎀

okay bestie, the title block is serving everything 💅 This is RFC 6518, and it's a Design Guidelines doc for KARP (Keying and Authentication for Routing Protocols). G. Lebovitz and M. Bhatia wrote it while at Alcatel-Lucent, and it came out in February 2012. It's an Informational doc (ISSN 2070-1721), so it's not a Standards Track spec. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

Abstract ✨

so this doc is one of a series mapping out how routing protocols can use modern crypto for message authentication. the big idea is that it lays out the framework for a key management protocol, which is the thing that creates and manages session keys for authentication and integrity 🔐

Status of This Memo 🌸

quick reality check: this one is not an Internet Standards Track spec. it's published just to share info 🙈

it's still an IETF product, which means it reflects the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). ngl though, not every IESG-approved doc is up for any level of Internet Standard. see Section 2 of RFC 5741 for the deets ✨

for the latest status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6518 🍓

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. please read these carefully, bestie, because they spell out your rights and restrictions for this doc 📜

one more thing: any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they're provided without warranty, as the Simplified BSD License describes 🔥

Table of Contents 🧚

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................4
   2. Categorizing Routing Protocols ..................................5
      2.1. Category: Message Transaction Type .........................5
      2.2. Category: Peer versus Group Keying .........................6
   3. Consider the Future Existence of a Key Management Protocol ......6
      3.1. Consider Asymmetric Keys ...................................7
      3.2. Cryptographic Keys Life Cycle ..............................8
   4. Roadmap .........................................................9
      4.1. Work Phases on Any Particular Protocol .....................9
      4.2. Work Items per Routing Protocol ...........................11
   5. Routing Protocols in Categories ................................13
   6. Supporting Incremental Deployment ..............................16
   7. Denial-of-Service Attacks ......................................17
   8. Gap Analysis ...................................................18
   9. Security Considerations ........................................20
      9.1. Use Strong Keys ...........................................21
      9.2. Internal versus External Operation ........................22
      9.3. Unique versus Shared Keys .................................22
      9.4. Key Exchange Mechanism ....................................24
   10. Acknowledgments ...............................................26
   11. References ....................................................26
       11.1. Normative References ....................................26
       11.2. Informative References ..................................26

1. Introduction ✨

okay so back in March 2006, the Internet Architecture Board (IAB) ran a workshop on "Unwanted Internet Traffic" 👀 the report from that workshop is RFC 4948 [RFC4948]. its Section 8.1 says that "A simple risk analysis would suggest that an ideal attack target of minimal cost but maximal disruption is the core routing infrastructure". Section 8.2 then calls for "[t]ightening the security of the core routing infrastructure". 💀 Four main steps were named for that tightening:

  • Increase the security mechanisms and practices for operating routers.
  • 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.
  • 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 should be handled through liaisons with the folks who run the IRRs globally. the third is being handled in the SIDR working group 🫶

this document is all about the last bullet: securing the packets on the wire during routing protocol exchanges. so it's about guidelines for describing the issues and techniques for protecting messages between directly communicating peers. this may overlap with protection that makes sure routing information is properly authorized relative to its sources, but it's strongly distinct from that. those authorizations come from other mechanisms and are outside the scope of this doc and the work that relies on it 🦋

the phrase "on the wire" gets used a bunch in RFCs, and it's used in a few different ways. here, it refers both to information exchanged between routing protocol instances and to underlying protocols that might also need protecting in certain situations. other docs that analyze individual protocols will need to say how they use "on the wire" themselves 🌈

the term "routing transport" refers to the layer that carries the routing protocols. that can be TCP, UDP, or even direct link-level messaging for some routing protocols. the term is here so we have one referent for talking about the common and different issues that affect or interact with this part of routing systems. it refers generally to the mechanisms and exchanges underneath the routing protocol, whatever that happens to be in a specific case ✨

now the main vibe: KARP is going to focus on an abstraction for keying information. it describes the interface between routing protocols, operators, and automated key management. conceptually, when routing protocols send or receive messages, they look up the key to use in this abstract key table. there's also an interface for a routing protocol to make requests of automated key management when it's in use. when keys become available, they get put into the key table. there's no requirement that this abstraction be used in implementations, since it serves the needs of standardization and management 🧠 specifically, KARP's work plan has three parts:

  1. KARP will design the key table abstraction, the interface between key management protocols and routing protocols, and possibly security protocols at other layers.
  2. For each routing protocol, KARP will define the mapping between how the protocol represents key material and the protocol-independent key table abstraction. when routing protocols share a common authentication mechanism, such as the TCP Authentication Option, the same mapping is likely to be reused across protocols. an implementation may be able to move much of the keying logic into code tied to this shared authentication primitive, instead of code specific to routing protocols 💖
  3. When designing automated key management for both symmetric keys and group keys, we will only use the abstractions designed in point 1 above to communicate between automated key management and routing protocols.

readers must refer to [THTS-REQS] for a clear definition of the scope, goals, non-goals, and audience for the design work happening in the KARP WG 📖

1.1. Conventions Used in This Document 💅

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] 🎀

2. Categorizing Routing Protocols 🦋

this doc sorts the routing protocols into two categories based on their authentication requirements. the goal is to help design teams focus on security mechanisms for a given category. we also hope each protocol in a group can reuse the same authentication mechanism 🫶 down the road, we're hoping to create one Key Management Protocol (KMP) per category, or at least for several categories, so the work can be easily leveraged across the different routing protocol groupings 🌸

KMPs are useful because they allow simple, automated updates of the traffic keys used in a base protocol. they replace the need for humans, or operational support systems (OSS) routines, to periodically replace keys on running systems. they also remove the need for a chain of manual keys to be picked or configured on those systems. when a KMP is configured properly, it enforces the key freshness policy among peers by tracking each key's lifetime and negotiating a new key at the defined interval ⭐

2.1. Category: Message Transaction Type 💌

okay so category one is all about the message transaction type, aka how routers actually send their messages on the wire. there are three flavours 🎀

One-to-One 💖

one peer router directly and intentionally sends a route update to one specific other peer router. the examples are BGP [RFC4271], LDP [RFC5036], BFD [RFC5880], and RSVP-TE [RFC3209], [RFC3473], [RFC4726], and [RFC5151]. point-to-point modes of both IS-IS [RFC1195] and OSPF [RFC2328] can also land in this bucket, whether they're running over traditional point-to-point links or over multi-access layers 🦋

One-to-Many 🌸

a router peers with several other routers on a single network segment (so, on link local) and creates and sends ONE route update message that's meant for all of them. OSPF and IS-IS in their broadcast, non-point-to-point mode fit here, and so does the Routing Information Protocol (RIP) [RFC2453] 🧚

Multicast 🔥

multicast protocols have their own unique security properties because they're inherently group-based. so they have group keying requirements at the routing level, where the link-local routing messages get multicasted. also, at least for Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601], some messages are sent unicast to a given peer or peers, like the router-close-to-sender and the "Rendezvous Point" 👑 the Multicast Security (MSEC) working group did some work on application-layer message security that's worth a look, but it isn't directly applicable here 💅

these categories affect both the routing protocol's view of the communication AND the actual message transfer. so some message transaction types for a few routing protocols end up being mixtures 🫶 for example, using broadcast where you'd expect multicast, or using unicast to deliver what looks to the routing protocol like broadcast or multicast. wild, right? 😭

protocol security analysis docs produced in the KARP working group need to pay attention to both the semantics of the communication AND the techniques used for the message exchanges 🌈

2.2. Category: Peer versus Group Keying 🔑

the second category is the keying mechanism used to distribute the session keys to the routing transports. there are two of them 🍓

Peer Keying 💜

one router sends the keying messages only to one other router, so a one-to-one, uniquely keyed security association (SA) gets established between the two. this is the setup for BGP, BFD, and LDP (e.g.) ✨

Group Keying 🌈

one router creates and distributes a single keying message to multiple peers. in this case, a group SA gets established and used among multiple peers simultaneously 💫 group keying exists for protocols like OSPF [RFC2328], and for multicast protocols like PIM-SM [RFC4601] 🎀

3. Consider the Future Existence of a Key Management Protocol 🗝️

when the KARP WG gets around to designing a reusable model for a Key Management Protocol (KMP), [RFC4107] should be consulted. bookmark that one bestie 📌

when you're doing the design work on a manually keyed version of a routing protocol's authentication mechanism, consideration must be made for the eventual use of a KMP. specifically, design teams need to think about what parameters would have to be handed to the routing protocols by a KMP 🧠

examples of parameters that might need to be passed are: a security association identifier (e.g., IPsec Security Parameter Index (SPI) or the TCP Authentication Option's (TCP-AO's) KeyID), a key lifetime (which may be represented in either bytes or seconds), the cryptographic algorithms being used, the keys themselves, and the directionality of the keys (i.e., receiving versus the sending keys) 🌸

3.1. Consider Asymmetric Keys 🦄

asymmetric keys can be a super powerful way to authenticate machine peers in routing protocol peer exchanges 💪 if they're generated on the machine and never moved off it, these keys won't need to change if an administrator leaves the organization. and since the keys are random, they're way less susceptible to off-line dictionary and guessing attacks 🙈

an easy way to use asymmetric keys is to start with the router generating a public/private key pair. at the time of writing, the recommended key size for algorithms based on integer factorization cryptography like RSA is 1024 bits, and 2048 bits for extremely valuable keys like the root key pair used by a certification authority. it's believed that a 1024-bit RSA key is equivalent in strength to 80-bit symmetric keys, and 2048-bit RSA keys to 112-bit symmetric keys [RFC3766] 🧮 Elliptic Curve Cryptography (ECC) [RFC4492] appears to be secure with shorter keys than the ones needed by other asymmetric key algorithms ✨ the National Institute of Standards and Technology (NIST) guidelines [NIST-800-57] say ECC keys should be twice the length of equivalent strength symmetric key algorithms. so a 224-bit ECC key would roughly have the same strength as a 112-bit symmetric key 🫧

many routers can be remotely managed using Secure Shell (SSH) Protocol [RFC4252] and [RFC4253]. so routers will also be able to generate and store an asymmetric key pair, because that's the common authentication method SSH uses when an administrator connects to a router for management sessions 🖥️

once an asymmetric key pair is generated, the KMP that's generating the security association parameters and keys for the routing protocol may use the machine's asymmetric keys for the authentication mechanism. the form of the identity proof could be raw keys, the more easily administrable self-signed certificate format, or a PKI-issued [RFC5280] certificate credential 🎀

regardless of which credential gets standardized, the authentication mechanism can be as simple as a strong hash over a string of human-readable and transferable ASCII characters 🌷 more complex, but also more secure, the identity proof could be verified through a PKI system's revocation checking mechanism (e.g., Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) responder) 🛡️ if the SHA-1 fingerprint is used, the solution could be as simple as loading a set of neighbor routers' peer ID strings into a table and listing the associated fingerprint string for each ID string 📋 in most organizations or peering points, this list won't be longer than a thousand or so routers, and often it'll be way shorter 🍭 in other words, the entire list for a given organization's router ID and hash could be held in a router's configuration file, and uploaded, downloaded, and moved about at will 🚀 and honestly? it doesn't matter who sees or gets access to these fingerprints, because they can be distributed publicly. they don't need to be kept secret 🤷‍♀️✨

3.2. Cryptographic Keys Life Cycle ⏳

cryptographic keys should have a limited lifetime, and may need to be changed when an operator who had access to them leaves. using a key chain (a set of keys derived from the same keying material and used one after the other) also doesn't help, because you still have to change all the keys in the chain when an operator with access to all of them leaves the company 😬 key chains won't help either if the routing transport subsystem doesn't support rolling over to new keys without bouncing the routing sessions and adjacencies. so the first step is to fix the routing stack so routing protocols can change keys without breaking or bouncing the adjacencies 🔧

a commonly cited reason for limiting a key's lifetime is to minimize the damage from a compromised key. it could be argued that a user probably won't discover an attacker has compromised the key if the attacker stays "passive". so relatively frequent key changes will limit any potential damage from compromised keys 🕵️‍♀️

another threat against a long-lived key is that one of the systems storing it, or one of the users entrusted with it, gets subverted. so even if there aren't cryptographic reasons to change the keys, there could be system security reasons for rolling the key 🔐

manual key distribution methods are subject to human error and frailty, and more frequent manual key changes might actually increase the risk of exposure. that's because it's during the time the keys are being changed that they're likely to be disclosed 😱 in these cases, especially when very strong cryptography is employed, it may be more prudent to have fewer, well-controlled manual key distributions rather than more frequent, poorly controlled ones. in general, where strong cryptography is employed, physical, procedural, and logical access protection considerations often have more impact on the key life than algorithm and key size factors do 💀

for incremental deployments, we could start by associating lifetimes with the send and the receive keys in the key chain for the long-lived keys. this is an incremental approach we could use until the cryptographic keying material for individual sessions is derived from the keying material stored in a database of long-lived cryptographic keys, as described in [CRPT-TAB] 🧩 a key derivation function (KDF) and its inputs are also specified in the database of long-lived cryptographic keys, and session-specific values based on the routing protocol are input to the KDF. protocol-specific key identifiers may be assigned to the cryptographic keying material for individual sessions if needed 🌟

the long-lived cryptographic keys used by the routing protocols can either be inserted manually into a database, or make use of an automated key management protocol to do this 🤖

4. Roadmap 🗺️

4.1. Work Phases on Any Particular Protocol

okay so the plan is that securing any routing protocol is gonna be a two-phase glow-up ✨ Phase one is updating routing protocols so they can use modern crypto algorithms and key agility 💅 Phase two is designing and moving to an automated key management mechanism 🤖 It's giving crawl, walk, run 🏃‍♀️ Operators need to be able to accept these phases, and we think the key management protocol should be clearly separated from the routing transport 🫶 That means the routing transport subsystem doesn't care how the keys get derived, exchanged, and downloaded, as long as there's something it can use. Picture a routing-protocol-configuration switch that asks the security module for the "KARP security parameters" so it can point at a module written, maintained, and operated by security experts and drop those parameters into the routing exchange 🧚

The desired end state for KARP has a few parts 🌸 First, the people who want securely authenticated and integrity-validated packets between routing peers need tools that are specified, implemented, and shipped so they can actually deploy them 📦 These tools should be fairly simple to implement and no more complex than the security mechanisms router operators already know. (Examples of those mechanisms include: asymmetric keys for authentication in SSH for router configuration, pre-shared keys (PSKs) in TCP MD5 for BGP protection, self-signed certificates for HTTP Secure (HTTPS) access to device Web-based user interfaces, and strongly constructed passwords and/or identity tokens for user identification when logging into routers and management systems.) Real talk, the tools we're specifying may not be able to stop a deployment from using "foobar" as an input key on every device across its entire routing domain 🙈 But we intend to make a solid, modern security system that isn't too much harder than that. So simplicity and deployability are the keys to success 🔑 The routing protocols will specify modern cryptographic algorithms and security mechanisms. Routing peers will be able to use unique, pair-wise keys per peering instance, with reasonable key lifetimes, and updating those keys on a regular basis will be operationally easy and cause no service interruption 💖

Achieving that end state with manual keys may only be pragmatic in very small deployments 🍓 Manual keying in larger deployments is gonna be too burdensome for operators, so the second goal is supporting key life cycle management with a KMP 💜 We expect manual and automated key management to coexist in the real world.

So, in line with the end state we just described, we define two main work phases for each routing protocol ✨

  1. Enhance the routing protocol's current authentication mechanism(s). This work involves enhancing a routing protocol's current security mechanisms so it reaches a consistent, modern level of security functionality within its existing key management framework 💅 It's understood and accepted that those existing frameworks are mostly based on manual keys. Since many operators have already built operational support systems (OSS) around these manual key implementations, there's some automation an operator can leverage that way, if the underlying mechanisms are themselves secure 🔐 In this phase, we explicitly exclude embedding or creating a KMP. Refer to [THTS-REQS] for the list of requirements for Phase 1 work 🎀
  2. Develop an automated key management framework. The second phase focuses on building an automated keying framework that gives unique pair-wise (group-wise, where applicable) keys per peering instance. This involves the use of a KMP 🤖 Automatic key management offers a bunch of perks over manual keying. Most important, it provides fresh traffic keying material for each session, which helps prevent inter-connection replay attacks 🛡️ In an inter-connection replay attack, protocol packets from an earlier protocol session get replayed and mess with the current execution of the protocol 😭 A KMP is also super helpful because it negotiates unique, pair-wise, random keys without administrator involvement 🙌 It negotiates several SA parameters, like algorithms, modes, and parameters required for the secure connection, which gives interoperability between endpoints with disparate capabilities and configurations 🦋 It could also include negotiating the key lifetimes. The KMP can keep track of those lifetimes using counters and negotiate new keys and parameters before they expire, again without administrator interaction ⏰ And if there's a breach, changing the KMP key will immediately cause a rekey for the traffic key, and those new traffic keys get installed and used in the current connection 🚨 In summary, a KMP provides a protected channel between the peers, where they can negotiate and pass the important data needed to exchange proof of identities, derive traffic keys, determine rekeying, synchronize their keying state, signal various keying events, notify each other with error messages, etc. 👑

4.2. Work Items per Routing Protocol

Each routing protocol gets a team (the Routing_Protocol-KARP team, e.g., the OSPF-KARP team) that works on incrementally improving the security of that protocol 🧚 These teams have the following main work items 💅

PHASE 1:

  • Characterize the Routing Protocol: Assess the routing protocol to see what authentication and integrity mechanisms it has today. Does it need significant improvement to its existing mechanisms or not? This includes figuring out whether modern, strong security algorithms and parameters are present, and whether the protocol supports key agility without bouncing adjacencies 🔍
  • Define Optimal State: List the requirements for the routing protocol's session key usage and format so it contains modern, strong security algorithms and mechanisms, per the Requirements document [THTS-REQS]. The goal is to determine what's needed for the routing protocol to be used securely with at least manual key management 🎯
  • Gap Analysis: Enumerate the requirements for this protocol to move from its current security state, the first bullet, to its optimal state, as listed just above 📝
  • Transition and Deployment Considerations: Document the operational transition plan for moving from the old security mechanism to the new one. Will adjacencies need to bounce? What new elements/servers/services in the infrastructure will be required? What's an example workflow an operator will take? The best possible case is that the adjacency doesn't break, but that may not always be possible 🥺
  • Define, Assign, Design: Create a deliverables list of the design and specification work, with milestones. Define owners. Release one or more documents 📚

PHASE 2:

  • KMP Analysis: Review requirements for KMPs. Identify any nuances for this particular routing protocol's needs and its use cases for a KMP. List the requirements that this routing protocol has for being used in conjunction with a KMP. Define the optimal state and check how easily it can be decoupled from the KMP 🧩
  • Gap Analysis: Enumerate the requirements for this protocol to move from its current security state to its optimal state, with respect to key management 📝
  • Define, Assign, Design: Create a deliverables list of the design and specification work, with milestones. Define owners. Generate the design and document work for a KMP to be able to generate the routing protocol's session keys for the packets on the wire. These will be the arguments passed in the API to the KMP in order to bootstrap the session keys for the routing protocol 🔑

There will also be a team formed to work on the base framework mechanisms for each of the main categories 🌈

5. Routing Protocols in Categories ✨

okay so this section sorts the routing protocols into categories based on the attributes from the Categories section (Section 2) 🧚. Each group gets its own design team. Their job is to make the routing protocol mechanisms more secure, define the KMP requirements for their group, and then roll both into a roadmap document they'll follow 💅.

BGP, LDP, PCEP, and MSDP

these protocols are in the one-to-one peering messages category and will use peer keying protocols 💜. Border Gateway Protocol (BGP) [RFC4271], Path Computation Element Communication Protocol (PCEP) [RFC5440], and Multicast Source Discovery Protocol (MSDP) [RFC3618] messages all go over TCP, but Label Distribution Protocol (LDP) [RFC5036] uses both UDP and TCP 🌸. One team will work on one mechanism to cover these TCP unicast protocols. A lot of the work on updating the routing protocol's existing authentication mechanism has already happened in the TCPM working group, through the TCP-AO [RFC5925] document and its cryptography-helper document, TCP-AO-CRYPTO [RFC5926] ✨. BUT, TCP-AO can't be used for LDP's discovery exchanges because those ride on UDP 😭. A separate team might want to look at LDP. Another exception is the mode where LDP is used directly on the LAN. That work may go into the group keying category (along with OSPF), as mentioned below 🦋.

OSPF, IS-IS, and RIP

the routing protocols in the group keying category (one-to-many peering) are OSPF [RFC2328], IS-IS [RFC1195], and RIP [RFC2453] 🔥. Not surprising at all, these three have two more things in common. First, they run on a combo of the OSI datalink Layer 2 and the OSI network Layer 3. What we mean is that part of how the routing protocol works is specified in Layer 2 AND in Layer 3 🙈. Second, they're all internal gateway protocols (IGPs) 👑. The keying mechanisms are going to be way more complicated to define for these than for a one-to-one messaging protocol. it's giving a lot of plot twists 💀.

BFD

Bidirectional Forwarding Detection (BFD) [RFC5880] is less of a routing protocol per se and more of a peer liveness detection mechanism, so it gets its own team 🎀. It's also different from the others here because it works on millisecond timers, which means it needs separate thinking to reduce the potential for Denial-of-Service (DoS) attacks 😤. It also raises some interesting issues [RFC6039] with the sequence number scheme that's usually deployed to protect against replay attacks. That space can roll over pretty fast because BFD packets are generated at such a high rate 🌈.

RSVP and RSVP-TE

the Resource reSerVation Protocol (RSVP) [RFC2205] allows hop-by-hop authentication of RSVP neighbors, as specified in [RFC2747] ✨. In this mode, an integrity object gets attached to each RSVP message to carry a keyed message digest. The digest lets the receiver verify who sent the message and check that the message wasn't tampered with 🔐. Because a sequence number is included in the scope of the digest, the digest also gives replay protection 💖.

[RFC2747] doesn't dictate how the key for the integrity operation gets derived 🤷‍♀️. Right now, most RSVP implementations use a statically configured key, set per interface or per neighbor 🍓.

RSVP depends on a per-peer authentication mechanism, where each hop authenticates its neighbor using a shared key or a certificate 🫶.

Trust in this model is transitive 🔗. Each RSVP node explicitly trusts ONLY its RSVP next-hop peers, through the message digest in the INTEGRITY object [RFC2747]. Then the next-hop RSVP speaker trusts its own peers, and so on down the line 🧚. For more background, check out the document "RSVP Security Properties" [RFC4230] 📚.

The keys used to protect RSVP messages can be group keys. For example, they can be distributed via the Group Domain of Interpretation (GDOI) [RFC6407], as discussed in [GDOI-MAC] 🌟.

The trust one RSVP node has with another has an explicit part and an implicit part 💜. Explicitly, the node trusts the other node to maintain the integrity (and, optionally, the confidentiality) of RSVP messages, depending on whether authentication, encryption, or both are used. That means the message hasn't been altered, and its contents haven't been seen by some other non-trusted node 🙈. Implicitly, each node trusts the other to keep up the level of protection specified within that security domain. Also note that in any group key management scheme, like GDOI, each node trusts ALL the other members of the group for data origin authentication 👑.

RSVP-TE [RFC3209], [RFC3473], [RFC4726], and [RFC5151] is an extension of RSVP for traffic engineering 🚀. It supports reserving resources across an IP network, and it's used to set up MPLS label switch paths (LSPs). It takes network constraint parameters into account, like available bandwidth and explicit hops 🌸. RSVP-TE signaling is used to establish both intra-domain and inter-domain TE LSPs.

When signaling an inter-domain RSVP-TE LSP, operators may use the security features already defined for RSVP-TE [RFC3209]. This may require some coordination between domains to share keys ([RFC2747][RFC3097]), and care is required to make sure the keys get changed often enough 🔑. This can also involve extra synchronization if the domain border nodes are protected with Fast Reroute. That's because the merge point (MP) and point of local repair (PLR) should also share the key 🦋.

For inter-domain signaling for MPLS-TE, the administrators of neighboring domains must satisfy themselves that a suitable trust relationship exists between the domains 🤝. If there isn't one, the administrators should decide not to deploy inter-domain signaling and should disable RSVP-TE on any inter-domain interfaces 🙅‍♀️.

KARP will only be working on RSVP-TE for now, since native RSVP is outside the scope of the WG charter 💅.

PIM-SM and PIM-DM

last but not least, the multicast protocols Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] and Protocol Independent Multicast - Dense Mode (PIM-DM) [RFC3973] get grouped together 🌈. PIM-SM multicasts routing information (Hello, Join/Prune, Assert) on a link-local basis, using a defined multicast address ✨. It also uses unicast communication to exchange information (Register, Register-Stop) between the router closest to a group sender and the "Rendezvous Point". The Rendezvous Point is typically NOT "on-link" for a particular router 🙃.

Here's the tea: lots of work has been done on multicast security for application-layer groups, but very little has been done on managing hundreds or thousands of small one-to-many groups with link-local scope 😭. An authentication mechanism like that should be considered alongside the router-to-Rendezvous Point authentication mechanism. The most important issue is making sure ONLY the "authorized neighbors" get the keys for source/group (S,G), so rogue routers can't join the exchanges 🚫. Another issue is that some communication may happen intra-domain (like the link-local messages in an enterprise), while other messages for the same (*,G) may happen inter-domain (like router-to-Rendezvous Point messages going from one enterprise's router to another's) 🏢.

One possible solution proposes a region-wide "master" key server (possibly replicated), with one "local" key server per speaking router 🗝️. There's no issue with propagating messages outside the link, because link-local messages, by definition, aren't forwarded. BUT this solution is only offered as an example of how the work might progress. Further discussion should happen in this work team 💬. Specification of a link-local protection mechanism for PIM-SM is defined in [RFC4601], and that mechanism has been updated in PIM-SM-LINKLOCAL [RFC5796]. However, the KMP part is completely unspecified and will need work outside the expertise of the PIM working group. That's another example of why this roadmap is being created 🗺️✨.

6. Supporting Incremental Deployment

it is IMPERATIVE that the new authentication and security mechanisms support incremental deployment, because it isn't feasible to roll out a new routing protocol authentication mechanism across the whole network instantly 🕰️. One of the goals of the KARP WG is to add incremental security to existing mechanisms rather than replacing them 🫶. Delivering better, deployable solutions that vendors and operators can migrate to matters more than getting a perfect security solution 💖. It also may not be possible to deploy such a mechanism to every router in a large Autonomous System (AS) at once 🏗️. So designers have to work on this aspect of the authentication mechanism for whatever routing protocol they're working on 🧠. The mechanisms must provide backward compatibility in the message formatting, transmission, and processing of routing information carried through a mixed security environment 🌸👑.

7. Denial-of-Service Attacks 💀

okay bestie, DoS attacks have to be on your mind the whole time you're designing KARP solutions 🙈 [THTS-REQS] lists the DoS attacks that are in scope for the KARP work. Protocol designers should make sure the new cryptographic validation mechanisms don't give an attacker a chance to DoS anything 😭. Validation is usually cheaper than signing, but it's still a cost 💅. If an attacker can force a system to validate lots of packets over and over, that's a potential DoS attack vector 🚨. The flip side is just as bad: if the authentication procedure is already super CPU-intensive, then flooding the CPU with bogus packets can take the whole system down. In that case the authentication procedure itself is helping the attacker 💀.

There are some known techniques to lower the cryptographic computation load ✨. Packets can include non-cryptographic consistency checks. For example, [RFC5082] uses the IP header to limit which attackers can inject packets that will be subject to cryptographic validation 🦋. In the design, Phase 2, once an automated key management protocol is developed, it may be possible to work out the peer IP addresses that are valid participants. Then only packets from verified sources could be subject to cryptographic validation 🫶.

Protocol designers must ensure that a device never needs to check incoming protocol packets using multiple keys, because that can overwhelm the CPU and lead to a DoS attack 🔥. KARP solutions should indicate the checks that are appropriate before cryptographic validation happens. KARP solutions should also indicate where information about valid neighbors can be used to limit the scope of attacks 🌸.

Automated key management schemes need extra care, periodt 👑. It's often desirable to force a party trying to authenticate to do work and to keep state until that work is done. In other words, the initiator of the authentication should be the one maintaining the cost of any state the authentication needs, for as long as possible. This also helps when an attacker sends an overwhelming load of keying protocol initiations from bogus sources 🧚.

Another important class of attack is denial of service against the routing protocol, where an attacker manipulates either the routing protocol or the cryptographic authentication mechanism to disrupt routing adjacencies 💜.

Without KARP solutions, lots of routing protocols can be knocked over just by injecting an invalid packet or a packet meant for the wrong state 😩. Even with cryptographic validation, replay attacks are often the vector, where a previously valid packet gets injected to cause a denial of service 🙃. KARP solutions should prevent all cases where packet replays or other packet injections by an outsider can disrupt routing sessions 🛡️.

Some residual denial-of-service risk is always likely, sorry not sorry 🥲. If an attacker can generate a large enough number of packets, the routing protocol can get disrupted. Even when the routing protocol isn't disrupted, the loss rate on a link may climb to the point where saying traffic can successfully be routed across that link would be inaccurate 📉.

8. Gap Analysis 🔍

The [THTS-REQS] document lists the generic requirements for the security mechanisms that must exist for the various routing protocols under the KARP umbrella 🎀. There will be different design teams working on each of the categories of routing protocols that have been defined.

To start, design teams must review the "Threats and Requirements for Authentication of routing protocols" document [THTS-REQS] 📖. It has detailed descriptions of the threat analysis for routing protocol authentication and integrity in general. Note that it does not cover every authentication-related threat for any one routing protocol, or any category of routing protocols. So the design team has to run a protocol-specific threat analysis to find out if threats beyond those in [THTS-REQS] show up in the context of the protocol (group), and then describe them 🕵️‍♀️.

The [THTS-REQS] document also has a lot of security requirements 📋. Each routing protocol design team needs to walk through each section of the requirements and figure out, one by one, how its protocol does or doesn't relate to each requirement.

Examples include modern, strong cryptographic algorithms, with at least one such algorithm listed as a MUST 💪, algorithm agility, secure use of simple PSKs, intra-connection replay protection, inter-connection replay protection, and so on 🌈.

When doing the gap analysis, we must first identify the elements of each routing protocol that we want to protect 🧐. For protocols riding on top of IP, we might want to protect the IP header and the protocol headers. For protocols that work on top of TCP, it will be the TCP header and the protocol payload. There is patently value in protecting the IP header and the TCP header if the routing protocols rely on those headers for some information, like identifying the neighbor that originated the packet 💅.

Then there's a set of cryptography requirements we might want to look at ✨. For example, there must be at least one set of cryptographic algorithms (MD5, SHA, etc.) or constructions (Hashed MAC (HMAC), etc.) whose use is supported by all implementations and can be safely assumed to be supported by any implementation of the authentication option. The design teams should look at the protocol they're working on. If no such algorithms or constructions are available, then some should be defined so that interoperability works by having a single default 🫶.

Design teams must make sure the default cryptographic algorithms and constructions the routing protocols support are accepted by the community 🤝. This means the protocols must not rely on non-standard or ad hoc hash functions, keyed-hash constructions, signature schemes, or other functions, and they must use published and standard schemes. No vibes-based crypto allowed 🙅‍♀️.

Care should also be taken to make sure the routing protocol authentication scheme has algorithm agility, meaning it can support algorithms other than its defaults 🦋. Ideally, the authentication mechanism should not be affected by packet loss and reordering 🌸.

Design teams should make sure their protocol's authentication mechanism can accommodate rekeying 🔑. This is essential, since it's well known that keys must be changed periodically. What the designers must also ensure is that a rekeying event does not affect how the routing protocol functions. For example, OSPF rekeying requires coordination among the adjacent routers, while IS-IS requires coordination among routers in the entire domain 🧩.

If new authentication and security mechanisms are needed, the design teams must design them so the routing protocol authentication mechanism stays oblivious to how the keying material is derived 🙈. This decouples the authentication mechanism from whichever key management system is used. Main character energy for sure 👑.

Design teams should also note that many routing protocols require prioritized treatment of certain protocol packets, and authentication mechanisms should honor that 🚀.

Not all routing protocol authentication mechanisms provide protection against replay attacks 😬. Design teams should identify those mechanisms and work on them so the gap gets fixed. They must look at the protocols they're working on and see whether packets captured from previous or stale sessions can be replayed 🔁.

The rate at which protocol packets are originated can also shape the design ⏱️. For protocols like BFD, where packets are originated at millisecond intervals, there are some special considerations to keep in mind when defining new authentication and security mechanisms 🍓.

Designers should also consider whether the current authentication mechanisms impose considerable processing overhead on a router doing authentication 🧠. Most currently deployed routers don't have hardware accelerators for cryptographic processing, and these operations can put a significant processing burden on them under some circumstances. Proposed solutions should be carefully evaluated for the processing burden they'll impose, because deployment may get blocked if network operators think a solution will either cost a lot in capital expenses or threaten to destabilize their routers 😭.

9. Security Considerations 🔐

As mentioned in the Introduction, RFC 4948 [RFC4948] identifies additional steps needed to reach the overall goal of improving the security of the core routing infrastructure ✨. Those include validating route origin announcements, path validation, cleaning up the IRR databases for accuracy, and operational security practices that stop routers from becoming compromised devices. The KARP work is just one step needed to improve core routing infrastructure 💖.

The security of cryptographic-based systems depends on both the strength of the cryptographic algorithms chosen and the strength of the keys used with those algorithms 🗝️. Security also depends on the engineering of the protocol the system uses, to make sure there are no non-cryptographic ways to get around the security of the overall system. Lowkey the most important part, so don't skip it 🚨.

9.1. Use Strong Keys 🔐

okay bestie, keys need to be lowkey unguessable 🔐 so care should be taken to make sure the one you pick is unpredictable, and that you avoid any keys known to be weak for the algorithm you're using. [RFC4086] has the tea on key generation and cryptographic randomness, so go read it 💅

Length matters too! 📏 [RFC3766] has some extra info on asymmetric and symmetric key sizes and how they connect to what your system needs for attack resistance 🎀

Besides using a key with the right length and randomness, deployers of KARP should use different keys between different routing peers whenever operationally possible 🦋 This is especially true when the routing protocol takes a static traffic key instead of a traffic key derived on a per-connection basis using a KDF. Doing that is understandably a lot more work than using the same static traffic key across all peering routers 😭 Depending on the specific KMP, it can be argued that using a KMP network-wide generally increases peer-wise security. Picture an attacker who learns or guesses the traffic key used by two peer routers. If that traffic key is only used between those two routers, the attacker has only compromised that one connection, not the entire network 🫶

Now, whenever you're using manual keys, it's best to design a system where a given pre-shared key (PSK) gets used in a KDF mixed with connection-specific material. That's how you generate session-unique (and therefore peer-wise) traffic keys ✨ Doing this gives you a few perks: the traffic keys used in the per-message authentication mechanism are peer-wise unique, it provides inter-connection replay protection, and if the per-message authentication mechanism covers some connection counter, you also get intra-connection replay protection. main character energy 👑

Quick heads-up: certain key derivation functions (e.g., KDF_AES_128_CMAC) as used in TCP-AO [RFC5926] have a pseudorandom function (PRF) inside the KDF that may require a key of a certain fixed size as an input 🧚

For example, AES_128_CMAC needs a 128-bit (16-byte) key as the seed. But for the convenience of the administrators, a specification may not want to require that a PSK be exactly 16 bytes 🙈 So instead, a specification may call for a key prep routine that can handle a variable-length PSK, one that might be less or more than 16 bytes (see [RFC4615], Section 3, as an example). That key prep routine would derive a key of exactly the required length, so it's suitable as a seed to the PRF. This does NOT mean that administrators are safe to use weak keys! ⚠️ Administrators are encouraged to follow [RFC4086] [NIST-800-118]. We simply attempted to "put a fence around stupidity" as much as possible, because it's hard to imagine administrators typing in a password that is, say, 16 bytes in length 💀

A better option, from a security perspective, is to use some representation of a device-specific asymmetric key pair as the identity proof, as described in section "Unique versus Shared Keys" section. 🔥

9.2. Internal versus External Operation 🌐

Design teams have to figure out whether the protocol is an internal routing protocol or an external one. In other words, does it mostly run between peers inside a single domain of control, or between two different domains of control? 🤔 Some protocols get used in both cases, so the same protocol might need different modes of authentication operation. While it's preferred that all routing exchanges run with the best security mechanisms enabled in every deployment context, this exhortation is extra strong for protocols running on inter-domain point-to-point links. It's strongest of all for those on shared access link layers where several different domains interchange together, because there are more attackers coming from the outside 😈 Note, however, that the consequences of internal attacks maybe no less severe (in fact, they may be quite a bit more severe) than an external attack 😬

A classic example of this internal versus external vibe is BGP, which has both EBGP and IBGP modes 🎀 Another example is a multicast protocol where the neighbors are sometimes inside a domain of control and sometimes at an inter-domain exchange point. For PIM-SM running on an internal multi-access link, it would be acceptable to give up some security for some convenience by using a group key among the peers on the link 🫧 On the flip side, for PIM-SM running over a multi-access link at a public exchange point, operators may favor security over convenience by using unique pair-wise keys for every peer 🔐 Designers must consider both modes of operation and make sure the authentication mechanisms fit both 💖

Operators are encouraged to run cryptographic authentication on all their adjacencies, but to work from the outside in 🚪 In other words, External BGP (EBGP) links are a higher priority than the Internal BGP (IBGP) links, because they're externally facing and, as a result, more likely to be targeted in an attack 🎯

9.3. Unique versus Shared Keys 🗝️

This section talks about when it's appropriate to use the same authentication key inputs for multiple peers, and when it's not. Honestly, this is largely a debate of convenience versus security 😤 It's often the case that the best secured mechanism is also the least convenient mechanism. For example, an air gap between a host and the network absolutely prevents remote attacks on the host, but having to copy and carry files using the "sneaker net" is quite inconvenient and doesn't scale 🏃‍♀️💨

Operators have erred on the side of convenience when it comes to securing routing protocols with cryptographic authentication. Many don't use it at all. Some use it only on external links, but not on internal links. Those that do use it often use the same key for all peers in a network 🙃 It's super common to see the same key in use for years, e.g., the key was entered when authentication mechanisms were first configured or when the routing gear got deployed 📆

One goal for designers is to create authentication and integrity mechanisms that are easy for operators to deploy and manage, and that still use unique keys between peers (or small groups on multi-access links) and for different sessions among the same peers ✨ Operators have the impression that they NEED one key shared across the network, when, in fact, they do not 🙅‍♀️ What they really need is the relative convenience they get from deploying cryptographic authentication with one key (or a few keys), compared to the inconvenience they'd get from deploying the same authentication mechanism with unique pair-wise keys. An example is BGP route reflectors. Here, operators often use the same authentication key between each client and the route reflector. The roadmaps defined from this guidance document should allow for unique keys to be used between each client and the peer, without sacrificing much convenience 🌸 Designers should strive to deliver peer-wise unique keying mechanisms with similar ease-of-deployment properties to today's one-key method 💅

Operators must understand the consequences of using the same key across many peers 😳 One argument against it: if the same key is used in multiple devices, then a compromise of any one of those devices will expose the key. Also, since the same key is supported on many devices, lots of people know it, which affects how it gets distributed to all of the devices 🫠

Also consider the attack consequence size, meaning the amount of routing adjacencies that can be negatively affected once a breach has occurred, i.e., once the keys have been acquired by the attacker 📉

Again, if a shared key is used across the internal domain, then the consequence size is the whole network 💀 Ideally, unique key pairs would be used for each adjacency 💜

In some cases, shared keys are needed because of the problem space. For example, a multicast packet is sent once but then consumed by several routing neighbors. If unique keys were used per neighbor, the benefit of multicast would be erased, because the sender would have to create a different announcement packet for each receiver 🙀 Though this may be desired and acceptable in some small number of use cases, it isn't the norm. Shared (i.e., group) keys are an acceptable solution here, and much work has already been done in this area (by the MSEC working group) 🌈✨ the MSEC WG did the homework, slay ✨🌈

9.4. Key Exchange Mechanism ✨

Okay bestie, this section is all about how keys actually get into the routers 🔑 and it's giving "pick your fighter." There are two options: an out-of-band mechanism or a KMP. ✨

An out-of-band mechanism means operators set keys on the device with a configuration tool or management method (e.g., Simple Network Management Protocol (SNMP), Network Configuration Protocol (NETCONF)) 🛠️. A KMP is an automated protocol that swaps keys with no operator intervention 🤖. KMPs can run in-band to the routing protocol or out-of-band to it (meaning a totally different protocol) 🦋.

An out-of-band example: an admin SSHes into a router 💻 and types in the keying info by hand, like the algorithm, the key(s), the key lifetimes, etc. 🙈 Another example is an OSS system that feeds in the same info using a script over an SSH connection, or pushes config through some other management connection, whether it's standard (NETCONF-based) or proprietary 🌸.

Now the drawbacks of out-of-band config, and ngl they're a lot 😭. It's not scalable, it's complicated, and it's slow to change if a security breach is suspected 💀. Like, if an employee with key access gets terminated, or a machine holding the keys is believed to be compromised, the system is considered insecure and vulnerable until new keys are generated and distributed 🚨. Then those keys have to go into the OSS system, and the OSS system has to push them into the relevant devices, often during a very limited change window ⏰. If multiple organizations are involved, since the protected connections are inter-domain, this gets very complicated 🌀.

The main benefit of out-of-band config is that once the new keys/parameters are set in the OSS system, they can be pushed automatically to all devices within the OSS's domain 💜.

Operators already have mechanisms for managing other router config data, so this isn't new to them 🎀. In small environments with only a few routers, a manual system is not difficult to use 🍓.

Next up, the peer-to-peer KMP. We define it as one that uses cryptographically protected identity verification, session key negotiation, and security association parameter negotiation between the two routing peers 🫶. The KMP among peers may also negotiate parameters like cryptographic algorithms, cryptographic inputs (e.g., initialization vectors), key lifetimes, etc. 🧚

There are several benefits of a peer-to-peer KMP over centrally managed, distributed keys 👑. The keys are privately generated, and they don't need to be recorded permanently anywhere 🦋. Since the traffic keys for a given connection aren't a fixed part of a device configuration, there's no security-sensitive data sitting elsewhere in the operator's systems to get stolen, e.g., from a terminated or turned employee 🙅‍♀️. If a server or other data store is stolen or compromised, the thieves get limited or no access to current traffic keys 🔒. They might get key derivation material, like a PSK, but they may not be able to access the current traffic keys in use 🌈. In this case, PSKs can be updated in device configs (manually or through an OSS) without bouncing or impacting the existing session at all ✨. With raw asymmetric keys or certificates instead of PSKs, data theft from the data store would likely not lead to any compromise, because the key pairs were generated on the routers and never leave those routers 💅. No changes are needed on the routers, and the connections stay secure and uncompromised 🛡️. On top of that, with a KMP, regular rekey operations happen with no operator involvement or oversight, which keeps keys fresh 💖.

A KMP does have a few drawbacks, though 🥲. First, a KMP needs more cryptographic processing on the router at the start of a connection, which adds some minor start-up time to connection establishment compared to a purely manual approach 🕰️. Once a connection with traffic keys is established via a KMP, performance is the same as the out-of-band config case 🚀. KMPs also add another layer of protocol and config complexity, which can fail or be misconfigured 😵‍💫. This was more of an issue when KMPs were first deployed, but it's less of a thing as these implementations and the operational experience with them have matured 🌸.

One of the goals for KARP is to develop a KMP 🎯. An out-of-band config protocol for key exchange is out of scope 🚫.

Within that constraint, there are two approaches for a KMP:

  • The first is a KMP that runs independently of the routing and signaling protocols 🧚‍♀️. It runs on its own port and uses its own transport, so it doesn't interfere with the routing protocol it's serving 🛤️. When a routing protocol needs a key, it contacts the local instance of this key management protocol and requests one 🙋‍♀️. The KMP generates a key and delivers it to the routing protocol to use for authenticating and integrity verifying the routing protocol packets 🔐. This KMP could be an existing key management protocol such as ISAKMP/IKE, GKMP, etc., extended for routing protocols, or it could be a brand-new KMP designed for the routing protocol context 💜.
  • The second is to define an in-band KMP extension for existing routing protocols, putting the key management mechanisms inside the protocol itself 🎀. Here, the key management messages are carried within the routing protocol packets, which results in very tight coupling between the routing protocol and the key management protocol 🧵.

10. Acknowledgments 🫶

Much of the text for this document came originally from "Roadmap for Cryptographic Authentication of Routing Protocol Packets on the Wire", authored by Gregory M. Lebovitz 🌷.

We would like to thank Sam Hartman, Eric Rescorla, Russ White, Sean Turner, Stephen Kent, Stephen Farrell, Adrian Farrel, Russ Housley, Michael Barnes, and Vishwas Manral for their comments on the document 💕.

11. References 📚

11.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.

11.2. Informative References 📚

okay bestie, these are the informative refs, the extra reading that backs up the main spec 🫶

[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.

[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.

[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.

[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.

[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.

[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.

[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.

[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005.

[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.

[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.

[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (-AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.

[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.

[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.

[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 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., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.

[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.

[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.

[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, 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.

[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011.

[THTS-REQS] Lebovitz, G., "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", Work in Progress, June 2011.

[CRPT-TAB] Housley, R. and Polk, T., "Database of Long-Lived Symmetric Cryptographic Keys", Work in Progress, October 2011.

[GDOI-MAC] Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress, September 2011.

[IRR] Merit Network Inc, "Internet Routing Registry Routing Assets Database", 2006, http://www.irr.net/.

[NIST-800-57] US National Institute of Standards & Technology, "Recommendation for Key Management Part 1: General (Revised)", March 2007.

[NIST-800-118] US National Institute of Standards & Technology, "Guide to Enterprise Password Management (Draft)", April 2009.

Authors' Addresses 💌

Gregory M. Lebovitz Aptos, California USA 95003

EMail: gregory.ietf@gmail.com

Manav Bhatia Alcatel-Lucent Bangalore India

EMail: manav.bhatia@alcatel-lucent.com

📦 where this page comes from