draft-ietf-idr-bgp-tcp-md5-00.txt		rfc2385.txt
	INTERNET-DRAFT Andy Heffernan
	<draft-ietf-idr-bgp-tcp-md5-00.txt> cisco Systems		Network Working Group A. Heffernan
	March 12, 1998		Request for Comments: 2385 cisco Systems
			Category: Standards Track August 1998
	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 specifies an Internet standards track protocol for the
	documents of the Internet Engineering Task Force (IETF), its Areas,		Internet community, and requests discussion and suggestions for
	and its Working Groups. Note that other groups may also distribute		improvements. Please refer to the current edition of the "Internet
	working documents as Internet Drafts.		Official Protocol Standards" (STD 1) for the standardization state
			and status of this protocol. Distribution of this memo is unlimited.
	Internet Drafts are draft documents valid for a maximum of six		Copyright Notice
	months. Internet Drafts may be updated, replaced, or obsoleted by
	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
	draft" or "work in progress."
	Please check the I-D abstract listing contained in each Internet		Copyright (C) The Internet Society (1998). All Rights Reserved.
	Draft directory to learn the current status of this or any Internet
	Draft.
	IESG Note		IESG Note
	This document describes currrent existing practice for securing BGP		This document describes currrent existing practice for securing BGP
	against certain simple attacks. It is understood to have security		against certain simple attacks. It is understood to have security
	weaknesses against concerted attacks.		weaknesses against concerted attacks.
	Abstract		Abstract
	This memo describes a TCP extension to enhance security for BGP. It		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		defines a new TCP option for carrying an MD5 [RFC1321] digest in a
	TCP segment. This digest acts like a signature for that segment,		TCP segment. This digest acts like a signature for that segment,
	incorporating information known only to the connection end points.		incorporating information known only to the connection end points.
	Since BGP uses TCP as its transport, using this option in the way		Since BGP uses TCP as its transport, using this option in the way
	described in this paper significantly reduces the danger from certain		described in this paper significantly reduces the danger from certain
	security attacks on BGP.		security attacks on BGP.
	This document specifies an experimental protocol for use in the
	Internet.
	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
	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
	skipping to change at page 2, line 26		skipping to change at page 2, line 19
	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
	Every segment sent on a TCP connection to be protected against		Every segment sent on a TCP connection to be protected against
	spoofing will contain the 16-byte MD5 digest produced by applying the		spoofing will contain the 16-byte MD5 digest produced by applying the
	MD5 algorithm to these items in the following order:		MD5 algorithm to these items in the following order:
	1. the TCP pseudo-header (in the order: source IP address,		1. the TCP pseudo-header (in the order: source IP address,
	destination IP address, zero-padded protocol number, and segment		destination IP address, zero-padded protocol number, and
	length)		segment length)
	2. the TCP header, excluding options, and assuming a checksum of zero		2. the TCP header, excluding options, and assuming a checksum of
			zero
	3. the TCP segment data (if any)		3. the TCP segment data (if any)
	4. an independently-specified key or password, known to both TCPs		4. an independently-specified key or password, known to both TCPs
	and presumably connection-specific		and presumably connection-specific
	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
	skipping to change at page 4, line 34		skipping to change at page 4, line 32
	segment will be the initial SYN packet to start the connection. With		segment will be the initial SYN packet to start the connection. With
	MD5 signatures, the SYN packet will contain the following:		MD5 signatures, the SYN packet will contain the following:
	-- 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.		This sums to 40 bytes, which just makes it.
	4.4 MD5 as a Hashing Algorithm		4.4 MD5 as a Hashing Algorithm
	Since this draft was first issued (under a different title), the MD5		Since this memo was first issued (under a different title), the MD5
	algorithm has been found to be vulnerable to collision search attacks		algorithm has been found to be vulnerable to collision search attacks
	[Dobb], and is considered by some to be insufficiently strong for		[Dobb], and is considered by some to be insufficiently strong for
	this type of application.		this type of application.
	This draft still specifies the MD5 algorithm, however, since the		This memo still specifies the MD5 algorithm, however, since the
	option has already been deployed operationally, and there was no		option has already been deployed operationally, and there was no
	"algorithm type" field defined to allow an upgrade using the same		"algorithm type" field defined to allow an upgrade using the same
	option number. The original draft did not specify a type field since		option number. The original document did not specify a type field
	this would require at least one more byte, and it was felt at the		since this would require at least one more byte, and it was felt at
	time that taking 19 bytes for the complete option (which would		the time that taking 19 bytes for the complete option (which would
	probably be padded to 20 bytes in TCP implementations) would be too		probably be padded to 20 bytes in TCP implementations) would be too
	much of a waste of the already limited option space.		much of a 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.		algorithm type field.
	This would need to be addressed in another draft, however.		This would need to be addressed in another document, however.
	4.5 Key configuration		4.5 Key configuration
	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.		may restrict the possible keys that may be used between peers. It is
	Implementors should consider this issue in their design.		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		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.
	6.0 References		6.0 References
	[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.		April 1992.
	[RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions for		[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
	High Performance", RFC 1323, LBL, USC/Information Sciences Institute,		for High Performance", RFC 1323, May 1992.
	Cray Research, May 1992.
	[Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA		[Dobb] H. Dobbertin, "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
	cisco Systems		cisco Systems
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134 USA		San Jose, CA 95134 USA
	Phone: +1 408 526-8115		Phone: +1 408 526-8115
	Email: ahh@cisco.com		EMail: ahh@cisco.com
			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.
End of changes. 16 change blocks.
	37 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/