Protection of BGP Sessions via the TCP MD5 Signature Option
obsoleted by
- rfc-5925 — The TCP Authentication Option
updated by
- rfc-6691 — TCP Options and Maximum Segment Size (MSS)
Extracted elements (14)
No algorithm type field was included in the option because it would require at least one more byte, and taking 19 bytes (likely padded to 20) was considered too wasteful of the already limited 40-byte TCP option space. This decision locked the option to MD5 and prevents in-place algorithm upgrades.
No negotiation is defined for enabling the MD5 option; its use is purely a matter of site policy. This avoids the need for a negotiation phase and keeps the sending of signatures entirely under application control rather than subject to remote host behavior.
The shared key/password never appears in the connection stream; its form is left deliberately unspecified and may be connection-specific. It could even change during the lifetime of a connection if both ends are synchronized, though changing passwords can cause retransmission problems in some TCP implementations.
The SYN,ACK sent during connection negotiation will not be signed and will thus be ignored by the initiator configured to require signatures, so the connection will never complete. This means non-SYN segments with the MD5 option will never be sent to a peer that does not support it, avoiding misbehavior in non-MD5 TCP implementations.
Because no algorithm type field exists in the option, deploying a stronger hash algorithm (e.g., SHA-1) requires defining an entirely new TCP option with a different Kind number rather than upgrading the existing option.
Connectionless resets sent by a TCP that does not know the key will be ignored by the protected receiver because the reset cannot carry a valid signature. This means connection attempts to ports with no listener will time out rather than being refused, and stale-connection resets are also silently dropped.
The 18-byte MD5 option must be factored into the MSS advertised during connection negotiation, as it reduces the space available for data. The total TCP header plus options must remain at or below 60 bytes, leaving only 40 bytes for all options combined.
An implementation SHOULD be able to support at minimum a key composed of a string of printable ASCII of 80 bytes or less, as this is current practice.
The absence of the MD5 option in the SYN,ACK segment MUST NOT cause the sender to disable its sending of signatures. Sending of signatures must be under complete control of the application, not contingent on remote host understanding the option.
Upon receiving a signed segment, the receiver MUST validate it by computing its own digest from the same data and comparing. A failing comparison MUST result in the segment being dropped and MUST NOT produce any response to the sender.
The MD5 digest is computed over: (1) TCP pseudo-header (source IP, destination IP, zero-padded protocol number, segment length), (2) TCP header excluding options with checksum set to zero, (3) TCP segment data if any, and (4) a shared key/password known to both endpoints.
The TCP MD5 Signature Option (Kind=19, Length=18) carries a 16-byte MD5 digest in every TCP segment of a protected connection. The option appears in every segment and is 18 bytes total.
This mechanism is explicitly described as weak but currently practiced. MD5 has been found vulnerable to collision search attacks and is considered by some to be insufficiently strong for this application. Future work is anticipated to provide stronger mechanisms. An attacker must both guess TCP sequence numbers and obtain the shared password to spoof a segment.
The option format is: Kind=19 (1 byte), Length=18 (1 byte), MD5 digest (16 bytes). Total option size is 18 bytes and must appear in every segment of the protected connection.