TCP MD5 Signature Option
The TCP MD5 Signature Option, defined in RFC 2385 [8], is used to help BGP protect itself from spoofed TCP segments and, particularly, TCP resets. The TCP MD5 Signature Option employs MD5's message digest algorithm, defined in RFC 1321[9]. More details regarding the usefulness of the TCP MD5 Signature Option can be found in the specification.
The extension provides a mechanism for TCP to carry a digest message in each TCP segment, where the digest utilizes information known only to the connection end points and acts as a signature for the segment.
Applying the MD5 algorithm to the following items, in the order listed, produces the digest created for a given segment:
-
TCP pseudo-header, in this order: source IP address, destination IP address, zero-padded protocol number, and segment length
-
TCP header, excluding options and assuming a checksum of zero
-
TCP segment data
-
Independently specified key or password, known to both TCP sender and receiver
When TCP receives a signed segment, the receiver must validate it by using its local key to calculate its own digest and compare the value with that of the received digest. If the comparison results in unequal values, the segment should be discarded and must not produce any response to the sender.
If a receiver is configured to utilize the option, the absence of a signature from a sender should not result in the receiver's disabling its use of the option.
The MD5 option appears in every segment and is always 16 bytes in length. (Recall the available 16 bytes in the BGP message header that were reserved for this purpose.) The format is shown in Figure 5-16.
Figure 5-16. MD5 Option Format
The MD5 option results in potentially hostile TCP resets being ignored by the receiver of the reset if the sender doesn't know the key value. Note that the key is never exchanged via the connection and that only the end points should be aware of the value.
Several issues are associated with using this option. Most notably, the MD5 algorithm has been found to be vulnerable to collision search attacks and is therefore considered by some to be insufficient for this application. Fortunately, the current specification does not prevent the deployment of an alternative-hashing algorithm.
There are also performance implications associated with calculating the digest value. This is because each TCP segment requires that both the sender and receiver perform the hashing function to generate the key value, and the receiver must compare the two values before accepting a message. The result is significantly increased delay with BGP message processing and generation.
Despite these offshoots, this option has already been widely deployed in both the interdomain and intradomain routing space.