draft-ietf-6man-udpchecksums-05.txt   draft-ietf-6man-udpchecksums-06.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: April 25, 2013 Physics Laboratory Expires: June 14, 2013 Physics Laboratory
M. Westerlund M. Westerlund
Ericsson Ericsson
October 22, 2012 December 11, 2012
UDP Checksums for Tunneled Packets IPv6 and UDP Checksums for Tunneled Packets
draft-ietf-6man-udpchecksums-05 draft-ietf-6man-udpchecksums-06
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 of IPv6 in (IPv6) specification (RFC2460) to improve the performance in the use
the use case when a tunnel protocol uses UDP with IPv6 to tunnel case when 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 suitable tunneling protocol where checksum requirement for suitable tunneling protocol where header
header information is protected on the "inner" packet being carried. information is protected on the "inner" packet being carried. This
This relaxation removes the overhead associated with the computation relaxation removes the overhead associated with the computation of
of UDP checksums on IPv6 packets used to carry tunnel protocols and UDP checksums on IPv6 packets used to carry tunnel protocols. The
thereby improves the efficiency of the traversal of firewalls and specification describes how the IPv6 UDP checksum requirement can be
other network middleboxes by such protocols. We describe how the relaxed for the situation where the encapsulated packet itself
IPv6 UDP checksum requirement can be relaxed in the situation where contains a checksum. The limitations and risks of this approach are
the encapsulated packet itself contains a checksum, the limitations described, and restrictions specified on the use of the method.
and risks of this approach, and define restrictions on the use of
this relaxation to mitigate these risks.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 25, 2013. This Internet-Draft will expire on June 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 24 skipping to change at page 2, line 23
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. 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
5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 7 4.1. Analysis of Corruption in Tunnel Context . . . . . . . . . 5
6. Additional Observations . . . . . . . . . . . . . . . . . . . 8 4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Additional Observations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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 when a tunnel (IPv6) Specification [RFC2460], in the use case when 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, tunneling protocols have become increasingly of the Internet, tunneling protocols have become increasingly
important to enable the deployment of new protocols. Tunneled important to enable the deployment of new protocols. Tunneled
protocols can be deployed rapidly, while the time to upgrade and protocols can be deployed rapidly, while the time to upgrade and
deploy a critical mass of routers, switches and end hosts on the deploy a critical mass of routers, middleboxes and hosts on the
global Internet for a new protocol is now measured in decades. At global Internet for a new protocol is now measured in decades. At
the same time, the increasing use of firewalls and other security the same time, the increasing use of firewalls and other security-
related middleboxes means that truly new tunnel protocols, with new related middleboxes means that truly new tunnel protocols, with new
protocol numbers, are also unlikely to be deployable in a reasonable protocol numbers, are also unlikely to be deployable in a reasonable
time frame, which has resulted in an increasing interest in and use time frame, which has resulted in an increasing interest in and use
of UDP-based tunneling protocols. In such protocols, there is an of UDP-based tunneling protocols. In such protocols, there is an
encapsulated "inner" packet, and the "outer" packet carrying the encapsulated "inner" packet, and the "outer" packet carrying the
tunneled inner packet is a UDP packet, which can pass through tunneled inner packet is a UDP packet, which can pass through
firewalls and other middleboxes filtering that is a fact of life on firewalls and other middleboxes that perform filtering that is a fact
the current Internet. of life on the current Internet.
Tunnel endpoints may be routers or middleboxes aggregating traffic Tunnel endpoints may be routers or middleboxes aggregating traffic
from a large 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 tunneling protocol, unwarranted burden on nodes that implement a tunneling protocol,
especially if the inner packet(s) are already protected by a especially if the inner packet(s) are already protected by a
checksum. In IPv4, there is a checksum on the IP packet itself, and checksum. In IPv4, there is a checksum over the IP packet header,
the checksum on the outer UDP packet can be set to zero. However in and the checksum on the outer UDP packet may be set to zero. However
IPv6 there is not a checksum on the IP packet and RFC 2460 [RFC2460] in IPv6 there is no checksum in the IP header and RFC 2460 [RFC2460]
explicitly states that IPv6 receivers MUST discard UDP packets with a explicitly states that IPv6 receivers MUST discard UDP packets with a
zero checksum. So, while sending a UDP packet with a zero checksum zero checksum. So, while sending a UDP datagram with a zero checksum
is permitted in IPv4 packets, it is explicitly forbidden in IPv6 is permitted in IPv4 packets, it is explicitly forbidden in IPv6
packets. To improve support for IPv6 UDP tunnels, this document packets. To improve support for IPv6 UDP tunnels, this document
updates RFC 2460 to allow tunnel endpoints to use a zero UDP checksum updates RFC 2460 to allow endpoints to use a zero UDP checksum under
under constrained situations (IPv6 tunnel transports that carry constrained situations (primarily IPv6 tunnel transports that carry
checksum-protected packets), following the considerations in checksum-protected packets), following the applicability statements
[I-D.ietf-6man-udpzero]. and constraints in [I-D.ietf-6man-udpzero].
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 IP Multicast Without Explicit Tunnels", also draft titled "Automatic IP Multicast Without Explicit Tunnels", also
known as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have known as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have
wide applicability. Since the first version of this document, the wide applicability. Since the first version of this document, the
need for an efficient UDP tunneling mechanism has increased. Other need for an efficient UDP tunneling mechanism has increased. Other
IETF Working Groups, notably LISP [I-D.ietf-lisp] and Softwires IETF Working Groups, notably LISP [I-D.ietf-lisp] and Softwires
[RFC5619] have expressed a need to update the UDP checksum processing [RFC5619] have expressed a need to update the UDP checksum processing
in RFC 2460. We therefore expect this update to be applicable in in RFC 2460. We therefore expect this update to be applicable in
future to other tunneling protocols specified by these and other IETF future to other tunneling protocols specified by these and other IETF
Working Groups. Working Groups.
2. Some Terminology 2. Some Terminology
For the remainder of this document, we discuss only IPv6, since this This document discusses only IPv6, since this problem does not exist
problem does not exist for IPv4. Therefore all reference to 'IP' for IPv4. Therefore all reference to 'IP' should be understood as a
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
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
This document provides an update for the case where a tunnel protocol When using tunnel protocols based on UDP, there can be both a benefit
transports tunneled packets that already have a transport header with and a cost to computing and checking the UDP checksum of the outer
a checksum. There is both a benefit and a cost to computing and (encapsulating) UDP transport header. In certain cases, where
checking the UDP checksum of the outer (encapsulating) UDP transport reducing the forwarding cost is important, such as for nodes that
header. In certain cases, where reducing the forwarding cost is perform the checksum in software, where the cost may outweigh the
important, such as for systems that perform the check in software, benefit. This document provides an update for usage of the UDP
the cost may outweigh the benefit; this document describes a means to checksum with IPv6. The update is specified for use by a tunnel
avoid that cost. In the case where there is an inner header with a protocol that transports packets that are themselves protected by a
checksum. checksum.
4. Discussion 4. Discussion
IPv6 UDP Checksum Considerations [I-D.ietf-6man-udpzero] describes Applicability Statement for the use of IPv6 UDP Datagrams with Zero
the issues related to allowing UDP over IPv6 to have a valid checksum Checksums [I-D.ietf-6man-udpzero] describes issues related to
of zero and is not repeated here. allowing UDP over IPv6 to have a valid zero UDP checksum and is the
starting point for this discussion. Section 4 and 5 of
Section 5 and 6 of [I-D.ietf-6man-udpzero], identifies node and inner [I-D.ietf-6man-udpzero], respectively identify node implementation
protocol requirements respectively that introduce constraints on the and usage requirements for datagrams sent and received with a zero
usage of a zero checksum for UDP over IPv6. This document is UDP checksum. These introduce constraints on the usage of a zero
intended to satisfy these requirements. checksum for UDP over IPv6. The remainder of this section analyses
the use of general tunnels and motivates why tunnel protocols are
being permitted to use the method described in this update. Issues
with middleboxes are also discussed.
[I-D.ietf-6man-udpzero] and mailing list discussions have noted there 4.1. Analysis of Corruption in Tunnel Context
is still the possibility of deep-inspection firewall devices or other
middleboxes checking the UDP checksum field of the outer packet and
thereby discarding the tunneling packets. This would be an issue
also for any legacy IPv6 system that has not implemented this update
to the IPv6 specification. In this case, the system (according to
RFC 2460) will discard the zero-checksum UDP packets, and should log
this as an error.
The points below discuss how path errors can be detected and handled This section analyzes the impact of the different corruption modes in
in an UDP tunneling protocol when the checksum protection is the context of a tunnel protocol. It indicates what needs to be
disabled. Note that other (non-tunneling) protocols may have considered by the designer and user of a tunnel protocol to be
different approaches, but these are not the topic of this update. We robust. It also summarizes why use of a zero UDP checksum is thought
propose the following approach to handle this problem: safe for deployment.
o Context (i.e. tunneling state) should be established via o Context (i.e. tunneling state) should be established by exchanging
application Protocol Data Units (PDUs) that are carried in application Protocol Data Units (PDUs) carried in checksummed UDP
checksummed UDP packets. That is, any control packets flowing datagrams or by other protocols with integrity protection against
between the tunnel endpoints should be protected by UDP checksums. corruption. These control packets should also carry any
The control packets can also contain any negotiation required to negotiation required to enable the tunnel endpoint to accept UDP
enable the endpoint/adapters to accept UDP packets with a zero datagrams with a zero checksum and identify the set of ports that
checksum. The control packets may also carry any negotiation are used. It is important that the control traffic is robust
required to enable the endpoint/adapters to identify the set of against corruption because undetected errors can lead to long-
ports that need to enable reception of UDP datagrams with a zero lived and significant failures that affect not only the single
checksum. packet that was corrupted.
o A system never sets the UDP checksum to zero in packets that do o Keep-alive datagrams with a zero UDP checksum should be sent to
not contain tunneled packets. validate the network path, because the path between tunnel
endpoints can change and therefore the set of middleboxes along
the path may change during the life of an association. Paths with
middleboxes that drop datagrams with a zero UDP checksum will drop
these keep-alives. To enable the tunnel endpoints to discover and
react to this behavior in a timely way, the keep-alive traffic
should include datagrams with both a non-zero checksum and ones
with a zero checksum.
o UDP keep-alive packets with checksum zero can be sent to validate o Corruption of the address information in an encapsulating packets,
paths, given that paths between tunnel endpoints can change and so i.e. IPv6 source address, destination address and/or the UDP
middleboxes in the path may vary during the life of the source port, and destination port fields. A robust tunnel
association. Paths with middleboxes that are intolerant of a UDP protocol should track tunnel context based on the 5-tuple, i.e.
checksum of zero will drop the keep-alives and the endpoints will the protocol and both the address and port for both the source and
discover that. Note that this need only be done per tunnel destination. A corrupted datagram that arrives at a destination
endpoint pair, not per tunnel context. Keep-alive traffic can may be filtered based on this check.
include both packets with tunnel checksums and packets with
checksums equal to zero to enable the remote end to distinguish
between path failures and the blockage of packets with checksum
equal to zero.
o Corruption of the encapsulating IPv6 source address, destination * If the datagram header matches the 5-tuple with a zero checksum
address and/or the UDP source port, and destination port fields : enabled, the payload is matched to the wrong context. The
If the restrictions in [I-D.ietf-6man-udpzero] are followed, the tunneled packet will then be decapsulated and forwarded by the
inner packets (tunneled packets) will be protected and run the tunnel egress.
usual (presumably small) risk of having undetected corruption(s).
If tunneling protocol contexts contain (at a minimum) source and
destination IP addresses and source and destination ports, there
are 16 possible corruption outcomes. We note that these outcomes
are not equally likely. The possible corruption outcomes may be:
* Half of the 16 possible corruption combinations have a * If a corrupted datagram matches a different 5-tuple with a zero
corrupted destination address. If the incorrect destination is checksum enabled, the payload is matched to the wrong context,
reached and the node doesn't have an application for the and may be processed by the wrong tunneling protocol, if it
destination port, the packet will be dropped. If the passes the verification of that protocol.
application at the incorrect destination is the same tunneling
protocol and if it has a matching context (which can be assumed
to be a very low probability event) the inner packet will be
decapsulated and forwarded. Application developers can verify
the context of the packets they receive using UDP, as described
in [RFC5405]. Applications that verify the context of a
datagram are expected to have a high probability of discarding
corrupted data. [I-D.ietf-6man-udpzero] presents examples of
cases where corruption can inadvertently impact application
state.
* Half of the 8 possible corruption combinations with a correct * If a corrupted datagram matches a 5-tuple that does not have a
destination address have a corrupted source address. If the zero checksum enabled, it will be discarded.
tunnel contexts contain all elements of the address-port
4-tuple, then the likelihood is that this corruption will be
detected. It may in fact be discarded on route due to source
address validation techniques, such as Unicast Reverse Path
Forwarding [RFC2827].
* Of the remaining 4 possibilities, with valid source and When only the source information is corrupted, the datagram could
destination IPv6 addresses, one has all 4 fields valid, the arrive at the intended applications/protocol which will process it
other three have one or both ports corrupted. Again, if the and try to match it against an existing tunnel context. If the
tunneling endpoint context contains sufficient information, protocol restricts processing to only the source addresses with
these errors should be detected with high probability. established contexts the likelihood that a corrupted packet enters
a valid context is reduced. When both source and destination
fields are corrupted, this increases the likelihood of failing to
match a context, with the exception of errors replacing one packet
header with another one. In this case it is possible that both
are tunnels and thus the corrupted packet can match a previously
defined context.
o Corruption of source-fragmented encapsulating packets: In this o Corruption of source-fragmented encapsulating packets: In this
case, a tunneling protocol may reassemble fragments associated case, a tunneling protocol may reassemble fragments associated
with the wrong context at the right tunnel endpoint, or it may with the wrong context at the right tunnel endpoint, or it may
reassemble fragments associated with a context at the wrong tunnel reassemble fragments associated with a context at the wrong tunnel
endpoint, or corrupted fragments may be reassembled at the right endpoint, or corrupted fragments may be reassembled at the right
context at the right tunnel endpoint. In each of these cases, the context at the right tunnel endpoint. In each of these cases, the
IPv6 length of the encapsulating header may be checked (though IPv6 length of the encapsulating header may be checked (though
[I-D.ietf-6man-udpzero] points out the weakness in this check). [I-D.ietf-6man-udpzero] points out the weakness in this check).
In addition, if the encapsulated packet is protected by a In addition, if the encapsulated packet is protected by a
transport (or other) checksum, these errors can be detected (with transport (or other) checksum, these errors can be detected (with
some probability). some probability).
While they do not guarantee correctness, these mechanism can reduce o Tunnel protocols using UDP have some advantages that reduce the
the risks of relaxing the UDP checksum requirement for IPv6. risk for a corrupted tunnel packet reaching a destination that
will receive it, compared to other applications. This results
from processing by the network of the inner (tunneled) packet
after being forwarded from the tunnel egress using a wrong
context:
* A tunneled packet may be forwarded to the wrong address domain,
for example a private address domain where the inner packet's
address is not routable, or may fail a source address check,
such as Unicast Reverse Path Forwarding [RFC2827], resulting in
the packet being dropped.
* The destination address of a tunneled packet may not at all be
reachable from the delivered domain. For example an Ethernet
packet where the destination MAC address is not present on the
LAN segment that was reached.
* The type of the tunneled packet may prevent delivery for
example if an IP packet payload was attempted to be interpreted
as an Ethernet packet. This is likely to result in the packet
being dropped as invalid.
* The tunneled packet checksum or integrity mechanism may detect
corruption of the inner packet caused at the same time as
corruption to the outer packet header. The resulting packet
would likely be dropped as invalid.
These different examples each help to significantly reduce the
likelihood that a corrupted inner tunneled packet is finally
delivered to a protocol listener that can be affected by the packet.
While the methods do not guarantee correctness, they can reduce the
risk of relaxing the UDP checksum requirement for a tunnel
application using IPv6.
4.2. Limitation to Tunnel Protocols
This document describes the applicability of using a zero UDP
checksum to support tunnel protocols. There are good motivations
behind this and the arguments are provided here.
o Tunnels carry inner packets that have their own semantics that
makes any corruption less likely to reach the indicated
destination and be accepted as a valid packet. This is true for
IP packets with the addition of verification that can be made by
the tunnel protocol, the networks' processing of the inner packet
headers as discussed above, and verification of the inner packet
checksums. Also non-IP inner packets are likely to be subject to
similar effects that reduce the likelihood that an mis-delivered
packet are delivered.
o Protocols that directly consume the payload must have sufficient
robustness against mis-delivered packets from any context,
including the ones that are corrupted in tunnels and any other
usage of the zero checksum. This will require an integrity
mechanism. Using a standard UDP checksum reduces the
computational load in the receiver to verify this mechanism.
o Stateful protocols or protocols where corruption causes cascade
effects need to be extra careful. In tunnel usage each
encapsulating packet provides only a transport mechanism from
tunnel ingress to tunnel egress. A corruption will commonly only
effect the single packet, not established protocol state. One
common effect is that the inner packet flow will only see a
corruption and mis-delivery of the outer packet as a lost packet.
o Some non-tunnel protocols operate with general servers that do not
know from where they will receive a packet. In such applications,
the usage of a zero UDP checksum is especially unsuitable because
there is a need to provide the first level of verification that
the packet was intended for the server. This verification
prevents the server from processing the datagram payload and spend
any significant amount of resources on it, including sending
replies or error messages.
Tunnel protocols encapsulating IP this will generally be safe, since
all IPv4 and IPv6 packets include at least one checksum at either the
network or transport layer and the network delivery of the inner
packet will further reduce the effects of corruption. Tunnel
protocols carrying non-IP packets may provide equivalent protection
due to the non-IP networks reducing the risk of delivery to
applications. However, there is need for further analysis to
understand the implications of mis-delievery of corrupted packets for
that each non-IP protocol. The analysis above suggests that non-
tunnel protocols can be expected to have significantly more cases
where a zero checksum would result in mis-delivery or negative side-
effects.
One unfortunate side-effect of increased use of a zero-checksum is
that it also increases the likelihood of acceptance when a datagram
with a zero UDP checksum is mis-delivered. This requires all tunnel
protocols using this method to be designed to be robust to mis-
delivery.
4.3. Middleboxes
Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums [I-D.ietf-6man-udpzero] notes that middlebox devices that
conform to RFC 2460 will discard datagrams with a zero UDP checksum
and should log this as an error. Thus tunnel protocols intending to
use a zero UDP checksum needs to ensure that they have defined a
method for handling cases when a middlebox prevents the path between
the tunnel ingress and egress from supporting transmission of
datagrams with a zero UDP checksum.
5. The Zero-Checksum Update 5. The Zero-Checksum Update
This specification updates IPv6 to allow a UDP checksum of zero for This specification updates IPv6 to allow a zero UDP checksum in the
the outer encapsulating packet of a tunneling protocol. UDP outer encapsulating datagram of a tunneling protocol. UDP endpoints
endpoints that implement this update MUST change their behavior for that implement this update MUST follow the node requirements
any destination port explicitly configured for zero checksum and MUST "Applicability Statement for the use of IPv6 UDP Datagrams with Zero
NOT discard UDP packets received with a checksum value of zero on the Checksums" [I-D.ietf-6man-udpzero].
outer packet. When this is done, it requires the constraints in
Section 5 and 6 of [I-D.ietf-6man-udpzero].
Specifically, the text in [RFC2460] Section 8.1, 4th bullet is The following text in [RFC2460] Section 8.1, 4th bullet should be
updated. We refer to the following text: 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 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 item should be taken out of the bullet list and should be This text should be replaced by:
replaced by:
Whenever originating a UDP packet, an IPv6 node SHOULD compute a Whenever originating a UDP packet in the default mode, an IPv6
UDP checksum over the packet and the pseudo-header, and, if that node MUST compute a UDP checksum over the packet and the pseudo-
computation yields a result of zero, it must be changed to hex header, and, if that computation yields a result of zero, it MUST
FFFF for placement in the UDP header. IPv6 receivers SHOULD be changed to hex FFFF for placement in the UDP header. IPv6
discard UDP packets containing a zero checksum, and SHOULD log the receivers MUST by default discard UDP packets containing a zero
error. However, some protocols, such as tunneling protocols that checksum, and SHOULD log the error. As an alternative usage for
use UDP as a tunnel encapsulation, MAY omit computing the UDP some protocols, such as protocols that use UDP as a tunnel
checksum of the encapsulating UDP header and set it to zero, encapsulation, MAY enable the zero-checksum mode for specific sets
subject to the constraints described in Applicability Statement of ports. Any node implementing the zero-checksum mode MUST
for the use of IPv6 UDP Datagrams with Zero Checksums follow the node requirements specified in Section 4 of
[I-D.ietf-6man-udpzero]. In cases where the encapsulating Applicability Statement for the use of IPv6 UDP Datagrams with
protocol uses a zero checksum for UDP, the receiver of packets Zero Checksums [I-D.ietf-6man-udpzero].
sent to a port enabled to receive zero-checksum packets MUST NOT
discard packets solely for having a UDP checksum of zero. Note
that these constraints apply only to encapsulating protocols that
omit calculating the UDP checksum and set it to zero. An
encapsulating protocol can always choose to compute the UDP
checksum, in which case, its behavior is not updated and uses the
method specified in Section 8.1 of RFC2460.
Middleboxes MUST allow IPv6 packets with UDP checksum equal to Any protocol using the zero-checksum mode MUST follow the usage
zero to pass. Implementations of middleboxes MAY allow requirements specified in Section 5 of Applicability Statement for
configuration of specific port ranges for which a zero UDP the use of IPv6 UDP Datagrams with Zero Checksums
checksum is valid and may drop IPv6 UDP packets outside those [I-D.ietf-6man-udpzero].
ranges.
The path between tunnel endpoints can change, thus also the Middleboxes supporting IPv6 MUST follow the requirements 9, 10 and
middleboxes in the path may vary during the life of the 11 of the usage requirements specified in Section 5 of
association. Paths with middleboxes that are intolerant of a UDP Applicability Statement for the use of IPv6 UDP Datagrams with
checksum of zero will drop any keep-alives sent to validate the Zero Checksums [I-D.ietf-6man-udpzero].
path using checksum zero and the endpoints will discover that.
Therefore keep-alive traffic SHOULD include both packets with
tunnel checksums and packets with checksums equal to zero to
enable the remote end to distinguish between path failures and the
blockage of packets with checksum equal to zero. Note that path
validation need only be done per tunnel endpoint pair, not per
tunnel context.
6. Additional Observations 6. Additional Observations
The existence of this issue among a significant number of protocols This update was motivated by the existence of a number of protocols
being developed in the IETF motivates this specified change. The being developed in the IETF that are expected to benefit from the
authors would also like to make the following observations: 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
corruptions (with or without checksums) has not (to our knowledge) corruptions (with or without checksums) has not (to our knowledge)
been conducted since about 2000. It is now 2012. We strongly been conducted since about 2000. At the time of publication, it
suggest that an empirical study is in order, along with an is now 2012. We strongly suggest a new empirical study, along
extensive analysis of IPv6 header corruption probabilities. with an extensive analysis of the corruption probabilities of the
IPv6 header.
o A key cause to the increased usage of UDP in tunneling is the lack o A key motivation for the increase in use of UDP in tunneling is a
of protocol support in middleboxes. Specifically, new protocols, lack of protocol support in middleboxes. Specifically, new
such as LISP [I-D.ietf-lisp], prefer to use UDP tunnels to protocols, such as LISP [I-D.ietf-lisp], may prefer to use UDP
traverse an end-to-end path successfully and avoid having their tunnels to traverse an end-to-end path successfully and avoid
packets dropped by middleboxes. If this were not the case, the having their packets dropped by middleboxes. If middleboxes were
use of UDP-lite [RFC3828] might become more viable for some (but updated to support UDP-Lite [RFC3828], this would provide better
not necessarily all) tunneling protocols. protection than offered by this update. This may be suited to a
variety of applications and would be expected to be preferred 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 mis-delivered packets. protection from mis-delivered 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
It requires less work to generate zero-checksum attack packets than Less work is required required to generate an attack using a zero UDP
ones with full UDP checksums. However, this does not lead to any checksum than one using a standard full UDP checksum. However, this
significant new vulnerabilities as checksums are not a security does not lead to significant new vulnerabilities because checksums
measure and can be easily generated by any attacker. Properly are not a security measure and can be easily generated by any
configured tunnels should check the validity of the inner packet and attacker. Properly configured tunnels should check the validity of
perform any needed security checks, regardless of the checksum the inner packet and perform security checks.
status. Most attacks are generated from compromised hosts which
automatically create checksummed packets (in other words, it would
generally be more, not less, effort for most attackers to generate
zero UDP checksums on the host).
9. Acknowledgements 9. Acknowledgements
We would like to thank Brian Haberman and Gorry Fairhurst for We would like to thank Brian Haberman, Dan Wing, Joel Halpern and the
discussions and reviews. IESG of 2012 for discussions and reviews. Gorry Fairhurst has been
very diligent 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-07 (work in progress), draft-ietf-6man-udpzero-07 (work in progress),
October 2012. October 2012.
[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.
skipping to change at page 9, line 39 skipping to change at page 11, line 18
for the use of IPv6 UDP Datagrams with Zero Checksums", for the use of IPv6 UDP Datagrams with Zero Checksums",
draft-ietf-6man-udpzero-07 (work in progress), draft-ietf-6man-udpzero-07 (work in progress),
October 2012. October 2012.
[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.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
"Softwire Security Analysis and Requirements", RFC 5619,
August 2009.
10.2. Informative References 10.2. Informative References
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-23 (work in progress), May 2012. 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
G. Fairhurst, "The Lightweight User Datagram Protocol
(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,
"Softwire Security Analysis and Requirements", RFC 5619,
August 2009.
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. 44 change blocks. 
214 lines changed or deleted 285 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/