RFC 7349
LDP Hello Cryptographic Authentication
LDP Hello Cryptographic Authentication (RFC 7349) 🎀
Okay bestie, here's the vibe check first: this is an Internet Standards Track doc ✨ from the IETF (Internet Engineering Task Force), written by L. Zheng and M. Chen of Huawei Technologies, with M. Bhatia from Ionos Networks 💖. It's dated August 2014, its ISSN is 2070-1721, and the title block has no Obsoletes or Updates lines, so it doesn't replace or patch anything listed there 🦋.
Abstract
okay so this doc adds a brand new optional Cryptographic Authentication TLV that LDP can use to lock down its Hello messages 🔐. The goal is to stop spoofing attacks and some well-known attacks that target the IP header 🛡️. The mechanism uses Hashed Message Authentication Code (HMAC) with the Secure Hash Standard family of algorithms from the National Institute of Standards and Technology (NIST) ✨.
Status of This Memo
this is an Internet Standards Track document 📜.
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💅. more info on Internet Standards is in Section 2 of RFC 5741 🌸.
info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7349 🍓.
Copyright Notice
© 2014 IETF Trust and the people listed 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 stand on the publication date 📚. please read them carefully, because they spell out your rights and restrictions for this doc 🙈.
any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions 🎀. they come with no warranty, as described in the Simplified BSD License 🌈.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4
2.1. Optional Parameter for Hello Message . . . . . . . . . . 4
2.2. LDP Security Association . . . . . . . . . . . . . . . . 4
2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6
2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 7
3. Cryptographic Authentication Procedure . . . . . . . . . . . 8
4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . . 8
5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9
5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 9
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Processing Hello Message Using Cryptographic Authentication . 10
6.1. Transmission Using Cryptographic Authentication . . . . . 10
6.2. Receipt Using Cryptographic Authentication . . . . . . . 10
7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 141. Introduction ✨
okay so the Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions that run between LDP peers 🦋. those peers can be directly connected at the link level, or they can be multiple hops away 🌸. an LDP Label Switching Router (LSR) can either be configured with the identity of its peers, or it can discover them using LDP Hello messages 🔍. these messages get sent encapsulated in UDP, addressed to "all routers on this subnet" or to one specific IP address 💌. Hellos also get sent periodically to keep the relationship between LDP peers alive, which is what keeps the LDP session active 💖.
here's the tea: Hellos use UDP and not TCP, so they can't use the security mechanisms defined for TCP [RFC5926] 🙈. [RFC5036] does give some configuration guidance to help guard against false discovery messages, but it doesn't offer an explicit security mechanism to protect the Hello messages 😭.
spoofing a Hello for an existing adjacency can make the valid adjacency time out, and that can end the session tied to it 💀. this happens when the spoofed Hello sets a smaller Hold Time, so the receiver expects Hellos within that shorter interval, while the real neighbor keeps sending at the lower frequency they already agreed on 🫠. spoofing can also kill the LDP session directly, which happens when the spoofed Hello advertises a different Transport Address than the one the neighbors previously agreed on 🚫. these spoofed Hellos have been seen and reported as a real problem in production networks [RFC6952] 🔥.
for Link Hello, [RFC5036] says you can cut down the threat of spoofed Hellos by accepting Hellos only on interfaces where trusted LSRs are directly connected, and by ignoring Hellos not addressed to the "all routers on this subnet" multicast group 🧚. the Generalized TTL Security Mechanism (GTSM) is a simple and reasonably robust defense for Link Hello [RFC6720] ✨, but it doesn't protect against packet spoofing attacks or replay attacks [RFC5082] 😤.
spoofing via Targeted Hellos is a potentially more serious threat 🚨. [RFC5036] says an LSR can reduce it by filtering Targeted Hellos and accepting only the ones from sources an access list permits 📋. but filtering with access lists eats up LSR resources, and it doesn't stop IP-address spoofing either 💅.
so this document brings in a new Cryptographic Authentication TLV, used in LDP Hello messages as an optional parameter 🎀. it upgrades the authentication mechanism for LDP by protecting the Hello message against spoofing attacks 🛡️. it also adds a cryptographic sequence number carried in the Hello messages, which can be used to guard against replay attacks 🔁.
with this Cryptographic Authentication TLV, one or more secret keys (each with a matching Security Association (SA) ID) get configured in each system 🔑. for every LDP Hello message, the key is used to generate and verify an HMAC Hash that's stored inside that Hello 🧁. for the cryptographic hash function, this doc proposes SHA-1, SHA-256, SHA-384, and SHA-512, all defined in the US NIST Secure Hash Standard (SHS) [FIPS-180-4] 🌈. the HMAC authentication mode from [RFC2104] is used too 💜.
and the big rule for support: implementations MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY include support for HMAC-SHA-384 and HMAC-SHA-512 👑.
1.1. Requirements Language 📝
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶.
2. Cryptographic Authentication TLV 🔐
2.1. Optional Parameter for Hello Message 🦋
so [RFC5036] defines the encoding for the Hello message 🌸. each Hello message holds zero or more Optional Parameters, and each one is encoded as a TLV 🍓. [RFC5036] defines three Optional Parameters, and this document defines a brand new one: the Cryptographic Authentication parameter ✨.
here's the lineup 💖:
Optional Parameter Type
-------------------------------- --------
IPv4 Transport Address 0x0401 (RFC 5036)
Configuration Sequence Number 0x0402 (RFC 5036)
IPv6 Transport Address 0x0403 (RFC 5036)
Cryptographic Authentication TLV 0x0405 (this document)the encoding for the Cryptographic Authentication TLV is described in Section 2.3 💅.
Part 1 of 3 ✨ the rest of the RFC is coming up next, bestie 🫶💜
2.2. LDP Security Association 💖
okay so an LDP Security Association (SA) is basically a bundle of settings that any two legit LDP speakers share 🫶 it's the whole vibe of who's allowed to talk to who, and what secrets they use to prove it ✨
Here's what lives inside an LDP SA 👑
- Security Association Identifier (SA ID)
This is a 32-bit unsigned integer that uniquely identifies an LDP SA between two LDP peers 🎀 the network operator sets it up manually (or maybe some key management protocol the IETF cooks up later, ngl that would be iconic 🔥).
The receiver figures out which SA is active by checking the SA ID field in the incoming Hello message 👀
The sender picks an SA to use based on the active configuration and drops the matching SA ID value into the LDP Hello message 💅 if there are multiple valid and active LDP SAs on one interface, the sender can use any of them to protect the packet, so no stress 🦋
SA IDs make changing keys while the protocol keeps running super convenient 🌈 each SA ID covers two separate things, the authentication algorithm and the authentication key, which we'll get into below 🧚
Normally an implementation lets the network operator set up a bunch of keys in a key chain, and each key in that chain gets a fixed lifetime 🍓 how those mechanisms actually work is outside the scope of this doc, so we're not going there today 🙈
Also, each SA ID can point to a key with a different authentication algorithm 😭 this is the secret sauce that lets new authentication mechanisms show up without wrecking existing LDP sessions 💜
- Authentication Algorithm
This tells you which authentication algorithm goes with the LDP SA 🔐 the info never gets sent in clear text over the wire, so the implementer gets to pick whatever internal representation they want for it 🧁
Right now these algorithms are supported:
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 ✨
- Authentication Key
This is the cryptographic authentication key tied to the LDP SA 🗝️ its length isn't fixed, it depends on which authentication algorithm the LDP SA uses 🌸
- KeyStartAccept
The time this LDP router starts accepting packets that were created with this LDP Security Association ⏰
- KeyStartGenerate
The time this LDP router starts using this LDP Security Association to generate LDP Hello messages 🚀
- KeyStopGenerate
The time this LDP router stops using this LDP Security Association to generate LDP Hello messages 🛑
- KeyStopAccept
The time this LDP router stops accepting packets generated with this LDP Security Association 🥀
To get a smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept 🫠 if KeyStartGenerate or KeyStartAccept gets left unspecified, the time defaults to 0 and the key gets used right away ⚡ if KeyStopGenerate or KeyStopAccept gets left unspecified, the time defaults to infinity and the key's lifetime is infinite ♾️ when a new key replaces an old one, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key 🎯 and any unspecified values get encoded as zero 🫧
Key storage SHOULD persist across a system restart, warm or cold, so nothing goes sideways operationally 🛟 now, if the last key on an interface expires, it's literally unacceptable to fall back to an unauthenticated condition, and it's not advisable to disrupt routing either 😱 so the router SHOULD send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime gets extended, the key gets deleted by network management, or a new key is configured 🫶🌈
2.3. Cryptographic Authentication TLV Encoding 🎀
Here's the layout of the TLV, so get ready to stare at some bits 👀✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Auth (0x0405) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type: 0x0405, Cryptographic Authentication 🏷️
- Length: the length in octets of the value field, including the Security Association ID and Cryptographic Sequence Number fields 📏
- Security Association ID: this 32-bit field maps to the authentication algorithm and the secret key used to create the message digest carried in the LDP payload 🗺️
Even though the SA ID implies the algorithm, implementers should not use the HMAC output size as an implicit hint, because more algorithms might get defined later that have the same output size 🙅♀️
- Cryptographic Sequence Number: this is a 64-bit, strictly increasing sequence number that guards against replay attacks 🛡️ it MUST be incremented for every LDP Hello message the LDP router sends 📈 and when a message comes in, its sequence number MUST be greater than the sequence number in the last LDP Hello message accepted from that sending LDP neighbor 🫶 otherwise the LDP message counts as a replayed packet and gets dropped 🗑️ the Cryptographic Sequence Number is one single space per LDP router 🌌
LDP routers that implement this spec MUST use existing mechanisms to keep the sequence number strictly increasing for the whole deployed life of the router, cold restarts included 🥹 one way to do that could be using the high-order 32 bits as a boot count that goes up any time the router loses its sequence number state 🔢 other techniques, like the sequence number space partitioning mentioned above or preserving things in non-volatile storage, can work too, but they're beyond the scope of this spec 📦 and sequence number wrap is covered in Section 2.4 🔁
- Authentication Data: this field carries the digest computed by whichever Cryptographic Authentication algorithm is in use 🔐 its length changes based on that algorithm, and here's the breakdown 👇
Auth type Length
--------------- ----------
HMAC-SHA1 20 bytes
HMAC-SHA-256 32 bytes
HMAC-SHA-384 48 bytes
HMAC-SHA-512 64 bytes2.4. Sequence Number Wrap 🔁
okay so when the router increments the sequence number for each LDP message it sends, the sequence number should be treated as an unsigned 64-bit value 🧮 if the lower-order 32-bit value wraps around, the higher-order 32-bit value should be incremented and saved in non-volatile storage 💾
If the LDP router stays deployed long enough for the whole 64-bit sequence number to wrap, all keys MUST be reset, no matter which key distribution mechanism was used 😰 this is done to avoid any chance of replay attacks, so it's giving serious security energy 🛡️ once the keys have been changed, the higher-order sequence number can be reset to 0 and saved to non-volatile storage again 🫧
3. Cryptographic Authentication Procedure 🧾
As we said earlier, the Security Association ID maps to the authentication algorithm and the secret key used to generate and verify the message digest 🗝️ this spec talks about computing LDP Cryptographic Authentication data when any of the NIST SHS family of algorithms gets used in the Hashed Message Authentication Code (HMAC) mode 🌈
The currently valid algorithms (including mode) for LDP Cryptographic Authentication are:
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 💜
Of those, implementations of this spec MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY also include support for HMAC-SHA-384 and HMAC-SHA-512 🎀
Implementations of this standard MUST use HMAC-SHA-256 as the default authentication algorithm 👑
4. Cross-Protocol Attack Mitigation 🛡️
okay this part is so clever 🧠 to stop cross-protocol replay attacks for protocols sharing common keys, the 2-octet LDP Cryptographic Protocol ID gets appended to the authentication key before it's used (see Section 8) 🫶 other protocols using the common key do the same thing with their own Cryptographic Protocol IDs, so every protocol ends up using a different key value 💅
5. Cryptographic Aspects 🔐
In the algorithm description below, here's the nomenclature we're using 📝
- H is the specific hashing algorithm (e.g., SHA-256).
- K is the Authentication Key from the LDP Security Association.
- Ks is a Protocol-Specific Authentication Key, made by appending the Authentication Key (K) with the 2-octet LDP Cryptographic Protocol ID.
- Ko is the cryptographic key used with the hash algorithm.
- L is the length of the hash, measured in octets rather than bits.
- AuthTag is a value that is the same length as the hash output. For IPv4, the first 4 octets contain the IPv4 source address, followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. For IPv6, the first 16 octets contain the IPv6 source address, followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets. ✨
5.1. Preparing the Cryptographic Key 🗝️
The LDP Cryptographic Protocol ID gets appended to the Authentication Key (K), which gives you a Protocol-Specific Authentication Key (Ks) 🧩 in this application, Ko is always L octets long. Keys longer than the bit length of the hash function get hashed down to force them to this length, as we describe below 🫧 here's how Ks gets computed:
- If the Protocol-Specific Authentication Key (Ks) is L octets long, then Ko is equal to Ks.
- If the Protocol-Specific Authentication Key (Ks) is more than L octets long, then Ko is set to H(Ks).
- If the Protocol-Specific Authentication Key (Ks) is less than L octets long, then Ko is set to the Protocol-Specific Authentication Key (Ks) with zeros appended to the end, such that Ko is L octets long.
For higher entropy, it is RECOMMENDED that Key Ks should be at least L octets long 🌟
5.2. Computing the Hash 🧮
First, the Authentication Data field in the Cryptographic Authentication TLV gets filled with the value AuthTag 🏷️ then, to compute the HMAC over the Hello message, it does this:
AuthData = HMAC(Ko, Hello Message)Hello Message refers to the LDP Hello message excluding the IP and the UDP headers 📨
5.3. Result ✨
okay so the output of the hash is the thing that goes into the Authentication Data field of the Cryptographic Authentication TLV 💖 and the length of that field is always the same as the message digest size of whichever hash function H you're using 🎀. so like, the bigger the hash output, the bigger the LDP message gets on the wire 📦 bestie, that's just the vibe 💅
6. Processing Hello Message Using Cryptographic Authentication 🦋
6.1. Transmission Using Cryptographic Authentication 🌸
okay so before the LDP Hello gets sent out, you set the Length in the Cryptographic Authentication TLV header based on which authentication algorithm you're using ✨ it's 24 for HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384, and 68 for HMAC-SHA-512 💜
then the Security Association ID field gets set to the ID of the current authentication key 🔑 and the HMAC Hash gets computed the way Section 5 explains 🧚 the result gets stored in the Authentication Data field before it goes out 🎀 and the authentication key MUST NOT be carried in the packet 🙈 never ever put the key in the packet, periodt 💀
6.2. Receipt Using Cryptographic Authentication 👑
the receiving LSR checks whether the Hello is acceptable using cryptographic authentication 🫶 if the Cryptographic Authentication TLV is unknown to the receiver, the packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036] 🗑️
the receiving router MUST decide whether to accept a Hello from a particular source IP address like this 💅 first, if the router already has a stored LDP Hello cryptographic sequence number for that source IP address, or it's configured to require LDP Hello authentication, then it MUST discard any unauthenticated Hello packets 😭 and as we'll see later in this section, a cryptographic sequence number only gets stored for a source IP address once a valid authenticated Hello has been received 🌈
the receiving LSR finds the LDP SA using the Security Association ID field in the message 🔍 if the SA isn't found, or if it isn't valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the LDP Hello message MUST be discarded and an error event SHOULD be logged ⭐
if the cryptographic sequence number in the LDP Hello message is less than or equal to the last sequence number received from the same neighbor, the LDP Hello message MUST be discarded and an error event SHOULD be logged 🥲 no replays allowed, bestie 🚫
before the receiving LSR does any processing, it needs to save the values of the Authentication Data field 🫙 then it replaces the contents of the Authentication Data field with AuthTag and computes the Hash using the authentication key named by the received Security Association ID field, as explained in Section 3 🧮 if the locally computed Hash equals the received value of the Authentication Data field, the packet is accepted for the other normal checks and processing described in [RFC5036] 🥳 otherwise, if the locally computed Hash doesn't match the received value, the received LDP Hello message MUST be discarded and an error event SHOULD be logged 😤 this logging needs to be carefully rate limited, because while an LDP router is under attack by a storm of spoofed Hellos, the resources needed for logging could be overwhelming 🌪️ so like, don't let your logs eat all your memory, iykyk 💀
after the LDP Hello message has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for the LDP Hello message received from the source IP address 📝 those saved sequence numbers get used for replay checking on later packets from that source IP address 🔁
7. Operational Considerations 🎀
careful thought needs to go into when and how you turn authentication on and off for LDP Hellos 🥺 on one hand, it is critical that an attacker cannot cause the authentication to be disabled 🚨 on the other hand, it is equally important that an operator can change the hardware and/or software tied to a neighbor's IP address and successfully bring up an LDP adjacency with the desired level of authentication, which might be different or no authentication because of software restrictions 💖
LDP Hello authentication info (like whether authentication is enabled and what the last cryptographic sequence number is) tied to an IP address is learned through a set of interfaces 🧚 if an interface is administratively disabled, the LDP Hello authentication info learned through that interface MAY be forgotten ✨ this lets an operator who isn't specifically messing with LDP Hello authentication configs bring up an LDP adjacency easily 🫶 an implementation of this standard SHOULD provide a configuration mechanism to show and forget the LDP Hello authentication info associated with an IP address 👀 and configuration mechanisms are assumed to be accessed over an authenticated channel 🔐
8. Security Considerations 🚨
okay bestie, this part is SERIOUS 😭 Section 1 of this document describes the security issues that come up with unauthenticated LDP Hello messages 💀 to address those issues, it is RECOMMENDED that all deployments use the Cryptographic Authentication TLV to authenticate Hello messages 🛡️
the quality of the security the Cryptographic Authentication TLV provides depends completely on how strong the cryptographic algorithm is, how strong the key is, and whether the security mechanism is implemented correctly in the communicating LDP implementations 🧠 also, the level of security varies depending on the authentication type used 📉
it should be noted that the authentication method in this document is NOT used to authenticate the specific originator of a packet 🙅♀️ instead, it's used to confirm that the packet was issued by a router that has access to the authentication key 🔑
deployments SHOULD use sufficiently long and random values for the authentication key, so that guessing and other cryptographic attacks on the key aren't feasible in their environments 🎲 to support this, management systems SHOULD support hexadecimal input of authentication keys 🔢
the mechanism described here is not perfect 🥹 however, it introduces a significant increase in the effort an adversary needs to successfully attack the LDP Hello protocol, without causing undue implementation, deployment, or operational complexity 🏰 that's a big win, no cap 👑
9. IANA Considerations 📋
the IANA has assigned a new TLV from the "Label Distribution Protocol (LDP) Parameters" registry, "TLV Type Name Space" 🎀
Value Description Reference
------ -------------------------------- ---------------------------
0x0405 Cryptographic Authentication TLV this document (Section 2.3)the IANA has also assigned a value from the "Authentication Cryptographic Protocol ID" registry under the "Keying and Authentication for Routing Protocols (KARP) Parameters" category 🌈
Value Description Reference
----- -------------------------------- -------------------------
2 LDP Cryptographic Protocol ID this document (Section 4)10. Acknowledgements 🫶
we owe a huge thank you to Yaron Sheffer, who helped us enormously in rewriting the document to get rid of the redundant crypto mathematics we had added 🙌 we also want to thank Liu Xuehu for his work on background and motivation for LDP Hello authentication 💜 last but not least, thanks to Adrian Farrel, Eric Rosen, Sam Hartman, Stephen Farrell, Eric Gray, Kamran Raza, and Acee Lindem for their valuable comments 🌸✨
11. References 📚
11.1. Normative References 💖
[FIPS-180-4]
National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS 180-4, March 2012.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.11.2. Informative References 🧚
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010.
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.Authors' Addresses 🎀
Lianshu Zheng
Huawei Technologies
China
EMail: vero.zheng@huawei.com
Mach(Guoyi) Chen
Huawei Technologies
China
EMail: mach.chen@huawei.com
Manav Bhatia
Ionos Networks
India
EMail: manav@ionosnetworks.comThat's the whole RFC, bestie! 🌈💖 You made it through all three parts 😭✨
📦 where this page comes from
- ietf: rfc7349 2014-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms