RFC 2385

Protection of BGP Sessions via the TCP MD5 Signature Option

📅 published August 1998, from ietf

RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature Option 💖

okay bestie, here's the title block so you know who's behind this 🎀

  • Network Working Group 🌸
  • Request for Comments: 2385
  • Title: Protection of BGP Sessions via the TCP MD5 Signature Option
  • Author: A. Heffernan, cisco Systems ✨
  • Category: Standards Track
  • Date: August 1998
  • Obsoletes / Updates: nothing is listed in the header 🙈

Status of This Memo ✨

so this doc is a standards track protocol for the Internet community, and it's basically asking everyone to discuss it and suggest improvements 💅 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🦋

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

IESG Note 🙈

this doc describes existing practice for securing BGP against certain simple attacks 🛡️ It's understood to have security weaknesses against concerted attacks, so don't go thinking it's bulletproof bestie 💀

Abstract ✨

this memo describes a TCP extension that makes BGP more secure 🔐 It defines a new TCP option that carries an MD5 [RFC1321] digest in a TCP segment. That digest acts like a signature for the segment, and it's built from info that only the two connection endpoints know. Since BGP uses TCP as its transport, using this option the way this paper describes really cuts down the danger from certain attacks on BGP 🫶

1.0 Introduction 🌈

the main goal of this option is to let BGP protect itself from spoofed TCP segments getting slipped into the connection stream 👀 The big worry is TCP resets 😭

to spoof a connection using this scheme, an attacker would need to guess the TCP sequence numbers AND get the password that's included in the MD5 digest. The password never shows up in the connection stream, and what the password actually looks like is up to the application 🔑 It can even change during the life of a connection, as long as both ends change it at the same time. Retransmission can get messy in some TCP implementations when passwords change, though 💀

last thing: there's no negotiation for using this option. Whether a connection uses it is purely a matter of site policy 📋

2.0 Proposal 💅

every segment sent on a TCP connection that's protected against spoofing will carry the 16-byte MD5 digest. It's made by running MD5 over these items, in this order:

  1. the TCP pseudo-header (source IP address, destination IP address, zero-padded protocol number, and segment length, in that order)
  2. the TCP header, leaving out options and assuming a checksum of zero
  3. the TCP segment data (if there is any)
  4. an independently specified key or password that both TCPs know, and that's presumably specific to the connection 🔑

the header and pseudo-header are in network byte order 🧚 The nature of the key is deliberately left unspecified, but it MUST be known by both ends of the connection 🫶 A particular TCP implementation decides what the application is allowed to set as the key.

when a receiver gets a signed segment, it MUST validate it by calculating its own digest from the same data, using its own key, and then comparing the two digests 🔍 If the comparison fails, the segment MUST be dropped, and the receiver MUST NOT send any response back to the sender 🚫 It's probably a good idea to log the failure too 📝

unlike other TCP extensions (like the Window Scale option [RFC1323]), the absence of this option in the SYN,ACK segment MUST NOT make the sender stop sending signatures 🙅‍♀️ That negotiation is usually there so some TCP implementations don't misbehave when they get options in non-SYN segments. It's not a problem here, because the SYN,ACK sent during connection setup won't be signed, so it'll get ignored. The connection will never get made, and non-SYN segments with options will never get sent. Most importantly, sending signatures MUST be under the complete control of the application, not at the mercy of a remote host that doesn't understand the option 👑

3.0 Syntax 🍓

here's the layout of the proposed option 👇

             +---------+---------+-------------------+
             | Kind=19 |Length=18|   MD5 digest...   |
             +---------+---------+-------------------+
             |                                       |
             +---------------------------------------+
             |                                       |
             +---------------------------------------+
             |                                       |
             +-------------------+-------------------+
             |                   |
             +-------------------+

the MD5 digest is always 16 bytes long, and the option shows up in every segment of a connection ✨

4.0 Some Implications 🦋

4.1 Connectionless Resets 😭

