draft-ietf-6man-udpchecksums-07.txt		draft-ietf-6man-udpchecksums-08.txt
	Network Working Group M. Eubanks		Network Working Group M. Eubanks
	Internet-Draft AmericaFree.TV LLC		Internet-Draft AmericaFree.TV LLC
	Updates: 2460 (if approved) P. Chimento		Updates: 2460 (if approved) P. Chimento
	Intended status: Standards Track Johns Hopkins University Applied		Intended status: Standards Track Johns Hopkins University Applied
	Expires: July 21, 2013 Physics Laboratory		Expires: August 25, 2013 Physics Laboratory
	M. Westerlund		M. Westerlund
	Ericsson		Ericsson
	January 17, 2013		February 21, 2013
	IPv6 and UDP Checksums for Tunneled Packets		IPv6 and UDP Checksums for Tunneled Packets
	draft-ietf-6man-udpchecksums-07		draft-ietf-6man-udpchecksums-08
	Abstract		Abstract
	This document provides an update of the Internet Protocol version 6		This document provides an update of the Internet Protocol version 6
	(IPv6) specification (RFC2460) to improve the performance in the use		(IPv6) specification (RFC2460) to improve the performance in the use
	case where a tunnel protocol uses UDP with IPv6 to tunnel packets.		case where a tunnel protocol uses UDP with IPv6 to tunnel packets.
	The performance improvement is obtained by relaxing the IPv6 UDP		The performance improvement is obtained by relaxing the IPv6 UDP
	checksum requirement for any suitable tunnel protocol where header		checksum requirement for any suitable tunnel protocol where header
	information is protected on the "inner" packet being carried. This		information is protected on the "inner" packet being carried. This
	relaxation removes the overhead associated with the computation of		relaxation removes the overhead associated with the computation of
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 21, 2013.		This Internet-Draft will expire on August 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 27		skipping to change at page 2, line 27
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Analysis of Corruption in Tunnel Context . . . . . . . . . 5		4.1. Analysis of Corruption in Tunnel Context . . . . . . . . . 5
	4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7		4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7
	4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8		4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8
	5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 8		5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 8
	6. Additional Observations . . . . . . . . . . . . . . . . . . . 9		6. Additional Observations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 11		10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	10.2. Informative References . . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	This work constitutes an update of the Internet Protocol Version 6		This work constitutes an update of the Internet Protocol Version 6
	(IPv6) Specification [RFC2460], in the use case where a tunnel		(IPv6) Specification [RFC2460], in the use case where a tunnel
	protocol uses UDP with IPv6 to tunnel packets. With the rapid growth		protocol uses UDP with IPv6 to tunnel packets. With the rapid growth
	of the Internet, tunnel protocols have become increasingly important		of the Internet, tunnel protocols have become increasingly important
	to enable the deployment of new protocols. Tunnel protocols can be		to enable the deployment of new protocols. Tunnel protocols can be
	deployed rapidly, while the time to upgrade and deploy a critical		deployed rapidly, while the time to upgrade and deploy a critical
	skipping to change at page 3, line 52		skipping to change at page 3, line 52
	"Unicast UDP Usage Guidelines for Application Designers" [RFC5405]		"Unicast UDP Usage Guidelines for Application Designers" [RFC5405]
	should be consulted when reading this specification. It discusses		should be consulted when reading this specification. It discusses
	both UDP tunnels (Section 3.1.3) and the usage of checksums (Section		both UDP tunnels (Section 3.1.3) and the usage of checksums (Section
	3.4).		3.4).
	While the origin of this specification is the problem raised by the		While the origin of this specification is the problem raised by the
	draft titled "Automatic Multicast Tunnels", also known as "AMT"		draft titled "Automatic Multicast Tunnels", also known as "AMT"
	[I-D.ietf-mboned-auto-multicast] we expect it to have wide		[I-D.ietf-mboned-auto-multicast] we expect it to have wide
	applicability. Since the first version of this document, the need		applicability. Since the first version of this document, the need
	for an efficient UDP tunneling mechanism has increased. Other IETF		for an efficient UDP tunneling mechanism has increased. Other IETF
	Working Groups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619]		Working Groups, notably LISP [RFC6830] and Softwires [RFC5619] have
	have expressed a need to update the UDP checksum processing in RFC		expressed a need to update the UDP checksum processing in RFC 2460.
	2460. We therefore expect this update to be applicable in the future		We therefore expect this update to be applicable in the future to
	to other tunnel protocols specified by these and other IETF Working		other tunnel protocols specified by these and other IETF Working
	Groups.		Groups.
	2. Some Terminology		2. Some Terminology
	This document discusses only IPv6, since this problem does not exist		This document discusses only IPv6, since this problem does not exist
	for IPv4. Therefore all reference to 'IP' should be understood as a		for IPv4. Therefore all reference to 'IP' should be understood as a
	reference to IPv6.		reference to IPv6.
	The document uses the terms "tunneling" and "tunneled" as adjectives		The document uses the terms "tunneling" and "tunneled" as adjectives
	when describing packets. When we refer to 'tunneling packets' we		when describing packets. When we refer to 'tunneling packets' we
	skipping to change at page 9, line 21		skipping to change at page 9, line 21
	"Unlike IPv4, when UDP packets are originated by an IPv6 node, the		"Unlike IPv4, when UDP packets are originated by an IPv6 node, the
	UDP checksum is not optional. That is, whenever originating a UDP		UDP checksum is not optional. That is, whenever originating a UDP
	packet, an IPv6 node must compute a UDP checksum over the packet and		packet, an IPv6 node must compute a UDP checksum over the packet and
	the pseudo-header, and, if that computation yields a result of zero,		the pseudo-header, and, if that computation yields a result of zero,
	it must be changed to hex FFFF for placement in the UDP header. IPv6		it must be changed to hex FFFF for placement in the UDP header. IPv6
	receivers must discard UDP packets containing a zero checksum, and		receivers must discard UDP packets containing a zero checksum, and
	should log the error."		should log the error."
	This text should be replaced by:		This text should be replaced by:
	An IPv6 node associates a mode with each active UDP port.		An IPv6 node associates a mode with each used UDP port (for
			sending and/or receiving packets).
	Whenever originating a UDP packet for a port in the default mode,		Whenever originating a UDP packet for a port in the default mode,
	an IPv6 node MUST compute a UDP checksum over the packet and the		an IPv6 node MUST compute a UDP checksum over the packet and the
	pseudo-header, and, if that computation yields a result of zero,		pseudo-header, and, if that computation yields a result of zero,
	it MUST be changed to hex FFFF for placement in the UDP header.		it MUST be changed to hex FFFF for placement in the UDP header as
	IPv6 receivers MUST by default discard UDP packets containing a		specified in [RFC2460]. IPv6 receivers MUST by default discard
	zero checksum, and SHOULD log the error.		UDP packets containing a zero checksum, and SHOULD log the error.
	As an alternative, certain protocols that use UDP as a tunnel		As an alternative, certain protocols that use UDP as a tunnel
	encapsulation, MAY enable the zero-checksum mode for a specific		encapsulation, MAY enable the zero-checksum mode for a specific
	port (or set of ports). Any node implementing the zero-checksum		port (or set of ports) for sending and/or receiving. Any node
	mode MUST follow the node requirements specified in Section 4 of		implementing the zero-checksum mode MUST follow the node
	"Applicability Statement for the use of IPv6 UDP Datagrams with		requirements specified in Section 4 of "Applicability Statement
	Zero Checksums" [I-D.ietf-6man-udpzero].		for the use of IPv6 UDP Datagrams with Zero Checksums"
			[I-D.ietf-6man-udpzero].
	Any protocol that enables the zero-checksum mode for a specific		Any protocol that enables the zero-checksum mode for a specific
	port or ports MUST follow the usage requirements specified in		port or ports MUST follow the usage requirements specified in
	Section 5 of "Applicability Statement for the use of IPv6 UDP		Section 5 of "Applicability Statement for the use of IPv6 UDP
	Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero].		Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero].
	Middleboxes supporting IPv6 MUST follow requirements 9, 10 and 11		Middleboxes supporting IPv6 MUST follow requirements 9, 10 and 11
	of the usage requirements specified in Section 5 of "Applicability		of the usage requirements specified in Section 5 of "Applicability
	Statement for the use of IPv6 UDP Datagrams with Zero Checksums"		Statement for the use of IPv6 UDP Datagrams with Zero Checksums"
	[I-D.ietf-6man-udpzero].		[I-D.ietf-6man-udpzero].
	skipping to change at page 10, line 11		skipping to change at page 10, line 16
	This update was motivated by the existence of a number of protocols		This update was motivated by the existence of a number of protocols
	being developed in the IETF that are expected to benefit from the		being developed in the IETF that are expected to benefit from the
	change. The following observations are made:		change. The following observations are made:
	o An empirically-based analysis of the probabilities of packet		o An empirically-based analysis of the probabilities of packet
	corruption (with or without checksums) has not (to our knowledge)		corruption (with or without checksums) has not (to our knowledge)
	been conducted since about 2000. At the time of publication, it		been conducted since about 2000. At the time of publication, it
	is now 2012. We strongly suggest a new empirical study, along		is now 2012. We strongly suggest a new empirical study, along
	with an extensive analysis of the corruption probabilities of the		with an extensive analysis of the corruption probabilities of the
	IPv6 header.		IPv6 header. This can potentially allow revising the
			recommendations in this document.
	o A key motivation for the increase in use of UDP in tunneling is a		o A key motivation for the increase in use of UDP in tunneling is a
	lack of protocol support in middleboxes. Specifically, new		lack of protocol support in middleboxes. Specifically, new
	protocols, such as LISP [I-D.ietf-lisp], may prefer to use UDP		protocols, such as LISP [RFC6830], may prefer to use UDP tunnels
	tunnels to traverse an end-to-end path successfully and avoid		to traverse an end-to-end path successfully and avoid having their
	having their packets dropped by middleboxes. If middleboxes were		packets dropped by middleboxes. If middleboxes were updated to
	updated to support UDP-Lite [RFC3828], UDP-Lite would provide		support UDP-Lite [RFC3828], UDP-Lite would provide better
	better protection than offered by this update. This may be suited		protection than offered by this update. This may be suited to a
	to a variety of applications and would be expected to be preferred		variety of applications and would be expected to be preferred over
	over this method for many tunnel protocols.		this method for many tunnel protocols.
	o Another issue is that the UDP checksum is overloaded with the task		o Another issue is that the UDP checksum is overloaded with the task
	of protecting the IPv6 header for UDP flows (as is the TCP		of protecting the IPv6 header for UDP flows (as is the TCP
	checksum for TCP flows). Protocols that do not use a pseudo-		checksum for TCP flows). Protocols that do not use a pseudo-
	header approach to computing a checksum or CRC have essentially no		header approach to computing a checksum or CRC have essentially no
	protection from misdelivered packets.		protection from misdelivered packets.
	7. IANA Considerations		7. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	8. Security Considerations		8. Security Considerations
	Less work is required to generate an attack using a zero UDP checksum		Less work is required to generate an attack using a zero UDP checksum
	than one using a standard full UDP checksum. However, this does not		than one using a standard full UDP checksum. However, this does not
	lead to significant new vulnerabilities because checksums are not a		lead to significant new vulnerabilities because checksums are not a
	security measure and can be easily generated by any attacker.		security measure and can be easily generated by any attacker.
	Properly configured tunnels should check the validity of the inner
	packet and perform security checks.		In general any user of zero UDP checksums should apply the checks and
			context verification that are possible to minimize the risk of
			unintended traffic to reach a particular context. This will however
			not protect against an intended attack that create packet with the
			correct information. Source address validation can help prevent
			injection of traffic into contexts by an attacker.
			Depending on the hardware design, the processing requirements may
			differ for tunnels that have a zero UDP checksum and those that
			calculate a checksum. This processing overhead may need to be
			considered when deciding whether to enable a tunnel and to determine
			an acceptable rate for transmission. This can become a security risk
			for designs that can handle a significantly larger number of packets
			with zero UDP checksums compared to datagrams with a non-zero
			checksum, such as tunnel egress. An attacker could attempt to inject
			non-zero checksummed UDP packets into a tunnel forwarding zero
			checksum UDP packets and cause overload in the processing of the non-
			zero checksums, e.g. if this happens in a routers slow path.
			Protection mechanisms should therefore be employed when this threat
			exists. Protection may include source address filtering to prevent
			an attacker injecting traffic, as well as throttling the amount of
			non-zero checksum traffic. The latter may impact the function of the
			tunnel protocol.
	9. Acknowledgements		9. Acknowledgements
	We would like to thank Brian Haberman, Dan Wing, Joel Halpern and the		We would like to thank Brian Haberman, Dan Wing, Joel Halpern, David
	IESG of 2012 for discussions and reviews. Gorry Fairhurst has been		Waltermire, J.W. Atwood, Peter Yee, Joe Touch and the IESG of 2012
	very diligent in reviewing and help ensuring alignment between this		for discussions and reviews. Gorry Fairhurst has been very diligent
	document and [I-D.ietf-6man-udpzero].		in reviewing and help ensuring alignment between this document and
			[I-D.ietf-6man-udpzero].
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-6man-udpzero]		[I-D.ietf-6man-udpzero]
	Fairhurst, G. and M. Westerlund, "Applicability Statement		Fairhurst, G. and M. Westerlund, "Applicability Statement
	for the use of IPv6 UDP Datagrams with Zero Checksums",		for the use of IPv6 UDP Datagrams with Zero Checksums",
	draft-ietf-6man-udpzero-08 (work in progress),		draft-ietf-6man-udpzero-10 (work in progress),
	December 2012.		January 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-lisp]
	Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-24 (work in progress), November 2012.
	[I-D.ietf-mboned-auto-multicast]		[I-D.ietf-mboned-auto-multicast]
	Bumgardner, G., "Automatic Multicast Tunneling",		Bumgardner, G., "Automatic Multicast Tunneling",
	draft-ietf-mboned-auto-multicast-14 (work in progress),		draft-ietf-mboned-auto-multicast-14 (work in progress),
	June 2012.		June 2012.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.		Address Spoofing", BCP 38, RFC 2827, May 2000.
	[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and		[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
	skipping to change at page 12, line 5		skipping to change at page 12, line 28
	(UDP-Lite)", RFC 3828, July 2004.		(UDP-Lite)", RFC 3828, July 2004.
	[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines		[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
	for Application Designers", BCP 145, RFC 5405,		for Application Designers", BCP 145, RFC 5405,
	November 2008.		November 2008.
	[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,		[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
	"Softwire Security Analysis and Requirements", RFC 5619,		"Softwire Security Analysis and Requirements", RFC 5619,
	August 2009.		August 2009.
			[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
			Locator/ID Separation Protocol (LISP)", RFC 6830,
			January 2013.
	Authors' Addresses		Authors' Addresses
	Marshall Eubanks		Marshall Eubanks
	AmericaFree.TV LLC		AmericaFree.TV LLC
	P.O. Box 141		P.O. Box 141
	Clifton, Virginia 20124		Clifton, Virginia 20124
	USA		USA
	Phone: +1-703-501-4376		Phone: +1-703-501-4376
	Fax:		Fax:
End of changes. 18 change blocks.
	40 lines changed or deleted		65 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/