draft-ietf-6man-udpchecksums-00.txt   draft-ietf-6man-udpchecksums-01.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 Intended status: Standards Track P. Chimento
Expires: September 8, 2011 Johns Hopkins University Applied Expires: May 3, 2012 Johns Hopkins University Applied
Physics Laboratory Physics Laboratory
March 7, 2011 October 31, 2011
UDP Checksums for Tunneled Packets UDP Checksums for Tunneled Packets
draft-ietf-6man-udpchecksums-00 draft-ietf-6man-udpchecksums-01
Abstract Abstract
We address the problem of computing the UDP checksum on tunneling This document provides an update of RFC 2460[RFC2460] in order to
IPv6 packets when using lightweight tunneling protocols. improve the performance of IPv6 in an increasingly important use
case, the use of tunneling to carry new transport protocols. The
performance improvement is obtained by relaxing the IPv6 UDP checksum
requirement for suitable tunneling protocol where header information
is protected on the "inner" packet being carried. This relaxation
removes the overhead associated with the computation of UDP checksums
on tunneled IPv6 packets and thereby improves the efficiency of the
traversal of firewalls and other network middleware by such new
protocols. We describe how the IPv6 UDP checksum requirement can be
relaxed in the situation where the encapsulated packet itself
contains a checksum, the limitations and risks of this approach, and
provides restrictions on the use of this relaxation to mitigate these
risks.
Requirements Language 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].
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
skipping to change at page 1, line 38 skipping to change at page 2, line 4
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 May 3, 2012.
This Internet-Draft will expire on September 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Some Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Recommended Solution . . . . . . . . . . . . . . . . . . . 6 5. The Zero-Checksum Solution . . . . . . . . . . . . . . . . . . 7
1.5. Additional Observations . . . . . . . . . . . . . . . . . 8 6. Additional Observations . . . . . . . . . . . . . . . . . . . 10
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
5.2. Informative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
With the rapid growth of the Internet, tunnel protocols have become This work constitutes the first upgrade of RFC 2460[RFC2460], in
increasingly important in the deployment of new transport layer order to improve the performance of IPv6 with transport layer
protocols. Tunneled protocols can be deployed rapidly, while the protocols carried encapsulated in tunnels. With the rapid growth of
time to upgrade and deploy a critical mass of routers, switches and the Internet, tunneling protocols have become increasingly important
end hosts on the global Internet for a new transport protocol is now to enable the deployment of new transport layer protocols. Tunneled
measured in decades. At the same time, the increasing use of protocols can be deployed rapidly, while the time to upgrade and
firewalls and other security related middleware means that truly new deploy a critical mass of routers, switches and end hosts on the
tunnel protocols are also unlikely to be deployable in a reasonable global Internet for a new transport protocol is now measured in
time frame, which has lead to an increasing interest in and use of decades. At the same time, the increasing use of firewalls and other
UDP-based tunneling protocols. In such protocols, there is an security related middleware means that truly new tunnel protocols,
encapsulated "inner" packet, and the "outer" packet carrying the with new protocol numbers, are also unlikely to be deployable in a
tunneled inner packet is a UDP packet, which can pass through reasonable time frame, which has resulted in an increasing interest
firewalls and other middleware filtering that is a fact of life on in and use of UDP-based tunneling protocols. In such protocols,
the current Internet. there is an encapsulated "inner" packet, and the "outer" packet
carrying the tunneled inner packet is a UDP packet, which can pass
through firewalls and other middleware filtering that is a fact of
life on the current Internet.
As tunnel endpoints may be routers or middleware aggregating traffic As tunnel endpoints may be routers or middleware aggregating traffic
from large numbers of tunnel users, the computation of an additional from large numbers of tunnel users, the computation of an additional
checksum on the outer UDP packet, when protected, is seen to be an checksum on the outer UDP packet, when protected, is seen to be an
unwarranted burden on the nodes implementing lightweight tunneling unwarranted burden on the nodes implementing lightweight tunneling
protocols, especially if the inner packet(s) are already protected by protocols, especially if the inner packet(s) are already protected by
a checksum. In IPv4, there is a checksum on the IP packet itself, 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 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 in IPv6 there is not a checksum on the IP packet and RFC 2460
[RFC2460] explicitly states that IPv6 receivers MUST discard UDP [RFC2460] explicitly states that IPv6 receivers MUST discard UDP
skipping to change at page 3, line 46 skipping to change at page 4, line 49
tunneling where the inner packet exists and has a checksum), based on tunneling where the inner packet exists and has a checksum), based on
the considerations set forth in [I-D.ietf-6man-udpzero]. the considerations set forth in [I-D.ietf-6man-udpzero].
While the origin of this I-D is the problem raised by the draft While the origin of this I-D is the problem raised by the draft
titled "Automatic IP Multicast Without Explicit Tunnels", also known titled "Automatic IP Multicast Without Explicit Tunnels", also known
as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have wide as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have wide
applicability, immediately to LISP [I-D.ietf-lisp], and also to other applicability, immediately to LISP [I-D.ietf-lisp], and also to other
tunneling protocols to come out of Softwires and other IETF Working tunneling protocols to come out of Softwires and other IETF Working
Groups. Groups.
Since the first version of this draft, the need for an efficient, Since the first version of this document, the need for an efficient,
lightweight UDP tunneling mechanism has increased. Indeed, other lightweight UDP tunneling mechanism has increased. Indeed, other
workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have
also expressed a need to have exceptions to the RFC 2460 prohibition. also expressed a need to have exceptions to the RFC 2460 prohibition.
More recently, a discussion on the DCCP mailing list covered the UDP
over IPv6 checksum issues. Other users of UDP as a tunneling
protocol, for example, L2TP and Softwires may benefit from a
relaxation of the RFC 2460 restriction.
1.1. Some Terminology Other users of UDP as a tunneling protocol, for example, L2TP and
Softwires may benefit from a relaxation of the RFC 2460 restriction.
For the remainder of this draft, we discuss only IPv6, since this The third version of this document benefited from a close read by
Magnus Westerlund and Gorry Fairhurst.
2. Some Terminology
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. So any reference to 'IP' should be
understood as a reference to IPv6. understood as a reference to IPv6.
Although we will try to avoid them when possible, we may use the Although we will try to avoid them when possible, we may use the
terms "tunneling" and "tunneled" as adjectives when describing terms "tunneling" and "tunneled" as adjectives when describing
packets. When we refer to 'tunneling packets' we refer to the outer packets. When we refer to 'tunneling packets' we refer to the outer
packet header that provides the tunneling function. When we refer to packet header that provides the tunneling function. When we refer to
'tunneled packets' we refer to the inner packet, i.e. the packet 'tunneled packets' we refer to the inner packet, i.e. the packet
being carried in the tunnel. being carried in the tunnel.
1.2. Problem Statement 3. Problem Statement
The argument is that since in the case of AMT multicast packets The argument is that since in the case of AMT multicast packets
already have a UDP header with a checksum, there is no additional already have a UDP header with a checksum, there is no additional
benefit and indeed some cost to nodes to both compute and check the benefit and indeed some cost to nodes to both compute and check the
UDP checksum of the outer (encapsulating) header. Consequently, IPv6 UDP checksum of the outer (encapsulating) header. Consequently, IPv6
should make an exception to the rule that the UDP checksum MUST not should make an exception to the rule that the UDP checksum MUST not
be 0, and allow tunneling protocols to set the checksum field of the be 0, and allow tunneling protocols to set the checksum field of the
outer header only to 0 and skip both the sender and receiver outer header only to 0 and skip both the sender and receiver
computation. computation.
1.3. Discussion 4. Discussion
The draft [I-D.ietf-6man-udpzero] does an excellent job of discussing [I-D.ietf-6man-udpzero] describes the issues related to allowing UDP
all the issues related to allowing UDP over IPv6 to have a valid over IPv6 to have a valid checksum of zero and is not repeated here.
checksum of zero. We will not repeat that work here.
In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine In Section 5.1 of [I-D.ietf-6man-udpzero], the authors propose nine
(9) constraints on the usage of a zero checksum for UDP over IPv6. (9) constraints on the usage of a zero checksum for UDP over IPv6.
We agree with the restrictions proposed, and in fact proposed some of We agree with the restrictions proposed, and in fact proposed some of
those restrictions ourselves in the previous version of the current those restrictions ourselves in the previous version of the current
draft. These restrictions are incorporated into the proposed changes draft. These restrictions are incorporated into the proposed changes
below. below.
As has been pointed out in [I-D.ietf-6man-udpzero] and in many As has been pointed out in [I-D.ietf-6man-udpzero] and in many
mailing lists, there is still the possibility of deep-inspection mailing lists, there is still the possibility of deep-inspection
skipping to change at page 5, line 27 skipping to change at page 6, line 32
o Only UDP packets containing tunneled packets should have a UDP o Only UDP packets containing tunneled packets should have a UDP
checksum equal to zero. checksum equal to zero.
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. endpoint pair, not per tunnel context. 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.
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 minumum) If lightweight tunneling protocol contexts contain (at a minimum)
source and destination IP addresses and source and destination source and destination IP addresses and source and destination
ports, there are 16 possible corruption outcomes. We note that ports, there are 16 possible corruption outcomes. We note that
these outcomes not equally likely, as most require multiple bit these outcomes not equally likely, as most require multiple bit
errors with errored bits in separate fields. The possible errors with errored bits in separate fields. The possible
corruption outcomes fall out this way: 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
lightweight tunneling protocol and if it has a matching context lightweight tunneling protocol and if it has a matching context
(which can be assumed to be a very low probability event) the (which can be assumed to be a very low probability event) the
inner packet will be decapsulated and forwarded. If it is some inner packet will be decapsulated and forwarded. If it is some
other application, with very high probability, the application other application, with very high probability, the application
will not recognize the contents of the packet. will not recognize the contents of the packet.
* 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 liklihood 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
tunneling endpoint context contains sufficient information, tunneling endpoint context contains sufficient information,
these error should be detected with high probability. these error should be detected with high probability.
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
skipping to change at page 6, line 32 skipping to change at page 7, line 40
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 this is not a perfect solution, it can reduce the risks of
relaxing the UDP checksum requirement for IPv6. relaxing the UDP checksum requirement for IPv6.
1.4. Recommended Solution 5. The Zero-Checksum Solution
There is a need that a UDP checksum of zero could be allowed on the The solution to the overhead associated with UDP packets carrying
outer encapsulating packet of a lightweight tunneling protocol. This encapsulated tunnel traffic is to allow a UDP checksum of zero on the
would imply that UDP endpoints handling that protocol must change outer encapsulating packet of a lightweight tunneling protocol. UDP
their behavior and not discard UDP packets received with a 0 checksum endpoints that implement this solution MUST change their behavior and
on the outer packet. We also recommend that the constraints in not discard UDP packets received with a 0 checksum on the outer
Section 5.1 of [I-D.ietf-6man-udpzero] be adopted. packet of tunneling protocols. If this is done constraints in
Section 5.1 of [I-D.ietf-6man-udpzero] also MUST be adopted.
Specifically, this draft proposes that the text in [RFC2460] Section Specifically, the text in [RFC2460] Section 8.1, 4th bullet is
8.1, 4th bullet be amended. We refer to the following text: amended. 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: modified as follows:
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 lightweight tunneling
protocols that use UDP as a tunnel encapsulation, MAY omit protocols that use UDP as a tunnel encapsulation, MAY omit
computing the UDP checksum of the encapsulating UDP header and set computing the UDP checksum of the encapsulating UDP header and set
it to zero, subject to the following constraints (from it to zero, subject to the constraints described in
[I-D.ietf-6man-udpzero]). In cases, where the encapsulating [I-D.ietf-6man-udpzero]. In cases where the encapsulating
protocol uses a zero checksum for UDP, the receiver of packets in protocol uses a zero checksum for UDP, the receiver of packets
the allowed port range MUST NOT discard packets with a UDP sent to a port enabled to receive zero-checksum packets MUST NOT
checksum of zero. Note that these constraints apply only to discard packets solely for having a UDP checksum of zero. Note
encapsulating protocols that omit calculating the UDP checksum and that these constraints apply only to encapsulating protocols that
set it to zero. An encapsulating protocol can always choose to omit calculating the UDP checksum and set it to zero. An
compute the UDP checksum, in which case, its behavior should be as encapsulating protocol can always choose to compute the UDP
specified above. checksum, in which case, its behavior should be as specified
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 behaviour allow the new method. The default node receiver behavior MUST
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
port or port-range. This may be implemented via a socket API port or port-range. This may be implemented via a socket API
call, or similar mechanism. call, or similar mechanism.
3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams 3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams
with a zero-checksum. This should remain the case for any with a zero-checksum. A port for which zero-checksum has been
datagram received on a port that does not explicitly enable enabled MUST NOT log zero-checksum datagrams for that reason
zero-checksum processing. A port for which zero-checksum has (of course, there might be other reasons to log such packets).
been enabled MUST NOT log the datagram.
4. A stack may separately identify UDP datagrams that are 4. A stack may separately identify UDP datagrams that are
discarded with a zero checksum. It SHOULD NOT add these to discarded with a zero checksum. It SHOULD NOT add these to
the standard log, since the endpoint has not been verified. the standard log, since the endpoint has not been verified.
5. UDP Tunnels that encapsulate IP MUST rely on the inner packet 5. UDP Tunnels that encapsulate IP may rely on the inner packet
integrity checks provided that the tunnel will not integrity checks provided that the tunnel will not
significantly increase the rate of corruption of the inner IP significantly increase the rate of corruption of the inner IP
packet. If a significantly increased corruption rate can packet. If a significantly increased corruption rate can
occur, then the tunnel MUST provide an additional integrity occur, then the tunnel MUST provide an additional integrity
verification mechanism. An integrity mechanism is always verification mechanism. An integrity mechanism is always
recommended at the tunnel layer to ensure that corruption recommended at the tunnel layer to ensure that corruption
rates of the inner most packet are not increased. rates of the inner most packet are not increased.
6. Tunnels that encapsulate Non-IP packets MUST have a CRC or 6. Tunnels that encapsulate Non-IP packets MUST have a CRC or
other mechanism for checking packet integrity, unless the other mechanism for checking packet integrity, unless the
skipping to change at page 8, line 45 skipping to change at page 10, line 11
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.
1.5. Additional Observations 6. Additional Observations
The persistence of this issue among a significant number of protocols The persistence of this issue among a significant number of protocols
being developed in the IETF requires a definitive policy. The being developed in the IETF requires a definitive policy. The
authors would like to make the following observations: authors would 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 2011. 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 of this issue generally is the lack of protocol
support in middleboxes. Specifically, new protocols, such as support in middleboxes. Specifically, new protocols, such as
DCCP, are being forced to use UDP tunnels just to traverse an end- LISP, are being forced to use UDP tunnels just to traverse an end-
to-end path successfully and avoid having their packets dropped by to-end path successfully and avoid having their packets dropped by
middleboxes. If this were not the case, the use of UDP-lite might middleboxes. If this were not the case, the use of UDP-lite might
become more viable for some (but not necessarily all) lightweight become more viable for some (but not necessarily all) lightweight
tunneling protocols. tunneling protocols.
o Another cause of this issue is that the UDP checksum is overloaded o Another cause of this issue is that the UDP checksum is overloaded
with the task of protecting the IPv6 header for UDP flows (as it with the task of protecting the IPv6 header for UDP flows (as it
the TCP checksum for TCP flows). Protocols that do not use a the TCP checksum for TCP flows). Protocols that do not use a
pseudo-header approach to computing a checksum or CRC have pseudo-header approach to computing a checksum or CRC have
essentially no protection from misdelivered packets. We suggest essentially no protection from misdelivered packets.
that decoupling IPv6 header protection from transport generally
should be studied in this workgroup. One approach might be to
consider an extension header for IPv6 containing (at least) a
header checksum. However, that is beyond the scope of this draft.
2. 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.
3. Security Considerations 8. Security Considerations
It is of course less work to generate zero-checksum attack packets It is of course less work to generate zero-checksum attack packets
than ones with full UDP checksums. However, this does not lead to than ones with full UDP checksums. However, this does not lead to
any significant new vulnerabilities as checksums are not a security any 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).
4. Acknowledgements 9. Acknowledgements
We would like to thank Brian Haberman, Magnus Westerlund and Gorry We would like to thank Brian Haberman, Magnus Westerlund and Gorry
Fairhurst for discussions and reviews. Fairhurst for discussions and reviews.
5. References 10. References
5.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.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[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 [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.
[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.
5.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-02 (work in Considerations", draft-ietf-6man-udpzero-04 (work in
progress), October 2010. progress), October 2011.
[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-09 (work in progress), October 2010. draft-ietf-lisp-15 (work in progress), July 2011.
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-auto-multicast]
Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
Pusateri, "Automatic IP Multicast Without Explicit Tunnels Pusateri, "Automatic IP Multicast Without Explicit Tunnels
(AMT)", draft-ietf-mboned-auto-multicast-10 (work in (AMT)", draft-ietf-mboned-auto-multicast-11 (work in
progress), March 2010. progress), July 2011.
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:
Email: tme@americafree.tv Email: marshall.eubanks@gmail.com
URI: http://www.americafree.tv
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
 End of changes. 37 change blocks. 
94 lines changed or deleted 109 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/