Network Working Group M. Eubanks
Internet-Draft Iformata Communications
Intended status: Standards Track P. Chimento
Expires: April 27, 2011 Johns Hopkins University Applied
Physics Laboratory
October 24, 2010
UDP Checksums for Tunneled Packets
draft-eubanks-chimento-6man-01
Abstract
We address the problem of computing the UDP checksum on tunneling
IPv6 packets when using lightweight tunneling protocols.
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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Eubanks & Chimento Expires April 27, 2011 [Page 1]
Internet-Draft udp-checksum October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Some Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Recommended Solution . . . . . . . . . . . . . . . . . . . 6
1.5. Additional Observations . . . . . . . . . . . . . . . . . 8
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
3. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
5. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Eubanks & Chimento Expires April 27, 2011 [Page 2]
Internet-Draft udp-checksum October 2010
1. Introduction
The origin of this I-D is the problem raised by the draft titled
"Automatic IP Multicast Without Explicit Tunnels", also known as
"AMT". See draft-ietf-mboned-auto-multicast-09, Section 6.6. That
draft used UDP as the transport layer protocol for tunneling packets;
that is, the outer packet carrying a tunneled (inner) packet is a UDP
packet. The draft specifies that for packets carrying tunneled
multicast data only, the UDP checksum in the UDP header of the outer
packet SHOULD be 0.
However 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. The reason that this
prohibition exists is that there is no header checksum in the IPv6
header. The computation of an additional checksum, when the inner
packet(s) are already adequately protected, is seen to be an
unwarranted burden on nodes implementing lightweight tunneling
protocols. However, there are issues with a UDP checksum of zero in
IPv6 packets; these issues are described in detail in
[I-D.ietf-6man-udpzero]
Since the first version of this draft, the need for an efficient,
lightweight UDP tunneling mechanism has increased. Indeed, other
workgroups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619] have
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
For the remainder of this draft, we discuss only IPv6, since this
problem does not exist for IPv4. So any reference to 'IP' should be
understood as a reference to IPv6.
Although we will try to avoid them when possible, we may use 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.
Eubanks & Chimento Expires April 27, 2011 [Page 3]
Internet-Draft udp-checksum October 2010
1.2. Problem Statement
The argument made by the draft authors is that since in the case of
AMT multicast packets 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 UDP checksum of the outer (encapsulating)
header. Consequently, IPv6 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 outer header only to 0 and skip both the
sender and receiver computation.
1.3. Discussion
The draft [I-D.ietf-6man-udpzero] does an excellent job of discussing
all the issues related to allowing UDP over IPv6 to have a valid
checksum of zero. We will not repeat that work here.
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.
We agree with the restrictions proposed, and in fact proposed some of
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 many
mailing lists, there is still the possibility of deep-inspection
firewall devices or other middleboxes actually checking the UDP
checksum field of the outer packet and discarding the tunneling
packets. This is would be an issue also for legacy systems which
have not implemented the change in the IPv6 specification. So in any
case, there may be packet loss of lightweight tunneling packets
because of mixed new-rule and old-rule nodes.
As an example, we discuss how can errors be detected and handled in a
lightweight UDP tunneling protocol when the checksum protection is
disabled. Note that other (non-tunneling) protocols may have
different approaches. We suggest that the following could be an
approach to this problem:
o Context (i.e. tunneling state) should be established via
application 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 that is necessary to set up the
endpoint/adapters to accept UDP packets with a zero checksum.
o Only UDP packets containing tunneled packets should have a UDP
checksum equal to zero.
Eubanks & Chimento Expires April 27, 2011 [Page 4]
Internet-Draft udp-checksum October 2010
o 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.
o Corruption of the encapsulating IPv6 source address, destination
address and/or the UDP source port, destination port fields : If
the 9 restrictions in [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 lightweight tunneling protocol contexts contain (at a minumum)
source and destination IP addresses and source and destination
ports, there are 16 possible corruption outcomes. We note that
not only are these outcomes not equally likely, most require
multiple bit errors with errored bits in separate fields. The
possible corruption outcomes fall out this way:
* 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
lightweight tunneling protocol and if it has a matching context
(we assume a very small probability event) the inner packet
will be decapsulated and forwarded. If it is some other
application, with very high probability, the application will
not recognize the contents of the packet.
* 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 liklihood is that this corruption will be
detected.
* 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.
o 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
Eubanks & Chimento Expires April 27, 2011 [Page 5]
Internet-Draft udp-checksum October 2010
context at the right tunnel endpoint. In each of these cases, the
IPv6 length of the encapsulating header may be checked (though
[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).
While this is not a perfect solution, it can reduce the risks of
relaxing the UDP checksum requirement for IPv6.
1.4. Recommended Solution
There is a need that a UDP checksum of zero could be allowed on the
outer encapsulating packet of a lightweight tunneling protocol. This
would imply that UDP endpoints handling that protocol must change
their behavior and not discard UDP packets received with a 0 checksum
on the outer packet. We also recommend that the constraints in
Section 5.1 of [I-D.ietf-6man-udpzero] be adopted.
Specifically, this draft proposes that the text in [RFC2460] Section
8.1, 4th bullet be amended. We refer to the following text:
"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."
This item should be taken out of the bullet list and should be
modified as follows:
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 lightweight 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 following constraints (from
[I-D.ietf-6man-udpzero]). In cases, where the encapsulating
protocol uses a zero checksum for UDP, the receiver of packets in
the allowed port range MUST NOT discard packets with 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
Eubanks & Chimento Expires April 27, 2011 [Page 6]
Internet-Draft udp-checksum October 2010
compute the UDP checksum, in which case, its behavior should be as
specified above.
1. IPv6 protocol stack implementations SHOULD NOT by default
allow the new method. The default node receiver behaviour
MUST discard all IPv6 packets carrying UDP packets with a zero
checksum.
2. 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.
3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams
with a zero-checksum. This should remain the case for any
datagram received on a port that does not explicitly enable
zero-checksum processing. A port for which zero-checksum has
been enabled MUST NOT log the datagram.
4. 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.
5. UDP Tunnels that encapsulate IP MUST 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.
6. 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.
7. 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
Eubanks & Chimento Expires April 27, 2011 [Page 7]
Internet-Draft udp-checksum October 2010
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.
8. 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).
9. 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).
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.
1.5. Additional Observations
The persistence of this issue among a significant number of protocols
being developed in the IETF requires a definitive policy. The
authors would like to make the following observations:
o 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 2010. We strongly
suggest that an empirical study is in order, along with an
extensive analysis of IPv6 header corruption probabilities.
o A key cause of this issue generally is the lack of protocol
support in middleboxes. Specifically, new protocols, such as
DCCP, are being forced to use UDP tunnels just 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 might
become more viable for some (but not necessarily all) lightweight
tunneling protocols.
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
the TCP checksum for TCP flows). Protocols that do not use a
pseudo-header approach to computing a checksum or CRC have
Eubanks & Chimento Expires April 27, 2011 [Page 8]
Internet-Draft udp-checksum October 2010
essentially no protection from misdelivered packets. We suggest
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
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
3. Security Considerations
It is of course 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).
4. Acknowledgements
We would like to thank Brian Haberman, Magnus Westerlund and Gorry
Fairhurst for discussions and reviews.
5. Normative References
[I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
Considerations", draft-ietf-6man-udpzero-02 (work in
progress), October 2010.
[I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-09 (work in progress), October 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Eubanks & Chimento Expires April 27, 2011 [Page 9]
Internet-Draft udp-checksum October 2010
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
"Softwire Security Analysis and Requirements", RFC 5619,
August 2009.
Authors' Addresses
Marshall Eubanks
Iformata Communications
Phone: +1-703-501-4376
Fax:
Email: marshall.eubanks@iformata.com
URI:
P.F. Chimento
Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road
Laurel, MD 20723
USA
Phone: +1-443-778-1743
Fax:
Email: Philip.Chimento@jhuapl.edu
URI:
Eubanks & Chimento Expires April 27, 2011 [Page 10]
Internet-Draft udp-checksum October 2010
Eubanks & Chimento Expires April 27, 2011 [Page 11]