draft-ietf-6man-udpchecksums-08.txt   rfc6935.txt 
Network Working Group M. Eubanks Internet Engineering Task Force (IETF) M. Eubanks
Internet-Draft AmericaFree.TV LLC Request for Comments: 6935 AmericaFree.TV LLC
Updates: 2460 (if approved) P. Chimento Updates: 2460 P. Chimento
Intended status: Standards Track Johns Hopkins University Applied Category: Standards Track Johns Hopkins University Applied
Expires: August 25, 2013 Physics Laboratory ISSN: 2070-1721 Physics Laboratory
M. Westerlund M. Westerlund
Ericsson Ericsson
February 21, 2013 April 2013
IPv6 and UDP Checksums for Tunneled Packets IPv6 and UDP Checksums for Tunneled Packets
draft-ietf-6man-udpchecksums-08
Abstract Abstract
This document provides an update of the Internet Protocol version 6 This document updates the IPv6 specification (RFC 2460) to improve
(IPv6) specification (RFC2460) to improve the performance in the use performance when a tunnel protocol uses UDP with IPv6 to tunnel
case where a tunnel protocol uses UDP with IPv6 to tunnel packets. packets. The performance improvement is obtained by relaxing the
The performance improvement is obtained by relaxing the IPv6 UDP IPv6 UDP checksum requirement for tunnel protocols whose header
checksum requirement for any suitable tunnel protocol where header information is protected on the "inner" packet being carried.
information is protected on the "inner" packet being carried. This Relaxing this requirement removes the overhead associated with the
relaxation removes the overhead associated with the computation of computation of UDP checksums on IPv6 packets that carry the tunnel
UDP checksums on IPv6 packets used to carry tunnel protocols. The protocol packets. This specification describes how the IPv6 UDP
specification describes how the IPv6 UDP checksum requirement can be checksum requirement can be relaxed when the encapsulated packet
relaxed for the situation where the encapsulated packet itself itself contains a checksum. It also describes the limitations and
contains a checksum. The limitations and risks of this approach are risks of this approach and discusses the restrictions on the use of
described, and restrictions specified on the use of the method. this method.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on August 25, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6935.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. 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 UDP Checksum Update . . . . . . . . . . . . . . . . . 9
6. Additional Observations . . . . . . . . . . . . . . . . . . . 10 6. Additional Observations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This work constitutes an update of the Internet Protocol Version 6 This document constitutes an update of the IPv6 specification
(IPv6) Specification [RFC2460], in the use case where a tunnel [RFC2460] for cases where a tunnel protocol uses UDP with IPv6 to
protocol uses UDP with IPv6 to tunnel packets. With the rapid growth tunnel packets. With the rapid growth of the Internet, tunnel
of the Internet, tunnel protocols have become increasingly important protocols have become increasingly important to enable the deployment
to enable the deployment of new protocols. Tunnel protocols can be of new protocols. Tunnel protocols can be deployed rapidly, while
deployed rapidly, while the time to upgrade and deploy a critical the time to upgrade and deploy a new protocol on a critical mass of
mass of routers, middleboxes and hosts on the global Internet for a routers, middleboxes, and hosts on the global Internet is now
new protocol is now measured in decades. At the same time, the measured in decades. At the same time, the increasing use of
increasing use of firewalls and other security-related middleboxes firewalls and other security-related middleboxes means that truly new
means that truly new tunnel protocols, with new protocol numbers, are tunnel protocols, with new protocol numbers, are also unlikely to be
also unlikely to be deployable in a reasonable time frame, which has deployable in a reasonable time frame. The result is an increasing
resulted in an increasing interest in and use of UDP-based tunnel interest in and use of UDP-based tunnel protocols. In such
protocols. In such protocols, there is an encapsulated "inner" protocols, there is an encapsulated "inner" packet, and the "outer"
packet, and the "outer" packet carrying the tunneled inner packet is packet carrying the tunneled inner packet is a UDP packet, which can
a UDP packet, which can pass through firewalls and other middleboxes pass through firewalls and other middleboxes that perform the
that perform filtering that is a fact of life on the current filtering that is a fact of life on the current Internet.
Internet.
Tunnel endpoints may be routers or middleboxes aggregating traffic Tunnel endpoints may be routers or middleboxes aggregating traffic
from a number of tunnel users, therefore the computation of an from a number of tunnel users. Therefore, the computation of an
additional checksum on the outer UDP packet may be seen as an additional checksum on the outer UDP packet may be seen as an
unwarranted burden on nodes that implement a tunnel protocol, unwarranted burden on nodes that implement a tunnel protocol,
especially if the inner packet(s) are already protected by a especially if the inner packets are already protected by a checksum.
checksum. In IPv4, there is a checksum over the IP packet header, IPv4 has a checksum over the IP packet header, and the checksum on
and the checksum on the outer UDP packet may be set to zero. However the outer UDP packet may be set to zero. However, IPv6 has no
in IPv6 there is no checksum in the IP header and RFC 2460 [RFC2460] checksum in the IP header, and RFC 2460 [RFC2460] explicitly states
explicitly states that IPv6 receivers MUST discard UDP packets with a that IPv6 receivers MUST discard UDP packets with a zero checksum.
zero checksum. So, while sending a UDP datagram with a zero checksum So, while sending a UDP datagram with a zero checksum is permitted in
is permitted in IPv4 packets, it is explicitly forbidden in IPv6 IPv4 packets, it is explicitly forbidden in IPv6 packets. To improve
packets. To improve support for IPv6 UDP tunnels, this document support for IPv6 UDP tunnels, this document updates RFC 2460 to allow
updates RFC 2460 to allow endpoints to use a zero UDP checksum under endpoints to use a zero UDP checksum under constrained situations
constrained situations (primarily IPv6 tunnel transports that carry (primarily for IPv6 tunnel transports that carry checksum-protected
checksum-protected packets), following the applicability statements packets), following the applicability statements and constraints in
and constraints in [I-D.ietf-6man-udpzero]. [RFC6936].
"Unicast UDP Usage Guidelines for Application Designers" [RFC5405] When reading this document, the advice in "Unicast UDP Usage
should be consulted when reading this specification. It discusses Guidelines for Application Designers" [RFC5405] is applicable. It
both UDP tunnels (Section 3.1.3) and the usage of checksums (Section discusses both UDP tunnels (Section 3.1.3) and the usage of checksums
3.4). (Section 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 [AMT], we expect it to have wide applicability. Since the first
applicability. Since the first version of this document, the need draft of this RFC was written, the need for an efficient UDP
for an efficient UDP tunneling mechanism has increased. Other IETF tunneling mechanism has increased. Other IETF Working Groups,
Working Groups, notably LISP [RFC6830] and Softwires [RFC5619] have notably LISP [RFC6830] and Softwires [RFC5619], have expressed a need
expressed a need to update the UDP checksum processing in RFC 2460. to update the UDP checksum processing in RFC 2460. We therefore
We therefore expect this update to be applicable in the future to expect this update to be applicable in the future to other tunnel
other tunnel protocols specified by these and other IETF Working protocols specified by these and other IETF Working Groups.
Groups.
2. Some Terminology 2. Terminology
This document discusses only IPv6, since this problem does not exist This document discusses only IPv6, because the problem being
for IPv4. Therefore all reference to 'IP' should be understood as a addressed does not exist for IPv4. Therefore, all references to "IP"
reference to IPv6. should be understood as references 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
refer to the outer packet header that provides the tunneling refer to the outer packet header that provides the tunneling
function. When we refer to 'tunneled packets' we refer to the inner function. When we refer to "tunneled packets", we refer to the inner
packet, i.e., the packet being carried in the tunnel. packet, i.e., the packet being carried in the tunnel.
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Problem Statement 3. Problem Statement
When using tunnel protocols based on UDP, there can be both a benefit When using tunnel protocols based on UDP, there can be both a benefit
and a cost to computing and checking the UDP checksum of the outer and a cost to computing and checking the UDP checksum of the outer
(encapsulating) UDP transport header. In certain cases, reducing the (encapsulating) UDP transport header. In certain cases, where
forwarding cost is important, e.g., for nodes that perform the reducing the forwarding cost is important, the cost of the
checksum in software the cost may outweigh the benefit. This computation may outweigh the benefit of the checksum. This document
document provides an update for usage of the UDP checksum with IPv6. provides an update for usage of the UDP checksum with IPv6. The
The update is specified for use by a tunnel protocol that transports update is specified for use by a tunnel protocol that transports
packets that are themselves protected by a checksum. packets that are themselves protected by a checksum.
4. Discussion 4. Discussion
"Applicability Statement for the use of IPv6 UDP Datagrams with Zero "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero
Checksums" [I-D.ietf-6man-udpzero] describes issues related to Checksums" [RFC6936] describes issues related to allowing UDP over
allowing UDP over IPv6 to have a valid zero UDP checksum and is the IPv6 to have a valid zero UDP checksum and is the starting point for
starting point for this discussion. Sections 4 and 5 of this discussion. Sections 4 and 5 of [RFC6936], respectively,
[I-D.ietf-6man-udpzero], respectively identify node implementation identify node implementation and usage requirements for datagrams
and usage requirements for datagrams sent and received with a zero sent and received with a zero UDP checksum. These sections introduce
UDP checksum. These introduce constraints on the usage of a zero constraints on the usage of a zero checksum for UDP over IPv6. The
checksum for UDP over IPv6. The remainder of this section analyses remainder of this section analyzes the use of general tunnels and
the use of general tunnels and motivates why tunnel protocols are explains the motivations for why tunnel protocols are being permitted
being permitted to use the method described in this update. Issues to use the method described in this update. It also discusses issues
with middleboxes are also discussed. with middleboxes.
4.1. Analysis of Corruption in Tunnel Context 4.1. Analysis of Corruption in Tunnel Context
This section analyzes the impact of the different corruption modes in This section analyzes the impact of the different corruption modes in
the context of a tunnel protocol. It indicates what needs to be the context of a tunnel protocol. It specifies what needs to be
considered by the designer and user of a tunnel protocol to be considered by the designer and user of a tunnel protocol for the
robust. It also summarizes why use of a zero UDP checksum is thought protocol to be robust. It also summarizes why use of a zero UDP
to be safe for deployment. checksum is thought to be safe for deployment.
1. Context (i.e., tunneling state) should be established by o Context (i.e., tunneling state) should be established by
exchanging application Protocol Data Units (PDUs) carried in exchanging application Protocol Data Units (PDUs) carried in
checksummed UDP datagrams or by other protocols with integrity checksummed UDP datagrams or by using other protocols that provide
protection against corruption. These control packets should also integrity protection against corruption. These control packets
carry any negotiation required to enable the tunnel endpoint to should also carry any negotiation required to enable the tunnel
accept UDP datagrams with a zero checksum and identify the set of endpoint to accept UDP datagrams with a zero checksum and identify
ports that are used. It is important that the control traffic is the set of ports that are used. It is important that the control
robust against corruption because undetected errors can lead to traffic is robust against corruption, because undetected errors
long-lived and significant failures that may affect much more can lead to long-lived and significant failures that may affect
than the single packet that was corrupted. much more than the single packet that was corrupted.
2. Keep-alive datagrams with a zero UDP checksum should be sent to o Keepalive datagrams with a zero UDP checksum should be sent to
validate the network path, because the path between tunnel validate the network path, because the path between tunnel
endpoints can change and therefore the set of middleboxes along endpoints can change, and therefore, the set of middleboxes along
the path may change during the life of an association. Paths the path may change during the life of an association. Paths with
with middleboxes that drop datagrams with a zero UDP checksum middleboxes that drop datagrams with a zero UDP checksum will drop
will drop these keep-alives. To enable the tunnel endpoints to these keepalives. To enable the tunnel endpoints to discover and
discover and react to this behavior in a timely way, the keep- react to this behavior in a timely way, the keepalive traffic
alive traffic should include datagrams with a non-zero checksum should include datagrams with a non-zero checksum and datagrams
and datagrams with a zero checksum. with a zero checksum.
3. Receivers should attempt to detect corruption of the address o Receivers should attempt to detect corruption of the address
information in an encapsulating packet. A robust tunnel protocol information in an encapsulating packet. A robust tunnel protocol
should track tunnel context based on the 5-tuple (tunneled should track tunnel context based on the 5-tuple (tunneled
protocol number, IPv6 source address, IPv6 destination address, protocol number, IPv6 source address, IPv6 destination address,
UDP source port, UDP destination port). A corrupted datagram UDP source port, UDP destination port). A corrupted datagram that
that arrives at a destination may be filtered based on this arrives at a destination may be filtered based on this check.
check.
* If the datagram header matches the 5-tuple and the node has * If the datagram header matches the 5-tuple and the node has
the zero checksum enabled for this port, the payload is enabled the zero checksum for this port, the payload is matched
matched to the wrong context. The tunneled packet will then to the wrong context. The tunneled packet will then be
be decapsulated and forwarded by the tunnel egress. decapsulated and forwarded by the tunnel egress.
* If a corrupted datagram matches a different 5-tuple and the * If a corrupted datagram matches a different 5-tuple and the
zero checksum was enabled for the port, the datagram payload node has enabled zero checksum for the port, the datagram
is matched to the wrong context, and may be processed by the payload is matched to the wrong context and may be processed by
wrong tunnel protocol, if it also passes the verification of the wrong tunnel protocol, provided that it also passes the
that protocol. verification of that protocol.
* If a corrupted datagram matches a 5-tuple and the zero * If a corrupted datagram matches a 5-tuple and node has not
checksum has not been enabled for this port, the datagram will enabled the zero checksum for this port, the datagram will be
be discarded. discarded.
When only the source information is corrupted, the datagram could When only the source information is corrupted, the datagram could
arrive at the intended applications/protocol, which will process arrive at the intended applications or protocol, which will
the datagram and try to match it against an existing tunnel process the datagram and try to match it against an existing
context. The likelihood that a corrupted packet enters a valid tunnel context. The likelihood that a corrupted packet enters a
context is reduced when the protocol restricts processing to only valid context is reduced when the protocol restricts processing to
the source addresses with established contexts. When both source only the source addresses with established contexts. When both
and destination fields are corrupted, this increases the source and destination fields are corrupted, this also decreases
likelihood of failing to match a context, with the exception of the likelihood of matching a context. However, the exception is
errors replacing one packet header with another one. In this when errors replace one packet header with another, so both
case, it is possible that both packets are tunnelled and packets could be tunneled, and therefore the corrupted packet
therefore the corrupted packet could match a previously defined could match a previously defined context.
context.
4. Receivers should attempt to detect corruption of source- o Receivers should attempt to detect corruption of source-fragmented
fragmented encapsulating packets. A tunnel protocol may encapsulating packets. A tunnel protocol may reassemble fragments
reassemble fragments associated with the wrong context at the associated with the wrong context at the right tunnel endpoint, it
right tunnel endpoint, or it may reassemble fragments associated may reassemble fragments associated with a context at the wrong
with a context at the wrong tunnel endpoint, or corrupted tunnel endpoint, or corrupted fragments may be reassembled at the
fragments may be reassembled at the right context at the right right context at the right tunnel endpoint. In each of these
tunnel endpoint. In each of these cases, the IPv6 length of the cases, the IPv6 length of the encapsulating header may be checked
encapsulating header may be checked (though (although [RFC6936] points out the weakness in this check). In
[I-D.ietf-6man-udpzero] points out the weakness in this check). addition, if the encapsulated packet is protected by a transport
In addition, if the encapsulated packet is protected by a (or other) checksum, these errors can be detected (with some
transport (or other) checksum, these errors can be detected (with probability).
some probability).
5. Tunnel protocols using UDP have some advantages that reduce the o Compared to other applications, tunnel protocols using UDP have
risk for a corrupted tunnel packet reaching a destination that some advantages that reduce the risk for a corrupted tunnel packet
will receive it, compared to other applications. This results reaching a destination that will receive it. These advantages
from processing by the network of the inner (tunneled) packet result from processing by the network of the inner (tunneled)
after being forwarded from the tunnel egress using a wrong packet after it is forwarded from the tunnel egress using a wrong
context: context:
* A tunneled packet may be forwarded to the wrong address * A tunneled packet may be forwarded to the wrong address domain,
domain, for example, a private address domain where the inner for example, to a private address domain where the inner
packet's address is not routable, or may fail a source address packet's address is not routable, or it may fail a source
check, such as Unicast Reverse Path Forwarding [RFC2827], address check, such as Unicast Reverse Path Forwarding
resulting in the packet being dropped. [RFC2827], resulting in the packet being dropped.
* The destination address of a tunneled packet may not at all be * The destination address of a tunneled packet may not be
reachable from the delivered domain. For example, an Ethernet reachable at all from the delivered domain. An example is an
frame where the destination MAC address is not present on the Ethernet frame where the destination MAC address is not present
LAN segment that was reached. on the LAN segment that was reached.
* The type of the tunneled packet may prevent delivery. For * The type of the tunneled packet may prevent delivery. For
example, an attempt to interpret an IP packet payload as an example, an attempt to interpret an IP packet payload as an
Ethernet frame, would likely to result in the packet being Ethernet frame would likely to result in the packet being
dropped as invalid. dropped as invalid.
* The tunneled packet checksum or integrity mechanism may detect * The tunneled packet checksum or integrity mechanism may detect
corruption of the inner packet caused at the same time as corruption of the inner packet caused at the same time as
corruption to the outer packet header. The resulting packet corruption to the outer packet header. The resulting packet
would likely be dropped as invalid. would likely be dropped as invalid.
These checks each significantly reduce the likelihood that a Each of these checks significantly reduces the likelihood that a
corrupted inner tunneled packet is finally delivered to a protocol corrupted inner tunneled packet is finally delivered to a protocol
listener that can be affected by the packet. While the methods do listener that can be affected by the packet. While the methods do
not guarantee correctness, they can reduce the risk of relaxing the not guarantee correctness, they can reduce the risks of relaxing the
UDP checksum requirement for a tunnel application using IPv6. UDP checksum requirement for a tunnel application using IPv6.
4.2. Limitation to Tunnel Protocols 4.2. Limitation to Tunnel Protocols
This document describes the applicability of using a zero UDP This document describes the applicability of using a zero UDP
checksum to support tunnel protocols. There are good motivations checksum to support tunnel protocols. There are good motivations
behind this and the arguments are provided here. behind this, and the arguments are provided here.
o Tunnels carry inner packets that have their own semantics, which o Tunnels carry inner packets that have their own semantics, which
may make any corruption less likely to reach the indicated may make any corruption less likely to reach the indicated
destination and be accepted as a valid packet. This is true for destination and be accepted as a valid packet. This is true for
IP packets with the addition of verification that can be made by IP packets with the addition of verification that can be made by
the tunnel protocol, the network processing of the inner packet the tunnel protocol, the network processing of the inner packet
headers as discussed above, and verification of the inner packet headers as discussed above, and verification of the inner packet
checksums. Non-IP inner packets are likely to be subject to checksums. Non-IP inner packets are likely to be subject to
similar effects that may reduce the likelihood of a misdelivered similar effects that may reduce the likelihood of a misdelivered
packet being delivered to a protocol listener that can be affected packet being delivered to a protocol listener that can be affected
by the packet. by the packet.
o Protocols that directly consume the payload must have sufficient o Protocols that directly consume the payload must have sufficient
robustness against misdelivered packets from any context, robustness against misdelivered packets (from any context),
including the ones that are corrupted in tunnels and any other including ones that are corrupted in tunnels or corrupted by other
usage of the zero checksum. This will require an integrity usage of the zero checksum. This will require an integrity
mechanism. Using a standard UDP checksum reduces the mechanism. Using a standard UDP checksum reduces the
computational load in the receiver to verify this mechanism. computational load in the receiver that is necessary to verify
this mechanism.
o The design for stateful protocols or protocols where corruption o The design for stateful protocols or protocols where corruption
causes cascade effects requires extra care. In tunnel usage, each causes cascade effects requires extra care. In tunnel usage, each
encapsulating packet provides only a transport mechanism from encapsulating packet provides no functions other than a transport
tunnel ingress to tunnel egress. A corruption will commonly only from tunnel ingress to tunnel egress. A corruption will commonly
affect the single tunneled packet, not the established protocol affect only the single tunneled packet, not the established
state. One common effect is that the inner packet flow will only protocol state. One common effect is that the inner packet flow
see a corruption and misdelivery of the outer packet as a lost will see only a corruption and a misdelivery of the outer packet
packet. as a lost packet.
o Some non-tunnel protocols operate with general servers that do not o Some non-tunnel protocols operate with general servers that do not
know the source from which they will receive a packet. In such know the source from which they will receive a packet. In such
applications, a zero UDP checksum is unsuitable because there is a applications, a zero UDP checksum is unsuitable, because it is
need to provide the first level of verification that the packet necessary to provide the first level of verification that the
was intended for the receiving server. A verification prevents packet was intended for the receiving server. A verification
the server from processing the datagram payload and without this prevents the server from processing the datagram payload; without
it may spend significant resources processing the packet, this, the server may spend significant resources processing the
including sending replies or error messages. packet, including sending replies or error messages.
Tunnel protocols that encapsulate IP will generally be safe for Tunnel protocols that encapsulate IP will generally be safe for
deployment, since all IPv4 and IPv6 packets include at least one deployment, because all IPv4 and IPv6 packets include at least one
checksum at either the network or transport layer. The network checksum at either the network or transport layer. The network
delivery of the inner packet will then further reduce the effects of delivery of the inner packet will then further reduce the effects of
corruption. Tunnel protocols carrying non-IP packets may offer corruption. Tunnel protocols carrying non-IP packets may offer
equivalent protection when the non-IP networks reduce the risk of equivalent protection when the non-IP networks reduce the risk of
misdelivery to applications. However, there is a need for further misdelivery to applications. However, further analysis is necessary
analysis to understand the implications of misdelievery of corrupted to understand the implications of misdelivery of corrupted packets
packets for that each non-IP protocol. The analysis above suggests for each non-IP protocol. The analysis above suggests that non-
that non-tunnel protocols can be expected to have significantly more tunnel protocols can be expected to have significantly more cases
cases where a zero checksum would result in misdelivery or negative where a zero checksum would result in misdelivery or negative side
side-effects. effects.
One unfortunate side-effect of increased use of a zero-checksum is One unfortunate side effect of increased use of a zero checksum is
that it also increases the likelihood of acceptance when a datagram that it also increases the likelihood of acceptance when a datagram
with a zero UDP checksum is misdelivered. This requires all tunnel with a zero UDP checksum is misdelivered. This requires all tunnel
protocols using this method to be designed to be robust to protocols using this method to be designed to be robust in the face
misdelivery. of misdelivery.
4.3. Middleboxes 4.3. Middleboxes
"Applicability Statement for the use of IPv6 UDP Datagrams with Zero "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero
Checksums" [I-D.ietf-6man-udpzero] notes that middleboxes that Checksums" [RFC6936] specifies requirements for middleboxes and
conform to RFC 2460 will discard datagrams with a zero UDP checksum tunnels that need to traverse middleboxes. Tunnel protocols
and should log this as an error. Tunnel protocols intending to use a intending to use a zero UDP checksum need to ensure that they have
zero UDP checksum need to ensure that they have defined a method for defined a method for handling cases when a middlebox prevents the
handling cases when a middlebox prevents the path between the tunnel path between the tunnel ingress and egress from supporting
ingress and egress from supporting transmission of datagrams with a transmission of datagrams with a zero UDP checksum. This is
zero UDP checksum. especially important as middleboxes that conform to RFC 2460 are
likely to discard datagrams with a zero UDP checksum.
5. The Zero-Checksum Update 5. The Zero UDP Checksum Update
This specification updates IPv6 to allow a zero UDP checksum in the This specification updates IPv6 to allow a zero UDP checksum in the
outer encapsulating datagram of a tunnel protocol. UDP endpoints outer encapsulating datagram of a tunnel protocol. UDP endpoints
that implement this update MUST follow the node requirements in that implement this update MUST follow the node requirements in
"Applicability Statement for the use of IPv6 UDP Datagrams with Zero "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero
Checksums" [I-D.ietf-6man-udpzero]. Checksums" [RFC6936].
The following text in [RFC2460] Section 8.1, 4th bullet should be The following text in [RFC2460], Section 8.1, fourth bullet should be
deleted: deleted:
"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
the pseudo-header, and, if that computation yields a result of zero, and the pseudo-header, and, if that computation yields a result of
it must be changed to hex FFFF for placement in the UDP header. IPv6 zero, it must be changed to hex FFFF for placement in the UDP
receivers must discard UDP packets containing a zero checksum, and header. IPv6 receivers must discard UDP packets containing a zero
should log the error." checksum, and should log the error.
This text should be replaced by: This text should be replaced by:
An IPv6 node associates a mode with each used UDP port (for An IPv6 node associates a mode with each used UDP port (for
sending and/or receiving packets). 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 as the checksum MUST be changed to hex FFFF for placement in the UDP
specified in [RFC2460]. IPv6 receivers MUST by default discard header, as specified in [RFC2460]. IPv6 receivers MUST by default
UDP packets containing a zero checksum, and SHOULD log the error. discard 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 zero-checksum mode for a specific port
port (or set of ports) for sending and/or receiving. Any node (or set of ports) for sending and/or receiving. Any node
implementing the zero-checksum mode MUST follow the node implementing zero-checksum mode MUST follow the node requirements
requirements specified in Section 4 of "Applicability Statement specified in Section 4 of "Applicability Statement for the use of
for the use of IPv6 UDP Datagrams with Zero Checksums" IPv6 UDP Datagrams with Zero Checksums" [RFC6936].
[I-D.ietf-6man-udpzero].
Any protocol that enables the zero-checksum mode for a specific Any protocol that enables zero-checksum mode for a specific port
port or ports MUST follow the usage requirements specified in or ports MUST follow the usage requirements specified in Section 5
Section 5 of "Applicability Statement for the use of IPv6 UDP of "Applicability Statement for the Use of IPv6 UDP Datagrams with
Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero]. Zero Checksums" [RFC6936].
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]. [RFC6936].
6. Additional Observations 6. Additional Observations
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 2013. We strongly suggest that a new empirical study be
with an extensive analysis of the corruption probabilities of the performed, along with extensive analysis of the corruption
IPv6 header. This can potentially allow revising the probabilities of the IPv6 header. This could potentially allow
recommendations in this document. 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 [RFC6830], may prefer to use UDP tunnels protocols, such as LISP [RFC6830], may prefer to use UDP tunnels
to traverse an end-to-end path successfully and avoid having their to traverse an end-to-end path successfully and avoid having their
packets dropped by middleboxes. If middleboxes were updated to packets dropped by middleboxes. If middleboxes were updated to
support UDP-Lite [RFC3828], UDP-Lite would provide better support UDP-Lite [RFC3828], UDP-Lite would provide better
protection than offered by this update. This may be suited to a protection than offered by this update. UDP-Lite may be suited to
variety of applications and would be expected to be preferred over a variety of applications and would be expected to be preferred
this method for many tunnel protocols. over 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. Security Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
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.
In general any user of zero UDP checksums should apply the checks and In general, any user of zero UDP checksums should apply the checks
context verification that are possible to minimize the risk of and context verification that are possible to minimize the risk of
unintended traffic to reach a particular context. This will however unintended traffic to reach a particular context. This will,
not protect against an intended attack that create packet with the however, not protect against an intentional attack that creates
correct information. Source address validation can help prevent packets with the correct information. Source address validation can
injection of traffic into contexts by an attacker. help prevent injection of traffic into contexts by an attacker.
Depending on the hardware design, the processing requirements may Depending on the hardware design, the processing requirements may
differ for tunnels that have a zero UDP checksum and those that differ for tunnels that have a zero UDP checksum and those that
calculate a checksum. This processing overhead may need to be calculate a checksum. This processing overhead may need to be
considered when deciding whether to enable a tunnel and to determine considered when deciding whether to enable a tunnel and to determine
an acceptable rate for transmission. This can become a security risk an acceptable rate for transmission. This processing overhead can
for designs that can handle a significantly larger number of packets become a security risk for designs that can handle a significantly
with zero UDP checksums compared to datagrams with a non-zero larger number of packets with zero UDP checksums compared to
checksum, such as tunnel egress. An attacker could attempt to inject datagrams with a non-zero checksum, such as a tunnel egress. An
non-zero checksummed UDP packets into a tunnel forwarding zero attacker could attempt to inject non-zero checksummed UDP packets
checksum UDP packets and cause overload in the processing of the non- into a tunnel forwarding zero checksum UDP packets and cause overload
zero checksums, e.g. if this happens in a routers slow path. in the processing of the non-zero checksums, e.g., if this happens in
Protection mechanisms should therefore be employed when this threat a router's slow path. Therefore, protection mechanisms should be
exists. Protection may include source address filtering to prevent employed when this threat exists. Protection may include source-
an attacker injecting traffic, as well as throttling the amount of address filtering to prevent an attacker from injecting traffic, as
non-zero checksum traffic. The latter may impact the function of the well as throttling the amount of non-zero checksum traffic. The
tunnel protocol. latter may impact the functioning of the tunnel protocol.
9. Acknowledgements 8. Acknowledgments
We would like to thank Brian Haberman, Dan Wing, Joel Halpern, David We would like to thank Brian Haberman, Dan Wing, Joel Halpern, David
Waltermire, J.W. Atwood, Peter Yee, Joe Touch and the IESG of 2012 Waltermire, J.W. Atwood, Peter Yee, Joe Touch, and the IESG of 2012
for discussions and reviews. Gorry Fairhurst has been very diligent for discussions and reviews. Gorry Fairhurst has been very diligent
in reviewing and help ensuring alignment between this document and in reviewing and helping to ensure alignment between this document
[I-D.ietf-6man-udpzero]. and [RFC6936].
10. References
10.1. Normative References 9. References
[I-D.ietf-6man-udpzero] 9.1. Normative References
Fairhurst, G. and M. Westerlund, "Applicability Statement
for the use of IPv6 UDP Datagrams with Zero Checksums",
draft-ietf-6man-udpzero-10 (work in progress),
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 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, April 2013.
[I-D.ietf-mboned-auto-multicast] 9.2. Informative References
Bumgardner, G., "Automatic Multicast Tunneling",
draft-ietf-mboned-auto-multicast-14 (work in progress), [AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work
June 2012. in Progress, 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
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(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
skipping to change at page 12, line 41 skipping to change at page 12, line 26
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: EMail: marshall.eubanks@gmail.com
Email: marshall.eubanks@gmail.com
P.F. Chimento P.F. Chimento
Johns Hopkins University Applied Physics Laboratory Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723 Laurel, Maryland 20723
USA USA
Phone: +1-443-778-1743 Phone: +1-443-778-1743
Email: Philip.Chimento@jhuapl.edu EMail: Philip.Chimento@jhuapl.edu
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 719 00 00
Email: magnus.westerlund@ericsson.com EMail: magnus.westerlund@ericsson.com
 End of changes. 75 change blocks. 
314 lines changed or deleted 294 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/