RFC 4278

Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification 💖

okay bestie, let's get into this 🎀

RFC 4278 📜 is from the Network Working Group. Its category is Informational 🌸, and it's dated January 2006 🍓. The authors are Steven M. Bellovin (AT&T Labs Research) and Alex Zinin (Alcatel) 👑. The title block doesn't list anything it obsoletes or updates 🙈.

---

Status of This Memo ✨

this memo gives information to the Internet community 🫶. it does not specify an Internet standard of any kind, and distribution of it is unlimited 🦋.

Copyright Notice 💜

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

Abstract 🔮

okay so the IETF Standards Process says all the normative references in a document have to be at the same or higher level of standardization 📚. RFC 2026 section 9.1 lets the IESG grant a variance to the usual IETF practices 👀. this doc explains why the IESG is thinking about doing that for the revised BGP-4 spec, which normatively refers to RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option" 🧚. RFC 2385 is staying at the Proposed Standard level 🔥.

---

1. Introduction ✨

so the IETF Standards Process [RFC2026] says all normative references for a document have to be at the same or higher level of standardization 💅. RFC 2026 section 9.1 lets the IESG grant a variance to the usual IETF practices, and the IESG is considering using that to publish the updated BGP-4 spec [RFC4271] as a Draft Standard 🎀. the catch is the normative reference to [RFC2385], "Protection of BGP Sessions via the TCP MD5 Signature Option" 💀. RFC 2385 stays a Proposed Standard 🌸.

ngl, the title of [RFC2385] says "signature," but the tech it describes is usually called a Message Authentication Code, or MAC 🙈. don't mix it up with digital signatures, bestie ✨.

[RFC2385] is widely implemented 🦋, and it's the only transmission security mechanism defined for BGP-4 😭. other options like IPsec [RFC2401] and TLS [RFC2246] are rarely, if ever, used for this 💅. with the long-standing expectation that protocols have security features, you can't advance BGP-4 without a mandated security mechanism 🔐.

normally, when maturity levels clash between specs, you'd push the referenced spec up the standards track to the level the referring spec needs 🍓. but here the IESG thinks [RFC2385] is adequate for BGP deployments right now, yet not strong enough for general use, so it shouldn't move along the standards track 🙅‍♀️. so the IESG feels the variance procedure is the way to let the updated BGP-4 spec be published as a Draft Standard 👑.

the next sections give the detailed explanations of everything above 🧚.

2. Draft Standard Requirements 🌈

the requirements for Proposed Standards and Draft Standards are in [RFC2026] 📖. for Proposed Standards, [RFC2026] warns:

Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended.

so basically, flaws in Proposed Standards are considered reasonable 🙈✨.

the bar for Draft Standards is way higher 🔥:

A Draft Standard must be well-understood and known to be quite stable, both in its semantics and as a basis for developing an implementation.

so any doc with known deficiencies should not be promoted to Draft Standard 💀🫶.

3. The TCP MD5 Signature Option 🔐

okay the tea ☕: [RFC2385], even though it came out in 1998, describes a MAC that's way older than that 🦖. it uses a "keyed hash function" with MD5 [RFC1321] as the hash 🔑. back when it was made, that seemed reasonable, especially if the key was appended to the data being protected instead of prepended 💅. but cryptographic hash functions were never meant to be MACs, and later cryptanalysis showed the construct wasn't as strong as people thought [PV1, PV2] 😭. even worse, MD5 itself has shown signs of weakness [Dobbertin, Wang] 💀. so the IETF community adopted HMAC [RFC2104], which has provable security properties, as its standard MAC 🎀.

also, [RFC2385] has no key management technique at all 🙈. the common practice is using a password as a shared secret between pairs of sites, but that's not a good idea [RFC3562] 🚫.

other problems are written up in [RFC2385] itself, like the missing type code or version number, and systems that can't accept certain TCP resets 🌸.

even with how widely [RFC2385] is deployed in BGP, the IESG decided it's not appropriate for other contexts 👑. so [RFC2385] isn't suitable for advancement to Draft Standard 💔.

4. Usage Patterns for RFC 2385 🦋

so if [RFC2385] is so flawed, why is BGP still using it? 🤔 the answer is in how BGP gets deployed 🧚.

BGP connections naturally tend to travel over short paths 🛣️. most external BGP links are one hop 💅. internal BGP sessions are usually multi-hop, but the links are mostly just routers, not general-purpose computers 🖥️. general-purpose computers are way easier for attackers to turn into TCP hijacking tools [Joncheray] 😱.

BGP peering relationships also tend to be long-lived and static 🌈. a lot of other security situations are way more dynamic 🌪️.

this doesn't mean attacks can't happen 🙈. (if they couldn't happen at all, there'd be no point in security measures, bestie 💅.) attackers could divert links at layers 1 or 2, or in some situations use Address Resolution Protocol (ARP) spoofing at Ethernet-based exchange points 🦹. still, on balance, BGP runs in an environment that's less susceptible to this kind of attack ✨.

there's another class of attack BGP is extremely vulnerable to 💀: false route advertisements from more than one autonomous system (AS) hop away. but neither [RFC2385] nor any other transmission security mechanism can block those. a scheme like S-BGP [Kent] would be needed 🔥.

Full Copyright Statement 💅

okay so the legal bit, bestie 🎀 Copyright (C) The Internet Society (2006). 🌸

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 💜

THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈

---

Intellectual Property 🦋

the IETF is not picking a side on whether any Intellectual Property Rights or other rights might cover the technology in this document, or whether a license under those rights might be available. ngl, it also doesn't claim it went looking for any of them. 🫶 If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79. ✨

copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights, can all be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🧚

and the IETF literally invites anyone to tell it about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. 👑 Send that info to the IETF at ietf-ipr@ietf.org. 💖

---

Acknowledgement 🌈

shoutout to the funders! 🙌 Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). 💅