One document matched: draft-ietf-6man-udpchecksums-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-6man-udpchecksums-04"
ipr="trust200902" updates="2460">
<front>
<title abbrev="udp-checksum">UDP Checksums for Tunneled Packets</title>
<author fullname="Marshall Eubanks" initials="M." surname="Eubanks">
<organization>AmericaFree.TV LLC</organization>
<address>
<postal>
<street>P.O. Box 141</street>
<city>Clifton</city>
<region>Virginia</region>
<code>20124</code>
<country>USA</country>
</postal>
<phone>+1-703-501-4376</phone>
<facsimile/>
<email>marshall.eubanks@gmail.com</email>
</address>
</author>
<author fullname="P.F. Chimento" initials="P.F." surname="Chimento">
<organization>Johns Hopkins University Applied Physics
Laboratory</organization>
<address>
<postal>
<street>11100 Johns Hopkins Road</street>
<city>Laurel</city>
<region>MD</region>
<code>20723</code>
<country>USA</country>
</postal>
<phone>+1-443-778-1743</phone>
<facsimile/>
<email>Philip.Chimento@jhuapl.edu</email>
<uri/>
</address>
</author>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<date day="5" month="September" year="2012"/>
<abstract>
<t>This document provides an update of the Internet Protocol version 6
(IPv6) specification (RFC2460) to improve the performance of IPv6 in the
use case when a tunnel protocol uses UDP with IPv6 to tunnel packets.
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 IPv6 packets used to carry tunnel protocols and thereby
improves the efficiency of the traversal of firewalls and other network
middleboxes by such 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 defines restrictions on the use of this relaxation to
mitigate these risks.</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>This work constitutes an update of the <xref
target="RFC2460">Internet Protocol Version 6 (IPv6)
Specification</xref>, in the use case when a tunnel protocol uses UDP
with IPv6 to tunnel packets. With the rapid growth of the Internet,
tunneling protocols have become increasingly important to enable the
deployment of new protocols. Tunneled protocols can be deployed rapidly,
while the time to upgrade and deploy a critical mass of routers,
switches and end hosts on the global Internet for a new protocol is now
measured in decades. At the same time, the increasing use of firewalls
and other security related middleboxes means that truly new tunnel
protocols, with new protocol numbers, are also unlikely to be deployable
in a reasonable time frame, which has resulted in an increasing interest
in and use of UDP-based tunneling protocols. In such protocols, 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 middleboxes filtering that is a fact of life on the current
Internet.</t>
<t>Tunnel endpoints may be routers or middleboxes aggregating traffic
from a large number of tunnel users, therefore the computation of an
additional checksum on the outer UDP packet, may be seen as an
unwarranted burden on nodes that implement a tunneling protocol,
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 <xref target="RFC2460"/>
explicitly states that IPv6 receivers MUST discard UDP packets with a
zero checksum. So, while sending a UDP packet with a zero 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 <xref
target="I-D.ietf-6man-udpzero"/>.</t>
<t><xref target="RFC5405">Unicast UDP Usage Guidelines for Application
Designers</xref> should be consulted when reading this specification. It
discusses both UDP tunnels (Section 3.1.3) and the usage of Checksums
(Section 3.4).</t>
<t>While the origin of this specification is the problem raised by the
draft titled "Automatic IP Multicast Without Explicit Tunnels", also
known as "AMT," <xref target="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 <xref
target="I-D.ietf-lisp">LISP</xref> and <xref
target="RFC5619">Softwires</xref> have expressed a need to update the
UDP checksum processing 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.</t>
</section>
<section anchor="term" title="Some Terminology">
<t>For the remainder of this document, we discuss only IPv6, since this
problem does not exist for IPv4. Therefore all reference to 'IP' should
be understood as a reference to IPv6.</t>
<t>The document uses the terms "tunneling" and "tunneled" as adjectives
when describing packets. When we refer to 'tunneling packets' we refer
to the outer packet header that provides the tunneling function. When we
refer to 'tunneled packets' we refer to the inner packet, i.e. the
packet being carried in the tunnel.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="Prob" title="Problem Statement">
<t>This document provides an update for the case where a tunnel protocol
transports tunnelled packets that already have a UDP header with a
checksum, there is both a benefit and a cost to compute and check the
UDP checksum of the outer (encapsulating) UDP transport header. In
certain cases, where reducing the forwarding cost is important, such as
for systems that perform the check in software, the cost may outweigh
the benefit; this document describes a means to avoid that cost, in the
case where there is an inner header with a checksum.</t>
</section>
<section anchor="alts" title="Discussion">
<t><xref target="I-D.ietf-6man-udpzero">IPv6 UDP Checksum
Considerations</xref> describes the issues related to allowing UDP over
IPv6 to have a valid checksum of zero and is not repeated here.</t>
<t>Section 5.1 of <xref target="I-D.ietf-6man-udpzero"/>, identifies 9
requirements that introduce constraints on the usage of a zero checksum
for UDP over IPv6. This document is intended to satisfy these
requirements.</t>
<t><xref target="I-D.ietf-6man-udpzero"/> and mailing list discussions
have noted there 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.</t>
<t>The below discuss how path errors can be detected and handled in an
UDP tunneling protocol when the checksum protection is disabled. Note
that other (non-tunneling) protocols may have different approaches, but
these are not the topic of this update. We propose the following
approach to handle this problem:</t>
<t><list style="symbols">
<t>Context (i.e. tunneling state) should be established via
application Protocol Data Units (PDUs) that are carried in
checksummed UDP packets. That is, any control packets flowing
between the tunnel endpoints should be protected by UDP checksums.
The control packets can also contain any negotiation required to
enable the endpoint/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.</t>
<t>A system shall not set the UDP checksum to zero in packets that
do not contain tunneled packets.</t>
<t>UDP keep-alive packets with checksum zero can be sent to validate
paths, given that paths between tunnel endpoints can change and so
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 the keep-alives and the endpoints will discover that. Note
that this need only be done per tunnel 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.</t>
<t>Corruption of the encapsulating IPv6 source address, destination
address and/or the UDP source port, destination port fields : If the
9 restrictions in <xref target="I-D.ietf-6man-udpzero"/> are
followed, the inner packets (tunneled packets) should be protected
and run the 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: <list style="symbols">
<t>Half of the 16 possible corruption combinations have a
corrupted destination address. If the incorrect destination is
reached and the node doesn't have an application for the
destination port, the packet will be dropped. If the 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 should verify the context of
the packets they receive using UDP, as described in <xref
target="RFC5405"/>. Applications that verify the context of a
datagram are expected to have a high probability of discarding
corrupted data. <xref target="I-D.ietf-6man-udpzero"/> presents
examples of cases where corruption can inadvertently impact
application state.</t>
<t>Half of the 8 possible corruption combinations with a correct
destination address have a corrupted source address. If the
tunnel contexts contain all elements of the address-port
4-tuple, then the likelihood is that this corruption will be
detected.</t>
<t>Of the remaining 4 possibilities, with valid source and
destination IPv6 addresses, 1 has all 4 fields valid, the other
three have one or both ports corrupted. Again, if the tunneling
endpoint context contains sufficient information, these error
should be detected with high probability.</t>
</list></t>
<t>Corruption of source-fragmented encapsulating packets: In this
case, a tunneling protocol may reassemble fragments associated with
the wrong context at the right tunnel endpoint, or it may reassemble
fragments associated with a context at the wrong tunnel endpoint, or
corrupted fragments may be reassembled at the right context at the
right tunnel endpoint. In each of these cases, the IPv6 length of
the encapsulating header may be checked (though <xref
target="I-D.ietf-6man-udpzero"/> points out the weakness in this
check). In addition, if the encapsulated packet is protected by a
transport (or other) checksum, these errors can be detected (with
some probability).</t>
</list>While they do not guarantee correctness, these mechanism can
reduce the risks of relaxing the UDP checksum requirement for IPv6.</t>
</section>
<section anchor="rec" title="The Zero-Checksum Update">
<t>This specification updates IPv6 to allow a UDP checksum of zero for
the outer encapsulating packet of a tunneling protocol. UDP endpoints
that implement this update MUST change their behavior for any
destination port explicitly configured for zero checksum and not discard
UDP packets received with a checksum value of zero on the outer packet.
When this is done, it requires the constraints in Section 5.1 of <xref
target="I-D.ietf-6man-udpzero"/>.</t>
<t>Specifically, the text in <xref target="RFC2460"/> Section 8.1, 4th
bullet is updated. We refer to the following text:</t>
<t>"Unlike IPv4, when UDP packets are originated by an IPv6 node, the
UDP checksum is not optional. That is, whenever originating a UDP
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, it must
be changed to hex FFFF for placement in the UDP header. IPv6 receivers
must discard UDP packets containing a zero checksum, and should log the
error."</t>
<t>This item should be taken out of the bullet list and should be
replaced by:</t>
<t><list style="empty">
<t>Whenever originating a UDP packet, an IPv6 node SHOULD compute a
UDP checksum over the packet and 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 receivers SHOULD discard UDP
packets containing a zero checksum, and SHOULD log the error.
However, some protocols, such as tunneling protocols that use UDP as
a tunnel encapsulation, MAY omit computing the UDP checksum of the
encapsulating UDP header and set it to zero, subject to the
constraints described in RFCXXXX. In cases where the encapsulating
protocol uses a zero checksum for UDP, the receiver of packets 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
RFC2460.</t>
<t><list style="numbers">
<t>IPv6 protocol stack implementations SHOULD NOT by default
allow the new method. The default node receiver behavior MUST
discard all IPv6 packets carrying UDP packets with a zero
checksum.</t>
<t>Implementations MUST provide a way to signal the set of ports
that will be enabled to receive UDP datagrams with a zero
checksum. An IPv6 node that enables reception of UDP packets
with a zero-checksum, MUST enable this only for a specific port
or port-range. This may be implemented via a socket API call, or
similar mechanism.</t>
<t>RFC 2460 specifies that IPv6 nodes should log UDP datagrams
with a zero-checksum. A port for which zero-checksum has been
enabled MUST NOT log zero-checksum datagrams for that reason (of
course, there might be other reasons to log such packets).</t>
<t>A stack may separately identify UDP datagrams that are
discarded with a zero checksum. It SHOULD NOT add these to the
standard log, since the endpoint has not been verified.</t>
<t>UDP Tunnels that encapsulate IP MAY rely on the inner packet
integrity checks provided that the tunnel will not significantly
increase the rate of corruption of the inner IP packet. If a
significantly increased corruption rate can occur, then the
tunnel MUST provide an additional integrity verification
mechanism. An integrity mechanism is always recommended at the
tunnel layer to ensure that corruption rates of the inner most
packet are not increased.</t>
<t>Tunnels that encapsulate Non-IP packets MUST have a CRC or
other mechanism for checking packet integrity, unless the Non-IP
packet specifically is designed for transmission over lower
layers that do not provide any packet integrity guarantee. In
particular, the application must be designed so that corruption
of this information does not result in accumulated state or
incorrect processing of a tunneled payload.</t>
<t>UDP applications that support use of a zero-checksum, SHOULD
NOT rely upon correct reception of the IP and UDP protocol
information (including the length of the packet) when decoding
and processing the packet payload. In particular, the
application must be designed so that corruption of this
information does not result in accumulated state or incorrect
processing of a tunneled payload.</t>
<t>If a method proposes recursive tunnels, it MUST provide
guidance that is appropriate for all use-cases. Restrictions may
be needed to the use of a tunnel encapsulations and the use of
recursive tunnels (e.g. Necessary when the endpoint is not
verified).</t>
<t>IPv6 nodes that receive ICMPv6 messages that refer to packets
with a zero UDP checksum MUST provide appropriate checks
concerning the consistency of the reported packet to verify that
the reported packet actually originated from the node, before
acting upon the information (e.g. validating the address and
port numbers in the ICMPv6 message body).</t>
</list></t>
<t>Middleboxes MUST allow IPv6 packets with UDP checksum equal to
zero to pass. Implementations of middleboxes MAY allow configuration
of specific port ranges for which a zero UDP checksum is valid and
may drop IPv6 UDP packets outside those ranges.</t>
<t>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.</t>
<t>RFC-Editor Note: Please replace RFCXXXX above with the RFC number
this specification receives and remove this note.</t>
</list></t>
</section>
<section title="Additional Observations">
<t>The existence of this issue among a significant number of protocols
being developed in the IETF motivates this specified change. The authors
would also like to make the following observations: <list
style="symbols">
<t>An empirically-based analysis of the probabilities of packet
corruptions (with or without checksums) has not (to our knowledge)
been conducted since about 2000. It is now 2012. We strongly suggest
that an empirical study is in order, along with an extensive
analysis of IPv6 header corruption probabilities.</t>
<t>A key cause to the increased usage of UDP in tunneling is the
lack of protocol support in middleboxes. Specifically, new
protocols, such as LISP <xref target="I-D.ietf-lisp"/>, prefer to
use UDP tunnels to traverse an end-to-end path successfully and
avoid having their packets dropped by middleboxes. If this were not
the case, the use of UDP-lite <xref target="RFC3828"/> might become
more viable for some (but not necessarily all) tunneling
protocols.</t>
<t>Another issue is that the UDP checksum is overloaded with the
task of protecting the IPv6 header for UDP flows (as is the TCP
checksum for TCP flows). Protocols that do not use a pseudo-header
approach to computing a checksum or CRC have essentially no
protection from mis–delivered packets.</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>It requires less work to generate zero-checksum attack packets than
ones with full UDP checksums. However, this does not lead to any
significant new vulnerabilities as checksums are not a security measure
and can be easily generated by any attacker, as properly configured
tunnels should check the validity of the inner packet and perform any
needed security checks, regardless of the checksum status, and finally
as 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).</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We would like to thank Brian Haberman and Gorry Fairhurst for
discussions and reviews.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include="reference.RFC.2460"?>
<?rfc include='reference.RFC.3828'?>
<?rfc include='reference.RFC.5619'?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-mboned-auto-multicast"?>
<?rfc include="reference.I-D.ietf-lisp"?>
<?rfc include="reference.I-D.ietf-6man-udpzero"?>
<?rfc include='reference.RFC.5405'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 01:02:22 |