a connectionless reset gets ignored by whoever receives it, because the sender doesn't know the key and can't generate the right signature 🙅‍♀️ So, for example, connection attempts from a TCP that's generating signatures to a port with no listener will time out instead of being refused. Resets sent in response to segments on a stale connection get ignored too. This can be a real problem, because resets are how BGP recovers quickly from peer crashes 💀

4.2 Performance 🔥

calculating digests can be expensive, and that might discourage people from using this option 💸 Some measurements of a sample implementation on a 100 MHz R4600 showed that generating a signature for a simple ACK segment took 0.0268 ms on average, while generating a signature for a data segment carrying 4096 bytes of data took 0.8776 ms on average. These costs apply to both the input and output paths, and the input path also has to pay for a 16-byte compare ⏱️

4.3 TCP Header Size 🎀

like any other option that goes on every segment, the MD5 option's size has to be factored into the MSS offered to the other side during connection negotiation 📏 Specifically, the header size you subtract from the MTU (whether that's the MTU of the outgoing interface or IP's minimal MTU of 576 bytes) MUST be factored in, and it's now at least 18 bytes bigger.

the total header size matters too. The TCP header says where segment data starts with a 4-bit field that gives the total header size (options included) in 32-byte words. So the total header plus options MUST be less than or equal to 60 bytes, which leaves 40 bytes for options 🧮

for a concrete example, 4.4BSD defaults to sending window-scaling and timestamp info for the connections it starts. The biggest segment is the initial SYN packet that opens the connection. With MD5 signatures, the SYN packet looks like this:

    -- 4 bytes MSS option
    -- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD)
    -- 12 bytes for timestamp (4.4BSD pads the option as recommended
       in RFC 1323 Appendix A)
    -- 18 bytes for MD5 digest
    -- 2 bytes for end-of-option-list, to pad to a 32-bit boundary.

that adds up to 40 bytes, which just barely fits 😮‍💨✨

4.4 MD5 as a Hashing Algorithm 🙈

ngl this part is a little sad. Since this memo was first issued (under a different title), researchers found that MD5 is vulnerable to collision search attacks [Dobb], and some people think it's too weak for this kind of application 💔

this memo still specifies MD5 anyway, because the option is already deployed in the field, and there was never an "algorithm type" field that would let you upgrade while keeping the same option number. The original document didn't define a type field, because that would take at least one more byte. Back then it seemed like taking 19 bytes for the whole option (which would probably get padded to 20 bytes in TCP implementations) was too big a waste of the already limited option space 🥲

this doesn't stop anyone from deploying a similar option that uses a different hash algorithm, like SHA-1 🔐 Also, since most implementations pad the 18-byte option to 20 bytes anyway, it would be just as well to define a new option with an algorithm type field.

that would need to be handled in a different document, though 📄

4.5 Key configuration 🗝️

it's worth noting that a router's key configuration mechanism can restrict which keys can be used between peers. It is strongly RECOMMENDED that an implementation can support, at minimum, a key made of a string of printable ASCII that's 80 bytes or less, because that's current practice ✨

5.0 Security Considerations 💀

okay this one's serious bestie. This document defines a weak but currently practiced security mechanism for BGP ⚠️ It's expected that future work will provide different, stronger mechanisms for dealing with these issues. Don't treat this option as strong protection 🙅‍♀️

6.0 References 📚

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
          April 1992.

[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
          for High Performance", RFC 1323, May 1992.

[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA
          Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
          http://www.rsa.com/rsalabs/pubs/cryptobytes.html

Author's Address 🌸

Andy Heffernan
cisco Systems
170 West Tasman Drive
San Jose, CA  95134  USA

Phone:  +1 408 526-8115
EMail:  ahh@cisco.com

Copyright (C) The Internet Society (1998). All Rights Reserved.

this document and translations of it can be copied and handed out to others. Derivative works that comment on or explain it, or help with implementing it, can be prepared, copied, published, and distributed, in whole or in part, with no restrictions of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works 🎀 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exception is when you're developing Internet standards, and then the procedures for copyrights defined in the Internet Standards process MUST be followed. Translating it into languages other than English is also allowed.

The limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns 🦋

This document and the information in it are provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 🙏✨

📦 where this page comes from