1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc2385.txt b/doc/rfc/rfc2385.txt
new file mode 100644
index 0000000..deeb0de
--- /dev/null
+++ b/doc/rfc/rfc2385.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+