draft-ietf-6man-udpchecksums-02.txt   draft-ietf-6man-udpchecksums-03.txt 
Network Working Group M. Eubanks Network Working Group M. Eubanks
Internet-Draft AmericaFree.TV LLC Internet-Draft AmericaFree.TV LLC
Intended status: Standards Track P. Chimento Updates: 2460 (if approved) P. Chimento
Expires: September 13, 2012 Johns Hopkins University Applied Intended status: Standards Track Johns Hopkins University Applied
Physics Laboratory Expires: February 8, 2013 Physics Laboratory
March 12, 2012 M. Westerlund
Ericsson
August 7, 2012
UDP Checksums for Tunneled Packets UDP Checksums for Tunneled Packets
draft-ietf-6man-udpchecksums-02 draft-ietf-6man-udpchecksums-03
Abstract Abstract
This document provides an update of RFC 2460[RFC2460] in order to This document provides an update of the Internet Protocol version 6
improve the performance of IPv6 in an increasingly important use (IPv6) specification (RFC2460) to improve the performance of IPv6 in
case, the use of tunneling to carry new transport protocols. The the use case when a tunnel protocol uses UDP with IPv6 to tunnel
performance improvement is obtained by relaxing the IPv6 UDP checksum packets. The performance improvement is obtained by relaxing the
requirement for suitable tunneling protocol where header information IPv6 UDP checksum requirement for suitable tunneling protocol where
is protected on the "inner" packet being carried. This relaxation header information is protected on the "inner" packet being carried.
removes the overhead associated with the computation of UDP checksums This relaxation removes the overhead associated with the computation
on tunneled IPv6 packets and thereby improves the efficiency of the of UDP checksums on IPv6 packets used to carry tunnel protocols and
traversal of firewalls and other network middleware by such new thereby improves the efficiency of the traversal of firewalls and
protocols. We describe how the IPv6 UDP checksum requirement can be other network middleboxes by such protocols. We describe how the
relaxed in 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, and the encapsulated packet itself contains a checksum, the limitations
provides restrictions on the use of this relaxation to mitigate these and risks of this approach, and defines restrictions on the use of
risks. this relaxation to mitigate these risks.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 September 13, 2012.
Copyright Notice This Internet-Draft will expire on February 8, 2013.
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
5. The Zero-Checksum Solution . . . . . . . . . . . . . . . . . . 7 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Additional Observations . . . . . . . . . . . . . . . . . . . 10 5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 6
6. Additional Observations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This work constitutes the first upgrade of RFC 2460[RFC2460], in This work constitutes the first update of the Internet Protocol
order to improve the performance of IPv6 with transport layer Version 6 (IPv6) Specification [RFC2460], in the use case when a
protocols carried encapsulated in tunnels. With the rapid growth of tunnel protocol uses UDP with IPv6 to tunnel packets. With the rapid
the Internet, tunneling protocols have become increasingly important growth of the Internet, tunneling protocols have become increasingly
to enable the deployment of new transport layer protocols. Tunneled important to enable the deployment of new tunnel 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, switches and end hosts on the
global Internet for a new transport protocol is now measured in global Internet for a new tunnel protocol is now measured in decades.
decades. At the same time, the increasing use of firewalls and other At the same time, the increasing use of firewalls and other security
security related middleware means that truly new tunnel protocols, related middleboxes means that truly new tunnel protocols, with new
with new protocol numbers, are also unlikely to be deployable in a protocol numbers, are also unlikely to be deployable in a reasonable
reasonable time frame, which has resulted in an increasing interest time frame, which has resulted in an increasing interest in and use
in and use of UDP-based tunneling protocols. In such protocols, of UDP-based tunneling protocols. In such protocols, there is an
there is an encapsulated "inner" packet, and the "outer" packet encapsulated "inner" packet, and the "outer" packet carrying the
carrying the tunneled inner packet is a UDP packet, which can pass tunneled inner packet is a UDP packet, which can pass through
through firewalls and other middleware filtering that is a fact of firewalls and other middleboxes filtering that is a fact of life on
life on the current Internet. the current Internet.
As tunnel endpoints may be routers or middleware aggregating traffic
from large numbers of tunnel users, the computation of an additional
checksum on the outer UDP packet, when protected, is seen to be an
unwarranted burden on the nodes implementing lightweight tunneling
protocols, especially if the inner packet(s) are already protected by
a checksum. In IPv4, there is a checksum on the IP packet itself,
and the checksum on the outer UDP packet can be set to zero. However
in IPv6 there is not a checksum on the IP packet and RFC 2460
[RFC2460] explicitly states that IPv6 receivers MUST discard UDP
packets with a 0 checksum. So, while sending a UDP packet with a 0
checksum is permitted in IPv4 packets, it is explicitly forbidden in
IPv6 packets. In order to meet the needs of the deployers of IPv6
UDP tunnels, this document modifies RFC 2460 to allow for the
ignoring of UDP checksums under constrained situations (IPv6
tunneling where the inner packet exists and has a checksum), based on
the considerations set forth in [I-D.ietf-6man-udpzero].
While the origin of this I-D is the problem raised by the draft Tunnel endpoints may be routers or middleboxes aggregating traffic
titled "Automatic IP Multicast Without Explicit Tunnels", also known from a large number of tunnel users, therefore the computation of an
as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have wide additional checksum on the outer UDP packet, may be seen as an
applicability, immediately to AMT and LISP [I-D.ietf-lisp], and in unwarranted burden on nodes that implement a tunneling protocol,
the future to other tunneling protocols to come out of Softwires and especially if the inner packet(s) are already protected by a
other IETF Working Groups. checksum. In IPv4, there is a checksum on the IP packet itself, and
the checksum on the outer UDP packet can be set to zero. However in
IPv6 there is not a checksum on the IP packet and RFC 2460 [RFC2460]
explicitly states that IPv6 receivers MUST discard UDP packets with a
0 checksum. So, while sending a UDP packet with a 0 checksum is
permitted in IPv4 packets, it is explicitly forbidden in IPv6
packets. To improve support for IPv6 UDP tunnels, this document
updates RFC 2460 to allow tunnel endpoints to use a zero UDP checksum
under constrained situations (IPv6 tunnel transports that carry
checksum-protected packets), following the considerations in
[I-D.ietf-6man-udpzero].
Since the first version of this document, the need for an efficient, Unicast UDP Usage Guidelines for Application Designers [RFC5405]
lightweight UDP tunneling mechanism has increased. Indeed, other should be consulted when reading this specification. It discusses
workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have both UDP tunnels (Section 3.1.3) and the usage of Checksums (Section
also expressed a need to have exceptions to the RFC 2460 prohibition. 3.4).
Other users of UDP as a tunneling protocol, for example, L2TP and While the origin of this specification is the problem raised by the
Softwires may benefit from a relaxation of the RFC 2460 restriction. draft titled "Automatic IP Multicast Without Explicit Tunnels", also
known as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have
wide applicability. Since the first version of this document, the
need for an efficient UDP tunneling mechanism has increased. Other
IETF Working Groups, notably LISP [I-D.ietf-lisp] and Softwires
The third version of this document benefited from a close read by [RFC5619] have expressed a need to update the UDP checksum processing
Magnus Westerlund and Gorry Fairhurst. in RFC 2460. We therefore expect this update to be applicable in
future to other tunneling protocols specified by these and other IETF
Working Groups.
2. Some Terminology 2. Some Terminology
For the remainder of this document, we discuss only IPv6, since this For the remainder of this document, we discuss only IPv6, since this
problem does not exist for IPv4. So any reference to 'IP' should be problem does not exist for IPv4. Therefore all reference to 'IP'
understood as a reference to IPv6. should be understood as a reference to IPv6.
Although we will try to avoid them when possible, we may use the The document uses the terms "tunneling" and "tunneled" as adjectives
terms "tunneling" and "tunneled" as adjectives when describing when describing packets. When we refer to 'tunneling packets' we
packets. When we refer to 'tunneling packets' we refer to the outer refer to the outer packet header that provides the tunneling
packet header that provides the tunneling function. When we refer to function. When we refer to 'tunneled packets' we refer to the inner
'tunneled packets' we refer to the inner packet, i.e. the packet packet, i.e. the packet being carried in the tunnel.
being carried in the tunnel.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Problem Statement 3. Problem Statement
The argument is that since in the case of AMT multicast packets This document provides an update for the case where a tunnel protocol
already have a UDP header with a checksum, there is no additional transports tunnelled packets that already have a UDP header with a
benefit and indeed some cost to nodes to both compute and check the checksum, there is both a benefit and a cost to compute and check the
UDP checksum of the outer (encapsulating) header. Consequently, IPv6 UDP checksum of the outer (encapsulating) UDP transport header. In
should make an exception to the rule that the UDP checksum MUST not certain cases, where reducing the forwarding cost is important, such
be 0, and allow tunneling protocols to set the checksum field of the as for systems that perform the check in software, the cost may
outer header only to 0 and skip both the sender and receiver outweigh the benefit; this document describes a means to avoid that
computation. cost, in the case where there is an inner header with a checksum.
4. Discussion 4. Discussion
[I-D.ietf-6man-udpzero] describes the issues related to allowing UDP IPv6 UDP Checksum Considerations [I-D.ietf-6man-udpzero] describes
over IPv6 to have a valid checksum of zero and is not repeated here. the issues related to allowing UDP over IPv6 to have a valid checksum
of zero and is not repeated here.
In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements
(9) constraints on the usage of a zero checksum for UDP over IPv6. that introduce constraints on the usage of a zero checksum for UDP
We agree with the restrictions proposed, and in fact proposed some of over IPv6. This document is intended to satisfy these requirements.
those restrictions ourselves in the previous version of the current
draft. These restrictions are incorporated into the proposed changes
below.
As has been pointed out in [I-D.ietf-6man-udpzero] and in various [I-D.ietf-6man-udpzero] and mailing list discussions have noted there
mailing list discussions, there is still the possibility of deep- is still the possibility of deep-inspection firewall devices or other
inspection firewall devices or other middleboxes actually checking middleboxes checking the UDP checksum field of the outer packet and
the UDP checksum field of the outer packet and thereby discarding the thereby discarding the tunneling packets. This would be an issue
tunneling packets. This is would be an issue also for legacy systems also for any legacy IPv6 system that has not implemented this update
which have not implemented the change in the IPv6 specification. So to the IPv6 specification. In this case, the system (according to
in any case, there may be packet loss of lightweight tunneling RFC 2460) will discard the zero-checksum UDP packets, and should log
packets because of mixed new-rule and old-rule nodes. this as an error.
As an example, we discuss how can errors be detected and handled in a The below discuss how path errors can be detected and handled in an
lightweight UDP tunneling protocol when the checksum protection is UDP tunneling protocol when the checksum protection is disabled.
disabled. Note that other (non-tunneling) protocols may have Note that other (non-tunneling) protocols may have different
different approaches. We suggest that the following could be an approaches, but these are not the topic of this update. We propose
approach to this problem: the following approach to handle this problem:
o Context (i.e. tunneling state) should be established via o Context (i.e. tunneling state) should be established via
application PDUs that are carried in checksummed UDP packets. application PDUs that are carried in checksummed UDP packets.
That is, any control packets flowing between the tunnel endpoints That is, any control packets flowing between the tunnel endpoints
should be protected by UDP checksums. The control packets can should be protected by UDP checksums. The control packets can
also contain any negotiation that is necessary to set up the also contain any negotiation required to enable the endpoint/
endpoint/adapters to accept UDP packets with a zero checksum. adapters to accept UDP packets with a zero checksum. The control
packets may also carry any negotiation required to enable the
endpoint/adapters to identify the set of ports that need to enable
reception UDP datagrams with a zero checksum.
o Only UDP packets containing tunneled packets should have a UDP o A system shall not set the UDP checksum to zero in packets that do
checksum equal to zero. not contain tunneled packets.
o UDP keep-alive packets with checksum zero can be sent to validate o UDP keep-alive packets with checksum zero can be sent to validate
paths, given that paths between tunnel endpoints can change and so paths, given that paths between tunnel endpoints can change and so
middleboxes in the path may vary during the life of the middleboxes in the path may vary during the life of the
association. Paths with middleboxes that are intolerant of a UDP association. Paths with middleboxes that are intolerant of a UDP
checksum of zero will drop the keep-alives and the endpoints will checksum of zero will drop the keep-alives and the endpoints will
discover that. Note that this need only be done per tunnel discover that. Note that this need only be done per tunnel
endpoint pair, not per tunnel context. Keep-alive traffic SHOULD endpoint pair, not per tunnel context. Keep-alive traffic should
include both packets with tunnel checksums and packets with include both packets with tunnel checksums and packets with
checksums equal to zero to enable the remote end to distinguish checksums equal to zero to enable the remote end to distinguish
between path failures and the blockage of packets with checksum between path failures and the blockage of packets with checksum
equal to zero. equal to zero.
o Corruption of the encapsulating IPv6 source address, destination o Corruption of the encapsulating IPv6 source address, destination
address and/or the UDP source port, destination port fields : If address and/or the UDP source port, destination port fields : If
the 9 restrictions in [I-D.ietf-6man-udpzero] are followed, the the 9 restrictions in [I-D.ietf-6man-udpzero] are followed, the
inner packets (tunneled packets) should be protected and run the inner packets (tunneled packets) should be protected and run the
usual (presumably small) risk of having undetected corruption(s). usual (presumably small) risk of having undetected corruption(s).
If lightweight tunneling protocol contexts contain (at a minimum) If tunneling protocol contexts contain (at a minimum) source and
source and destination IP addresses and source and destination destination IP addresses and source and destination ports, there
ports, there are 16 possible corruption outcomes. We note that are 16 possible corruption outcomes. We note that these outcomes
these outcomes not equally likely, as most require multiple bit are not equally likely. The possible corruption outcomes may be:
errors with errored bits in separate fields. The possible
corruption outcomes fall out this way:
* Half of the 16 possible corruption combinations have a * Half of the 16 possible corruption combinations have a
corrupted destination address. If the incorrect destination is corrupted destination address. If the incorrect destination is
reached and the node doesn't have an application for the reached and the node doesn't have an application for the
destination port, the packet will be dropped. If the destination port, the packet will be dropped. If the
application at the incorrect destination is the same application at the incorrect destination is the same tunneling
lightweight tunneling protocol and if it has a matching context protocol and if it has a matching context (which can be assumed
(which can be assumed to be a very low probability event) the to be a very low probability event) the inner packet will be
inner packet will be decapsulated and forwarded. If it is some decapsulated and forwarded. Application developers should
other application, with very high probability, the application verify the context of the packets they receive using UDP, as
will not recognize the contents of the packet. 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 * Half of the 8 possible corruption combinations with a correct
destination address have a corrupted source address. If the destination address have a corrupted source address. If the
tunnel contexts contain all elements of the address-port tunnel contexts contain all elements of the address-port
4-tuple, then the likelihood is that this corruption will be 4-tuple, then the likelihood is that this corruption will be
detected. detected.
* Of the remaining 4 possibilities, with valid source and * Of the remaining 4 possibilities, with valid source and
destination IPv6 addresses, 1 has all 4 fields valid, the other destination IPv6 addresses, 1 has all 4 fields valid, the other
three have one or both ports corrupted. Again, if the three have one or both ports corrupted. Again, if the
skipping to change at page 7, line 37 skipping to change at page 6, line 44
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 this is not a perfect solution, it can reduce the risks of While they do not guarantee correctness, these mechanism can reduce
relaxing the UDP checksum requirement for IPv6. the risks of relaxing the UDP checksum requirement for IPv6.
5. The Zero-Checksum Solution 5. The Zero-Checksum Update
The solution to the overhead associated with UDP packets carrying This specification updates IPv6 to allow a UDP checksum of zero for
encapsulated tunnel traffic is to allow a UDP checksum of zero on the the outer encapsulating packet of a tunneling protocol. UDP
outer encapsulating packet of a lightweight tunneling protocol. UDP endpoints that implement this update MUST change their behavior for
endpoints that implement this solution MUST change their behavior and any destination port explicitly configured for zero checksum and not
not discard UDP packets received with a 0 checksum on the outer discard UDP packets received with a checksum value of zero on the
packet of tunneling protocols. If this is done constraints in outer packet. When this is done, it requires the constraints in
Section 5.1 of [I-D.ietf-6man-udpzero] also MUST be adopted. Section 5.1 of [I-D.ietf-6man-udpzero].
Specifically, the text in [RFC2460] Section 8.1, 4th bullet is Specifically, the text in [RFC2460] Section 8.1, 4th bullet is
amended. We refer to the following text: updated. We refer to the following text:
"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 item should be taken out of the bullet list and should be
modified as follows: replaced by:
Whenever originating a UDP packet, an IPv6 node SHOULD compute a Whenever originating a UDP packet, an IPv6 node SHOULD compute a
UDP checksum over the packet and the pseudo-header, and, if that UDP checksum over the packet and the pseudo-header, and, if that
computation yields a result of zero, it must be changed to hex computation yields a result of zero, it must be changed to hex
FFFF for placement in the UDP header. IPv6 receivers SHOULD FFFF for placement in the UDP header. IPv6 receivers SHOULD
discard UDP packets containing a zero checksum, and SHOULD log the discard UDP packets containing a zero checksum, and SHOULD log the
error. However, some protocols, such as lightweight tunneling error. However, some protocols, such as tunneling protocols that
protocols that use UDP as a tunnel encapsulation, MAY omit use UDP as a tunnel encapsulation, MAY omit computing the UDP
computing the UDP checksum of the encapsulating UDP header and set checksum of the encapsulating UDP header and set it to zero,
it to zero, subject to the constraints described in subject to the constraints described in RFCXXXX. In cases where
[I-D.ietf-6man-udpzero]. In cases where the encapsulating the encapsulating protocol uses a zero checksum for UDP, the
protocol uses a zero checksum for UDP, the receiver of packets receiver of packets sent to a port enabled to receive zero-
sent to a port enabled to receive zero-checksum packets MUST NOT checksum packets MUST NOT discard packets solely for having a UDP
discard packets solely for having a UDP checksum of zero. Note checksum of zero. Note that these constraints apply only to
that these constraints apply only to encapsulating protocols that encapsulating protocols that omit calculating the UDP checksum and
omit calculating the UDP checksum and set it to zero. An set it to zero. An encapsulating protocol can always choose to
encapsulating protocol can always choose to compute the UDP compute the UDP checksum, in which case, its behavior is not
checksum, in which case, its behavior should be as specified updated and uses the method specified in RFC2460.
originally.
1. IPv6 protocol stack implementations SHOULD NOT by default 1. IPv6 protocol stack implementations SHOULD NOT by default
allow the new method. The default node receiver behavior MUST allow the new method. The default node receiver behavior MUST
discard all IPv6 packets carrying UDP packets with a zero discard all IPv6 packets carrying UDP packets with a zero
checksum. checksum.
2. Implementations MUST provide a way to signal the set of ports 2. Implementations MUST provide a way to signal the set of ports
that will be enabled to receive UDP datagrams with a zero that will be enabled to receive UDP datagrams with a zero
checksum. An IPv6 node that enables reception of UDP packets checksum. An IPv6 node that enables reception of UDP packets
with a zero-checksum, MUST enable this only for a specific with a zero-checksum, MUST enable this only for a specific
skipping to change at page 10, line 11 skipping to change at page 9, line 13
that the reported packet actually originated from the node, that the reported packet actually originated from the node,
before acting upon the information (e.g. validating the before acting upon the information (e.g. validating the
address and port numbers in the ICMPv6 message body). address and port numbers in the ICMPv6 message body).
Middleboxes MUST allow IPv6 packets with UDP checksum equal to Middleboxes MUST allow IPv6 packets with UDP checksum equal to
zero to pass. Implementations of middleboxes MAY allow zero to pass. Implementations of middleboxes MAY allow
configuration of specific port ranges for which a zero UDP configuration of specific port ranges for which a zero UDP
checksum is valid and may drop IPv6 UDP packets outside those checksum is valid and may drop IPv6 UDP packets outside those
ranges. ranges.
The path between tunnel endpoints can change, thus also the
middleboxes in the path may vary during the life of the
association. Paths with middleboxes that are intolerant of a UDP
checksum of zero will drop any keep-alives sent to validate the
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.
RFC-Editor Note: Please replace RFCXXXX above with the RFC number
this specification receives and remove this note.
6. Additional Observations 6. Additional Observations
The persistence of this issue among a significant number of protocols The existence of this issue among a significant number of protocols
being developed in the IETF requires a definitive policy. The being developed in the IETF motivates this specified change. The
authors would like to make the following observations: authors would also like to make the following observations:
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 2011. We strongly been conducted since about 2000. It is now 2012. We strongly
suggest that an empirical study is in order, along with an suggest that an empirical study is in order, along with an
extensive analysis of IPv6 header corruption probabilities. extensive analysis of IPv6 header corruption probabilities.
o A key cause of this issue generally is the lack of protocol o A key cause to the increased usage of UDP in tunneling is the lack
support in middleboxes. Specifically, new protocols, such as LISP of protocol support in middleboxes. Specifically, new protocols,
[I-D.ietf-lisp], are being forced to use UDP tunnels just to such as LISP [I-D.ietf-lisp], prefer to use UDP tunnels to
traverse an end-to-end path successfully and avoid having their traverse an end-to-end path successfully and avoid having their
packets dropped by middleboxes. If this were not the case, the packets dropped by middleboxes. If this were not the case, the
use of UDP-lite [RFC3828] might become more viable for some (but use of UDP-lite [RFC3828] might become more viable for some (but
not necessarily all) lightweight tunneling protocols. not necessarily all) tunneling protocols.
o Another cause of this issue is that the UDP checksum is overloaded o Another issue is that the UDP checksum is overloaded with the task
with the task of protecting the IPv6 header for UDP flows (as it of protecting the IPv6 header for UDP flows (as is the TCP
the TCP checksum for TCP flows). Protocols that do not use a checksum for TCP flows). Protocols that do not use a pseudo-
pseudo-header approach to computing a checksum or CRC have header approach to computing a checksum or CRC have essentially no
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 is of course less work to generate zero-checksum attack packets It requires less work to generate zero-checksum attack packets than
than ones with full UDP checksums. However, this does not lead to ones with full UDP checksums. However, this does not lead to any
any significant new vulnerabilities as checksums are not a security significant new vulnerabilities as checksums are not a security
measure and can be easily generated by any attacker, as properly measure and can be easily generated by any attacker, as properly
configured tunnels should check the validity of the inner packet and configured tunnels should check the validity of the inner packet and
perform any needed security checks, regardless of the checksum perform any needed security checks, regardless of the checksum
status, and finally as most attacks are generated from compromised status, and finally as most attacks are generated from compromised
hosts which automatically create checksummed packets (in other words, hosts which automatically create checksummed packets (in other words,
it would generally be more, not less, effort for most attackers to it would generally be more, not less, effort for most attackers to
generate zero UDP checksums on the host). generate zero UDP checksums on the host).
9. Acknowledgements 9. Acknowledgements
We would like to thank Brian Haberman, Magnus Westerlund and Gorry We would like to thank Brian Haberman and Gorry Fairhurst for
Fairhurst for discussions and reviews. discussions and reviews.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
skipping to change at page 11, line 38 skipping to change at page 11, line 10
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
"Softwire Security Analysis and Requirements", RFC 5619, "Softwire Security Analysis and Requirements", RFC 5619,
August 2009. August 2009.
10.2. Informative References 10.2. Informative References
[I-D.ietf-6man-udpzero] [I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
Considerations", draft-ietf-6man-udpzero-05 (work in Considerations", draft-ietf-6man-udpzero-06 (work in
progress), December 2011. progress), June 2012.
[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-22 (work in progress), February 2012. draft-ietf-lisp-23 (work in progress), May 2012.
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-auto-multicast]
Bumgardner, G. and T. Morin, "Automatic Multicast Bumgardner, G., "Automatic Multicast Tunneling",
Tunneling", draft-ietf-mboned-auto-multicast-12 (work in draft-ietf-mboned-auto-multicast-14 (work in progress),
progress), February 2012. June 2012.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
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
skipping to change at line 477 skipping to change at page 12, line 4
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, MD 20723
USA USA
Phone: +1-443-778-1743 Phone: +1-443-778-1743
Fax: Fax:
Email: Philip.Chimento@jhuapl.edu Email: Philip.Chimento@jhuapl.edu
URI: URI:
Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
 End of changes. 44 change blocks. 
187 lines changed or deleted 209 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/