Network Working Group M. Eubanks
Internet-Draft Iformata Communications
Intended status: Standards Track P. Chimento
Expires: August 27, 2009 Johns Hopkins University Applied
Physics Laboratory
February 23, 2009
UDP Checksums for Tunneled Packets
draft-eubanks-chimento-6man-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2009.
Copyright Notice
Copyright (c) 2009 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.
Eubanks & Chimento Expires August 27, 2009 [Page 1]
Internet-Draft udp-checksum February 2009
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Some Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3
1.3. Alternate Solutions . . . . . . . . . . . . . . . . . . . . 3
1.4. Possible Pitfalls of a change . . . . . . . . . . . . . . . 4
1.5. Recommended Solution . . . . . . . . . . . . . . . . . . . 5
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Eubanks & Chimento Expires August 27, 2009 [Page 2]
Internet-Draft udp-checksum February 2009
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". This draft uses UDP as the layer protocol in tunneling
packets; that is, the outer packet carrying a tunneled (inner)
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 (See draft-ietf-mboned-auto-multicast-09, Section
6.6). However RFC 2460 (IPv6) 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 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.
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.
1.2. Problem Statement
The argument made by the draft authors is that since 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. However,
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. Alternate Solutions
1. UDP-lite: Some suggestions on the mailing list have been to use
UDP-lite (RFC 3828) [RFC3828]. This solution minimizes
computation. For example, if a tunneling protocol were to use
UDP-lite with a checksum coverage field of 8 to construct the
Eubanks & Chimento Expires August 27, 2009 [Page 3]
Internet-Draft udp-checksum February 2009
outer (tunneling) packet, the only variable quantity for a given
tunnel is the packet length of the inner (tunneled) packet, since
the IPv6 pseudo-header is otherwise fixed. This is a constant
value then added to the inner packet length (which should be
known when the outer packet is constructed). This is simply an
add and store, and a computation of the pseudo-header checksum
when the tunnel is created. The possible objections to this
approach are twofold: First, it still involves computation which
some view as unnecessary. Second, NAT traversal is a problem for
UDP-lite and may cause packet loss.
2. No exception for lightweight tunneling: Retain the IPv6
specification as it stands and do not allow a UDP checksum equal
to 0 in an outer IPv6 tunneling packet.
3. Exception for lightweight tunneling: Amend IPv6 to allow a 0
value in the UDP checksum field for leightweight tunneling
protocols which allows them to bypass any checksum computation in
the outer header if the inner packet is protected. Rules for
usage in this case must be developed.
4. Another possibilty is to allow an exception for the AMT protocol
only. This may seem undesirable, but it would restrict the
implementation of a zero checksum UDP header over IPv6 only to
the AMT endpoints. Any misdelivered packets (i.e. arriving at a
non-AMT endpoint) would simply be discarded.
1.4. Possible Pitfalls of a change
One potential problem with the approach which allows an exception to
the IPv6 UDP checksum rule is that in general, tunneling (outer) IPv6
packets could be encapsulating either IPv6 packets or IPv4 packets.
If the inner (tunneled) packet is an IPv4 packet with a 0 UDP
checksum, then the neither the inner nor the outer packet will
provide any checksum protection. This would likewise be the case if
the inner packet were an IPv6 packet produced by another (future)
protocol which uses an exception to the IPv6 rule.
Others on the mailing list have pointed out other issues with
changing the IPv6 specification to allow a checksum of 0 on the outer
packet header. In particular, Matt Mathis points out that some
tunneling devices ignore the DF bit and fragment silently. This
would allow two fragmented UDP packets to be spliced together and be
decapsulated and forwarded by a tunnel endpoint.
One notes also that there is no IPv6 header checksum.
There is also the possibility of deep-inspection firewall devices or
Eubanks & Chimento Expires August 27, 2009 [Page 4]
Internet-Draft udp-checksum February 2009
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.
1.5. Recommended Solution
There seems to be some general opinion that a UDP checksum of 0 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.
Magnus Westerlund proposed some restrictions on using a UDP header
checksum of 0. These are:
1. There must be some way to verify the integrity of the inner
(tunneled) packet.
2. The tunneling protocol and implementation must not use
fragmentation of the inner packets being carried.
We would suggest the following elaborations of the above
restrictions, if a change in the IPv6 specification moves forward:
o An inner IPv4 packet with a UDP checksum equal to 0 must not be
tunneled.
o Non-IP inner packets must have a CRC or other mechanism for
checking packet integrity.
o Other tunneling protcocols that use the UDP checksum equal to 0
MUST NOT be tunneled themselves, even if more deeply encapsulated
packets have checksums or other integrity checking mechanisms.
o We would recommend that general protocol stack implementations do
NOT implement this change. The exception should remain restricted
to devices serving as endpoints of the lightweight tunneling
protocol adopting the change.
In addition, we would recommend that a security analysis be done in
order to assess whether any new vulnerabilities are introduced by
such a change.
Eubanks & Chimento Expires August 27, 2009 [Page 5]
Internet-Draft udp-checksum February 2009
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
4. Acknowledgements
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
Authors' Addresses
Marshall Eubanks
Iformata Communications
Phone:
Fax:
Email: tme@multicasttech.com
URI:
Eubanks & Chimento Expires August 27, 2009 [Page 6]
Internet-Draft udp-checksum February 2009
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 August 27, 2009 [Page 7]