340 lines
12 KiB
Plaintext
340 lines
12 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group A. Heffernan
|
||
Request for Comments: 2385 cisco Systems
|
||
Category: Standards Track August 1998
|
||
|
||
|
||
Protection of BGP Sessions via the TCP MD5 Signature Option
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||
|
||
IESG Note
|
||
|
||
This document describes currrent existing practice for securing BGP
|
||
against certain simple attacks. It is understood to have security
|
||
weaknesses against concerted attacks.
|
||
|
||
Abstract
|
||
|
||
This memo describes a TCP extension to enhance security for BGP. It
|
||
defines a new TCP option for carrying an MD5 [RFC1321] digest in a
|
||
TCP segment. This digest acts like a signature for that segment,
|
||
incorporating information known only to the connection end points.
|
||
Since BGP uses TCP as its transport, using this option in the way
|
||
described in this paper significantly reduces the danger from certain
|
||
security attacks on BGP.
|
||
|
||
1.0 Introduction
|
||
|
||
The primary motivation for this option is to allow BGP to protect
|
||
itself against the introduction of spoofed TCP segments into the
|
||
connection stream. Of particular concern are TCP resets.
|
||
|
||
To spoof a connection using the scheme described in this paper, an
|
||
attacker would not only have to guess TCP sequence numbers, but would
|
||
also have had to obtain the password included in the MD5 digest.
|
||
This password never appears in the connection stream, and the actual
|
||
form of the password is up to the application. It could even change
|
||
|
||
|
||
|
||
|
||
|
||
Heffernan Standards Track [Page 1]
|
||
|
||
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
|
||
[RFC1323]), 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 [Page 2]
|
||
|
||
RFC 2385 TCP MD5 Signature Option August 1998
|
||
|
||
|
||
3.0 Syntax
|
||
|
||
The proposed option has the following format:
|
||
|
||
+---------+---------+-------------------+
|
||
| Kind=19 |Length=18| MD5 digest... |
|
||
+---------+---------+-------------------+
|
||
| |
|
||
+---------------------------------------+
|
||
| |
|
||
+---------------------------------------+
|
||
| |
|
||
+-------------------+-------------------+
|
||
| |
|
||
+-------------------+
|
||
|
||
The MD5 digest is always 16 bytes in length, and the option would
|
||
appear in every segment of a connection.
|
||
|
||
4.0 Some Implications
|
||
|
||
4.1 Connectionless Resets
|
||
|
||
A connectionless reset will be ignored by the receiver of the reset,
|
||
since the originator of that reset does not know the key, and so
|
||
cannot generate the proper signature for the segment. This means,
|
||
for example, that connection attempts by a TCP which is generating
|
||
signatures to a port with no listener will time out instead of being
|
||
refused. Similarly, resets generated by a TCP in response to
|
||
segments sent on a stale connection will also be ignored.
|
||
Operationally this can be a problem since resets help BGP recover
|
||
quickly from peer crashes.
|
||
|
||
4.2 Performance
|
||
|
||
The performance hit in calculating digests may inhibit the use of
|
||
this option. Some measurements of a sample implementation showed
|
||
that on a 100 MHz R4600, generating a signature for simple ACK
|
||
segment took an average of 0.0268 ms, while generating a signature
|
||
for a data segment carrying 4096 bytes of data took 0.8776 ms on
|
||
average. These times would be applied to both the input and output
|
||
paths, with the input path also bearing the cost of a 16-byte
|
||
compare.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Heffernan Standards Track [Page 3]
|
||
|
||
RFC 2385 TCP MD5 Signature Option August 1998
|
||
|
||
|
||
4.3 TCP Header Size
|
||
|
||
As with other options that are added to every segment, the size of
|
||
the MD5 option must be factored into the MSS offered to the other
|
||
side during connection negotiation. Specifically, the size of the
|
||
header to subtract from the MTU (whether it is the MTU of the
|
||
outgoing interface or IP's minimal MTU of 576 bytes) is now at least
|
||
18 bytes larger.
|
||
|
||
The total header size is also an issue. The TCP header specifies
|
||
where segment data starts with a 4-bit field which gives the total
|
||
size of the header (including options) in 32-byte words. This means
|
||
that the total size of the header plus option must be less than or
|
||
equal to 60 bytes -- this leaves 40 bytes for options.
|
||
|
||
As a concrete example, 4.4BSD defaults to sending window-scaling and
|
||
timestamp information for connections it initiates. The most loaded
|
||
segment will be the initial SYN packet to start the connection. With
|
||
MD5 signatures, the SYN packet will contain the following:
|
||
|
||
-- 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.
|
||
|
||
This sums to 40 bytes, which just makes it.
|
||
|
||
4.4 MD5 as a Hashing Algorithm
|
||
|
||
Since this memo was first issued (under a different title), the MD5
|
||
algorithm has been found to be vulnerable to collision search attacks
|
||
[Dobb], and is considered by some to be insufficiently strong for
|
||
this type of application.
|
||
|
||
This memo still specifies the MD5 algorithm, however, since the
|
||
option has already been deployed operationally, and there was no
|
||
"algorithm type" field defined to allow an upgrade using the same
|
||
option number. The original document did not specify a type field
|
||
since this would require at least one more byte, and it was felt at
|
||
the time that taking 19 bytes for the complete option (which would
|
||
probably be padded to 20 bytes in TCP implementations) would be too
|
||
much of a waste of the already limited option space.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Heffernan Standards Track [Page 4]
|
||
|
||
RFC 2385 TCP MD5 Signature Option August 1998
|
||
|
||
|
||
This does not prevent the deployment of another similar option which
|
||
uses another hashing algorithm (like SHA-1). Also, if most
|
||
implementations pad the 18 byte option as defined to 20 bytes anyway,
|
||
it would be just as well to define a new option which contains an
|
||
algorithm type field.
|
||
|
||
This would need to be addressed in another document, however.
|
||
|
||
4.5 Key configuration
|
||
|
||
It should be noted that the key configuration mechanism of routers
|
||
may restrict the possible keys that may be used between peers. It is
|
||
strongly recommended that an implementation 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.
|
||
|
||
5.0 Security Considerations
|
||
|
||
This document defines a weak but currently practiced security
|
||
mechanism for BGP. It is anticipated that future work will provide
|
||
different stronger mechanisms for dealing with these issues.
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Heffernan Standards Track [Page 5]
|
||
|
||
RFC 2385 TCP MD5 Signature Option August 1998
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that 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, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is 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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Heffernan Standards Track [Page 6]
|
||
|