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/