RFC 2385 (rfc2385) - Page 2 of 6
Protection of BGP Sessions via the TCP MD5 Signature Option
Alternative Format: Original Text Document
RFC 2385 TCP MD5 Signature Option August 1998
during the lifetime of a particular connection so long as this change
was synchronized on both ends (although retransmission can become
problematical in some TCP implementations with changing passwords).
Finally, there is no negotiation for the use of this option in a
connection, rather it is purely a matter of site policy whether or
not its connections use the option.
2.0 Proposal
Every segment sent on a TCP connection to be protected against
spoofing will contain the 16-byte MD5 digest produced by applying the
MD5 algorithm to these items in the following order:
1. the TCP pseudo-header (in the order: source IP address,
destination IP address, zero-padded protocol number, and
segment length)
2. the TCP header, excluding options, and assuming a checksum of
zero
3. the TCP segment data (if any)
4. an independently-specified key or password, known to both TCPs
and presumably connection-specific
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 will
determine what the application may specify as the key.
Upon receiving a signed segment, the receiver must validate it by
calculating its own digest from the same data (using its own key) and
comparing the two digest. A failing comparison must result in the
segment being dropped and must not produce any response back to the
sender. Logging the failure is probably advisable.
Unlike other TCP extensions (e.g., the Window Scale option
[RFC 1323]), the absence of the option in the SYN,ACK segment must not
cause the sender to disable its sending of signatures. This
negotiation is typically done to prevent some TCP implementations
from misbehaving upon receiving options in non-SYN segments. This is
not a problem for this option, since the SYN,ACK sent during
connection negotiation will not be signed and will thus be ignored.
The connection will never be made, and non-SYN segments with options
will never be sent. More importantly, the sending of signatures must
be under the complete control of the application, not at the mercy of
the remote host not understanding the option.
Heffernan Standards Track