draft-ietf-idr-rfc2385bis-00.txt   draft-ietf-idr-rfc2385bis-01.txt 
INTERNET-DRAFT Andy Heffernan INTERNET-DRAFT Andy Heffernan
<draft-ietf-idr-rfc2385bis-00.txt> Juniper Networks <draft-ietf-idr-rfc2385bis-01.txt> Juniper Networks
January 2002 March 2002
Protection of BGP Sessions via the TCP MD5 Signature Option Protection of BGP Sessions via the TCP MD5 Signature Option
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
This document is an Internet-Draft and is subject to all This document is an Internet-Draft and is subject to all provisions
provisions of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working Drafts as reference material or to cite them other than as a "working
draft" or "work in progress." draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any Internet Draft directory to learn the current status of this or any Internet
Draft. Draft.
skipping to change at page 6, line ? skipping to change at line 46
security attacks on BGP. security attacks on BGP.
1.0 Introduction 1.0 Introduction
The primary motivation for this option is to allow BGP to protect The primary motivation for this option is to allow BGP to protect
itself against the introduction of spoofed TCP segments into the itself against the introduction of spoofed TCP segments into the
connection stream. Of particular concern are TCP resets. connection stream. Of particular concern are TCP resets.
To spoof a connection using the scheme described in this paper, an To spoof a connection using the scheme described in this paper, an
attacker would not only have to guess TCP sequence numbers, but would attacker would not only have to guess TCP sequence numbers, but would
Heffernan Expires September 1, 2002 [Page 1]
also have had to obtain the password included in the MD5 digest. also have had to obtain the password included in the MD5 digest.
This password never appears in the connection stream, and the actual This password never appears in the connection stream, and the actual
form of the password is up to the application. It could even change form of the password is up to the application. It could even change
Heffernan Expires July 1, 2002 [Page 1]
during the lifetime of a particular connection so long as this change during the lifetime of a particular connection so long as this change
was synchronized on both ends (although retransmission can become was synchronized on both ends (although retransmission can become
problematical in some TCP implementations with changing passwords). problematical in some TCP implementations with changing passwords).
Finally, there is no negotiation for the use of this option in a 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 connection, rather it is purely a matter of site policy whether or
not its connections use the option. not its connections use the option.
2.0 Proposal 2.0 Proposal
skipping to change at page 6, line ? skipping to change at line 95
For any other network protocol, the pseudo-header is as described in For any other network protocol, the pseudo-header is as described in
the document that defines how upper-level protocols like TCP compute the document that defines how upper-level protocols like TCP compute
their checksums. their checksums.
The header and pseudo-header are in network byte order. The nature 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 of the key is deliberately left unspecified, but it must be known by
both ends of the connection. A particular TCP implementation will both ends of the connection. A particular TCP implementation will
determine what the application may specify as the key. determine what the application may specify as the key.
Upon receiving a signed segment, the receiver must validate it by Upon receiving a signed segment, the receiver must validate it by
Heffernan Expires September 1, 2002 [Page 2]
calculating its own digest from the same data (using its own key) and calculating its own digest from the same data (using its own key) and
comparing the two digest. A failing comparison must result in the comparing the two digest. A failing comparison must result in the
segment being dropped and must not produce any response back to the segment being dropped and must not produce any response back to the
Heffernan Expires July 1, 2002 [Page 2]
sender. Logging the failure is probably advisable. sender. Logging the failure is probably advisable.
Unlike other TCP extensions (e.g., the Window Scale option Unlike other TCP extensions (e.g., the Window Scale option
[RFC1323]), the absence of the option in the SYN,ACK segment must not [RFC1323]), the absence of the option in the SYN,ACK segment must not
cause the sender to disable its sending of signatures. This cause the sender to disable its sending of signatures. This
negotiation is typically done to prevent some TCP implementations negotiation is typically done to prevent some TCP implementations
from misbehaving upon receiving options in non-SYN segments. This is from misbehaving upon receiving options in non-SYN segments. This is
not a problem for this option, since the SYN,ACK sent during not a problem for this option, since the SYN,ACK sent during
connection negotiation will not be signed and will thus be ignored. connection negotiation will not be signed and will thus be ignored.
The connection will never be made, and non-SYN segments with options The connection will never be made, and non-SYN segments with options
skipping to change at page 6, line ? skipping to change at line 143
4.0 Some Implications 4.0 Some Implications
4.1 Connectionless Resets 4.1 Connectionless Resets
A connectionless reset will be ignored by the receiver of the reset, 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 since the originator of that reset does not know the key, and so
cannot generate the proper signature for the segment. This means, cannot generate the proper signature for the segment. This means,
for example, that connection attempts by a TCP which is generating for example, that connection attempts by a TCP which is generating
signatures to a port with no listener will time out instead of being signatures to a port with no listener will time out instead of being
refused. Similarly, resets generated by a TCP in response to refused. Similarly, resets generated by a TCP in response to
Heffernan Expires September 1, 2002 [Page 3]
segments sent on a stale connection will also be ignored. segments sent on a stale connection will also be ignored.
Operationally this can be a problem since resets help BGP recover Operationally this can be a problem since resets help BGP recover
quickly from peer crashes. quickly from peer crashes.
Heffernan Expires July 1, 2002 [Page 3]
4.2 Performance 4.2 Performance
The performance hit in calculating digests may inhibit the use of The performance hit in calculating digests may inhibit the use of
this option. Some measurements of a sample implementation showed this option. Some measurements of a sample implementation showed
that on a 100 MHz R4600, generating a signature for simple ACK that on a 100 MHz R4600, generating a signature for simple ACK
segment took an average of 0.0268 ms, while generating a signature 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 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 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 paths, with the input path also bearing the cost of a 16-byte
compare. compare.
skipping to change at page 6, line ? skipping to change at line 190
-- 4 bytes MSS option -- 4 bytes MSS option
-- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD) -- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD)
-- 12 bytes for timestamp (4.4BSD pads the option as recommended -- 12 bytes for timestamp (4.4BSD pads the option as recommended
in RFC 1323 Appendix A) in RFC 1323 Appendix A)
-- 18 bytes for MD5 digest -- 18 bytes for MD5 digest
-- 2 bytes for end-of-option-list, to pad to a 32-bit boundary. -- 2 bytes for end-of-option-list, to pad to a 32-bit boundary.
This sums to 40 bytes, which just makes it. (Note that other padding This sums to 40 bytes, which just makes it. (Note that other padding
schemes are possible which would reduce the aggregate size.) schemes are possible which would reduce the aggregate size.)
4.4 Key configuration 4.4 Key Configuration
Heffernan Expires September 1, 2002 [Page 4]
It should be noted that the key configuration mechanism of routers It should be noted that the key configuration mechanism of routers
may restrict the possible keys that may be used between peers. It is may restrict the possible keys that may be used between peers. It is
strongly recommended that an implementation be able to support at strongly recommended that an implementation be able to support at
minimum a key composed of a string of printable ASCII of 80 bytes or minimum a key composed of a string of printable ASCII of 80 bytes or
Heffernan Expires July 1, 2002 [Page 4]
less, as this is current practice. less, as this is current practice.
5.0 Security Considerations 5.0 Security Considerations
This document defines a weak but currently practiced security This document defines a weak but currently practiced security
mechanism for BGP. It is anticipated that future work will provide mechanism for BGP. It is anticipated that future work will provide
different stronger mechanisms for dealing with these issues. different stronger mechanisms for dealing with these issues.
5.1 MD5 as a hashing algorithm 5.1 MD5 as a hashing algorithm
skipping to change at page 6, line ? skipping to change at line 227
padded to 20 bytes in TCP implementations) would be too much of a padded to 20 bytes in TCP implementations) would be too much of a
waste of the already limited option space. waste of the already limited option space.
This does not prevent the deployment of another similar option which This does not prevent the deployment of another similar option which
uses another hashing algorithm (like SHA-1). Also, if most uses another hashing algorithm (like SHA-1). Also, if most
implementations pad the 18 byte option as defined to 20 bytes anyway, 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 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 algorithm type field. This would need to be addressed in another
draft, however. draft, however.
5.2 Signature coverage 5.2 Signature Coverage
A further weakness exists due to the exclusion of option data from A further weakness exists due to the exclusion of option data from
the signature. This decision was made (as best as can be recalled) the signature. This decision was made to simplify the protocol
to simplify the protocol definition and implementation, but serves to definition and implementation, but might possibly leave a connection
leave a connection vulnerable since option data can be rewritten vulnerable since option data can be rewritten without detection.
without detection.
6.0 References 6.0 Changes from RFC 2385
The previous version of this specification was published as RFC 2385.
Heffernan Expires September 1, 2002 [Page 5]
The changes in this document are primarly to be more explicit about
the data over which the MD5 signature is taken. In particular,
Section 2.0 describes the differences between IPv4 and IPv6 and their
respective pseudo-header definitions.
Additionally, section 4.3 adds a note about option padding.
The former section 4.4 ("MD5 has a Hashing Algorithm") has moved to
the Security Considerations section of the document as section 5.1
and the former section 4.5 ("Key configuration") is now section 4.4.
Finally, section 5.2 has been added to mention that the signature
does not cover option data, which might be a vulnerability.
7.0 References
[RFC793] Postel, J., "Transmission Control Protocol," RFC 793, [RFC793] Postel, J., "Transmission Control Protocol," RFC 793,
September 1981. September 1981.
[RFC2460] Deering, S., and Hinden, R., "Internet Protocol, [RFC2460] Deering, S., and Hinden, R., "Internet Protocol,
Version 6 (IPv6) Specification," RFC 2460, December 1998. Version 6 (IPv6) Specification," RFC 2460, December 1998.
Heffernan Expires July 1, 2002 [Page 5]
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
MIT Laboratory for Computer Science, April 1992. MIT Laboratory for Computer Science, April 1992.
[RFC1323] Jacobson, V., Braden, R., and Borman, D., "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and Borman, D., "TCP Extensions
for High Performance", RFC 1323, LBL, USC/Information Sciences for High Performance", RFC 1323, LBL, USC/Information Sciences
Institute, Cray Research, May 1992. Institute, Cray Research, May 1992.
[Dobb] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA [Dobb] Dobbertin, H., "The Status of MD5 After a Recent Attack", RSA
Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
http://www.rsa.com/rsalabs/pubs/cryptobytes.html http://www.rsa.com/rsalabs/pubs/cryptobytes.html
Author's Address Author's Address
Andy Heffernan Andy Heffernan
Juniper Networks Juniper Networks
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 USA Sunnyvale, CA 94089 USA
Phone: +1 408 745-2037 Phone: +1 408 745-2037
Email: ahh@juniper.net Email: ahh@juniper.net
Heffernan Expires September 1, 2002 [Page 6]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/