As per Relevance of the word standards, we have this rfc below:
Network Working Group A.
Request for Comments: 2385 cisco
Category: Standards Track August 1998
Protection of BGP Sessions via the TCP MD5 Signature
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
IESG
This document describes currrent existing practice for securing
against certain simple attacks. It is understood to have
weaknesses against concerted attacks
This memo describes a TCP extension to enhance security for BGP.
defines a new TCP option for carrying an MD5 [RFC1321] digest in
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
described in this paper significantly reduces the danger from
security attacks on BGP
1.0
The primary motivation for this option is to allow BGP to
itself against the introduction of spoofed TCP segments into
connection stream. Of particular concern are TCP resets
To spoof a connection using the scheme described in this paper,
attacker would not only have to guess TCP sequence numbers, but
also have had to obtain the password included in the MD5 digest
This password never appears in the connection stream, and the
form of the password is up to the application. It could even
Heffernan Standards Track [Page 1]
RFC 2385 TCP MD5 Signature Option August 1998
during the lifetime of a particular connection so long as this
was synchronized on both ends (although retransmission can
problematical in some TCP implementations with changing passwords).
Finally, there is no negotiation for the use of this option in
connection, rather it is purely a matter of site policy whether
not its connections use the option
2.0
Every segment sent on a TCP connection to be protected
spoofing will contain the 16-byte MD5 digest produced by applying
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,
segment length
2. the TCP header, excluding options, and assuming a checksum
3. the TCP segment data (if any
4. an independently-specified key or password, known to both
and presumably connection-
The header and pseudo-header are in network byte order. The
of the key is deliberately left unspecified, but it must be known
both ends of the connection. A particular TCP implementation
determine what the application may specify as the key
Upon receiving a signed segment, the receiver must validate it
calculating its own digest from the same data (using its own key)
comparing the two digest. A failing comparison must result in
segment being dropped and must not produce any response back to
sender. Logging the failure is probably advisable
Unlike other TCP extensions (e.g., the Window Scale
[RFC1323]), the absence of the option in the SYN,ACK segment must
cause the sender to disable its sending of signatures.
negotiation is typically done to prevent some TCP
from misbehaving upon receiving options in non-SYN segments. This
not a problem for this option, since the SYN,ACK sent
connection negotiation will not be signed and will thus be ignored
The connection will never be made, and non-SYN segments with
will never be sent. More importantly, the sending of signatures
be under the complete control of the application, not at the mercy
the remote host not understanding the option
Heffernan Standards Track [Page 2]
RFC 2385 TCP MD5 Signature Option August 1998
3.0
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
appear in every segment of a connection
4.0 Some
4.1 Connectionless
A connectionless reset will be ignored by the receiver of the reset
since the originator of that reset does not know the key, and
cannot generate the proper signature for the segment. This means
for example, that connection attempts by a TCP which is
signatures to a port with no listener will time out instead of
refused. Similarly, resets generated by a TCP in response
segments sent on a stale connection will also be ignored
Operationally this can be a problem since resets help BGP
quickly from peer crashes
4.2
The performance hit in calculating digests may inhibit the use
this option. Some measurements of a sample implementation
that on a 100 MHz R4600, generating a signature for simple
segment took an average of 0.0268 ms, while generating a
for a data segment carrying 4096 bytes of data took 0.8776 ms
average. These times would be applied to both the input and
paths, with the input path also bearing the cost of a 16-
compare
Heffernan Standards Track [Page 3]
RFC 2385 TCP MD5 Signature Option August 1998
4.3 TCP Header
As with other options that are added to every segment, the size
the MD5 option must be factored into the MSS offered to the
side during connection negotiation. Specifically, the size of
header to subtract from the MTU (whether it is the MTU of
outgoing interface or IP's minimal MTU of 576 bytes) is now at
18 bytes larger
The total header size is also an issue. The TCP header
where segment data starts with a 4-bit field which gives the
size of the header (including options) in 32-byte words. This
that the total size of the header plus option must be less than
equal to 60 bytes -- this leaves 40 bytes for options
As a concrete example, 4.4BSD defaults to sending window-scaling
timestamp information for connections it initiates. The most
segment will be the initial SYN packet to start the connection.
MD5 signatures, the SYN packet will contain the following
-- 4 bytes MSS
-- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD
-- 12 bytes for timestamp (4.4BSD pads the option as
in RFC 1323 Appendix A
-- 18 bytes for MD5
-- 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
Since this memo was first issued (under a different title), the MD
algorithm has been found to be vulnerable to collision search
[Dobb], and is considered by some to be insufficiently strong
this type of application
This memo still specifies the MD5 algorithm, however, since
option has already been deployed operationally, and there was
"algorithm type" field defined to allow an upgrade using the
option number. The original document did not specify a type
since this would require at least one more byte, and it was felt
the time that taking 19 bytes for the complete option (which
probably be padded to 20 bytes in TCP implementations) would be
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
uses another hashing algorithm (like SHA-1). Also, if
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
algorithm type field
This would need to be addressed in another document, however
4.5 Key
It should be noted that the key configuration mechanism of
may restrict the possible keys that may be used between peers. It
strongly recommended that an implementation be able to support
minimum a key composed of a string of printable ASCII of 80 bytes
less, as this is current practice
5.0 Security
This document defines a weak but currently practiced
mechanism for BGP. It is anticipated that future work will
different stronger mechanisms for dealing with these issues
6.0
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
April 1992.
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP
for High Performance", RFC 1323, May 1992.
[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack",
Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
http://www.rsa.com/rsalabs/pubs/cryptobytes.
Author's
Andy
cisco
170 West Tasman
San Jose, CA 95134
Phone: +1 408 526-8115
EMail: ahh@cisco.
Heffernan Standards Track [Page 5]
RFC 2385 TCP MD5 Signature Option August 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Heffernan Standards Track [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
