draft-ietf-6man-udpchecksums-06.txt   draft-ietf-6man-udpchecksums-07.txt 
Network Working Group M. Eubanks Network Working Group M. Eubanks
Internet-Draft AmericaFree.TV LLC Internet-Draft AmericaFree.TV LLC
Updates: 2460 (if approved) P. Chimento Updates: 2460 (if approved) P. Chimento
Intended status: Standards Track Johns Hopkins University Applied Intended status: Standards Track Johns Hopkins University Applied
Expires: June 14, 2013 Physics Laboratory Expires: July 21, 2013 Physics Laboratory
M. Westerlund M. Westerlund
Ericsson Ericsson
December 11, 2012 January 17, 2013
IPv6 and UDP Checksums for Tunneled Packets IPv6 and UDP Checksums for Tunneled Packets
draft-ietf-6man-udpchecksums-06 draft-ietf-6man-udpchecksums-07
Abstract Abstract
This document provides an update of the Internet Protocol version 6 This document provides an update of the Internet Protocol version 6
(IPv6) specification (RFC2460) to improve the performance in the use (IPv6) specification (RFC2460) to improve the performance in the use
case when a tunnel protocol uses UDP with IPv6 to tunnel packets. case where a tunnel protocol uses UDP with IPv6 to tunnel packets.
The performance improvement is obtained by relaxing the IPv6 UDP The performance improvement is obtained by relaxing the IPv6 UDP
checksum requirement for suitable tunneling protocol where header checksum requirement for any suitable tunnel protocol where header
information is protected on the "inner" packet being carried. This information is protected on the "inner" packet being carried. This
relaxation removes the overhead associated with the computation of relaxation removes the overhead associated with the computation of
UDP checksums on IPv6 packets used to carry tunnel protocols. The UDP checksums on IPv6 packets used to carry tunnel protocols. The
specification describes how the IPv6 UDP checksum requirement can be specification describes how the IPv6 UDP checksum requirement can be
relaxed for the situation where the encapsulated packet itself relaxed for the situation where the encapsulated packet itself
contains a checksum. The limitations and risks of this approach are contains a checksum. The limitations and risks of this approach are
described, and restrictions specified on the use of the method. described, and restrictions specified on the use of the method.
Status of this Memo Status of this Memo
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 June 14, 2013. This Internet-Draft will expire on July 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7 4.2. Limitation to Tunnel Protocols . . . . . . . . . . . . . . 7
4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8
5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 8 5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 8
6. Additional Observations . . . . . . . . . . . . . . . . . . . 9 6. Additional Observations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This work constitutes an update of the Internet Protocol Version 6 This work constitutes an update of the Internet Protocol Version 6
(IPv6) Specification [RFC2460], in the use case when a tunnel (IPv6) Specification [RFC2460], in the use case where a tunnel
protocol uses UDP with IPv6 to tunnel packets. With the rapid growth protocol uses UDP with IPv6 to tunnel packets. With the rapid growth
of the Internet, tunneling protocols have become increasingly of the Internet, tunnel protocols have become increasingly important
important to enable the deployment of new protocols. Tunneled to enable the deployment of new protocols. Tunnel protocols can be
protocols can be deployed rapidly, while the time to upgrade and deployed rapidly, while the time to upgrade and deploy a critical
deploy a critical mass of routers, middleboxes and hosts on the mass of routers, middleboxes and hosts on the global Internet for a
global Internet for a new protocol is now measured in decades. At new protocol is now measured in decades. At the same time, the
the same time, the increasing use of firewalls and other security- increasing use of firewalls and other security-related middleboxes
related middleboxes means that truly new tunnel protocols, with new means that truly new tunnel protocols, with new protocol numbers, are
protocol numbers, are also unlikely to be deployable in a reasonable also unlikely to be deployable in a reasonable time frame, which has
time frame, which has resulted in an increasing interest in and use resulted in an increasing interest in and use of UDP-based tunnel
of UDP-based tunneling protocols. In such protocols, there is an protocols. In such protocols, there is an encapsulated "inner"
encapsulated "inner" packet, and the "outer" packet carrying the packet, and the "outer" packet carrying the tunneled inner packet is
tunneled inner packet is a UDP packet, which can pass through a UDP packet, which can pass through firewalls and other middleboxes
firewalls and other middleboxes that perform filtering that is a fact that perform filtering that is a fact of life on the current
of life on the current Internet. Internet.
Tunnel endpoints may be routers or middleboxes aggregating traffic Tunnel endpoints may be routers or middleboxes aggregating traffic
from a number of tunnel users, therefore the computation of an from a number of tunnel users, therefore the computation of an
additional checksum on the outer UDP packet, may be seen as an additional checksum on the outer UDP packet may be seen as an
unwarranted burden on nodes that implement a tunneling protocol, unwarranted burden on nodes that implement a tunnel protocol,
especially if the inner packet(s) are already protected by a especially if the inner packet(s) are already protected by a
checksum. In IPv4, there is a checksum over the IP packet header, checksum. In IPv4, there is a checksum over the IP packet header,
and the checksum on the outer UDP packet may be set to zero. However and the checksum on the outer UDP packet may be set to zero. However
in IPv6 there is no checksum in the IP header and RFC 2460 [RFC2460] in IPv6 there is no checksum in the IP header and RFC 2460 [RFC2460]
explicitly states that IPv6 receivers MUST discard UDP packets with a explicitly states that IPv6 receivers MUST discard UDP packets with a
zero checksum. So, while sending a UDP datagram with a zero checksum zero checksum. So, while sending a UDP datagram with a zero checksum
is permitted in IPv4 packets, it is explicitly forbidden in IPv6 is permitted in IPv4 packets, it is explicitly forbidden in IPv6
packets. To improve support for IPv6 UDP tunnels, this document packets. To improve support for IPv6 UDP tunnels, this document
updates RFC 2460 to allow endpoints to use a zero UDP checksum under updates RFC 2460 to allow endpoints to use a zero UDP checksum under
constrained situations (primarily IPv6 tunnel transports that carry constrained situations (primarily IPv6 tunnel transports that carry
checksum-protected packets), following the applicability statements checksum-protected packets), following the applicability statements
and constraints in [I-D.ietf-6man-udpzero]. and constraints in [I-D.ietf-6man-udpzero].
Unicast UDP Usage Guidelines for Application Designers [RFC5405] "Unicast UDP Usage Guidelines for Application Designers" [RFC5405]
should be consulted when reading this specification. It discusses should be consulted when reading this specification. It discusses
both UDP tunnels (Section 3.1.3) and the usage of checksums (Section both UDP tunnels (Section 3.1.3) and the usage of checksums (Section
3.4). 3.4).
While the origin of this specification is the problem raised by the While the origin of this specification is the problem raised by the
draft titled "Automatic IP Multicast Without Explicit Tunnels", also draft titled "Automatic Multicast Tunnels", also known as "AMT"
known as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have [I-D.ietf-mboned-auto-multicast] we expect it to have wide
wide applicability. Since the first version of this document, the applicability. Since the first version of this document, the need
need for an efficient UDP tunneling mechanism has increased. Other for an efficient UDP tunneling mechanism has increased. Other IETF
IETF Working Groups, notably LISP [I-D.ietf-lisp] and Softwires Working Groups, notably LISP [I-D.ietf-lisp] and Softwires [RFC5619]
have expressed a need to update the UDP checksum processing in RFC
[RFC5619] have expressed a need to update the UDP checksum processing 2460. We therefore expect this update to be applicable in the future
in RFC 2460. We therefore expect this update to be applicable in to other tunnel protocols specified by these and other IETF Working
future to other tunneling protocols specified by these and other IETF Groups.
Working Groups.
2. Some Terminology 2. Some Terminology
This document discusses only IPv6, since this problem does not exist This document discusses only IPv6, since this problem does not exist
for IPv4. Therefore all reference to 'IP' should be understood as a for IPv4. Therefore all reference to 'IP' should be understood as a
reference to IPv6. reference to IPv6.
The document uses the terms "tunneling" and "tunneled" as adjectives The document uses the terms "tunneling" and "tunneled" as adjectives
when describing packets. When we refer to 'tunneling packets' we when describing packets. When we refer to 'tunneling packets' we
refer to the outer packet header that provides the tunneling refer to the outer packet header that provides the tunneling
skipping to change at page 4, line 32 skipping to change at page 4, line 31
2.1. Requirements Language 2.1. 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].
3. Problem Statement 3. Problem Statement
When using tunnel protocols based on UDP, there can be both a benefit When using tunnel protocols based on UDP, there can be both a benefit
and a cost to computing and checking the UDP checksum of the outer and a cost to computing and checking the UDP checksum of the outer
(encapsulating) UDP transport header. In certain cases, where (encapsulating) UDP transport header. In certain cases, reducing the
reducing the forwarding cost is important, such as for nodes that forwarding cost is important, e.g., for nodes that perform the
perform the checksum in software, where the cost may outweigh the checksum in software the cost may outweigh the benefit. This
benefit. This document provides an update for usage of the UDP document provides an update for usage of the UDP checksum with IPv6.
checksum with IPv6. The update is specified for use by a tunnel The update is specified for use by a tunnel protocol that transports
protocol that transports packets that are themselves protected by a packets that are themselves protected by a checksum.
checksum.
4. Discussion 4. Discussion
Applicability Statement for the use of IPv6 UDP Datagrams with Zero "Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums [I-D.ietf-6man-udpzero] describes issues related to Checksums" [I-D.ietf-6man-udpzero] describes issues related to
allowing UDP over IPv6 to have a valid zero UDP checksum and is the allowing UDP over IPv6 to have a valid zero UDP checksum and is the
starting point for this discussion. Section 4 and 5 of starting point for this discussion. Sections 4 and 5 of
[I-D.ietf-6man-udpzero], respectively identify node implementation [I-D.ietf-6man-udpzero], respectively identify node implementation
and usage requirements for datagrams sent and received with a zero and usage requirements for datagrams sent and received with a zero
UDP checksum. These introduce constraints on the usage of a zero UDP checksum. These introduce constraints on the usage of a zero
checksum for UDP over IPv6. The remainder of this section analyses checksum for UDP over IPv6. The remainder of this section analyses
the use of general tunnels and motivates why tunnel protocols are the use of general tunnels and motivates why tunnel protocols are
being permitted to use the method described in this update. Issues being permitted to use the method described in this update. Issues
with middleboxes are also discussed. with middleboxes are also discussed.
4.1. Analysis of Corruption in Tunnel Context 4.1. Analysis of Corruption in Tunnel Context
This section analyzes the impact of the different corruption modes in This section analyzes the impact of the different corruption modes in
the context of a tunnel protocol. It indicates what needs to be the context of a tunnel protocol. It indicates what needs to be
considered by the designer and user of a tunnel protocol to be considered by the designer and user of a tunnel protocol to be
robust. It also summarizes why use of a zero UDP checksum is thought robust. It also summarizes why use of a zero UDP checksum is thought
safe for deployment. to be safe for deployment.
o Context (i.e. tunneling state) should be established by exchanging 1. Context (i.e., tunneling state) should be established by
application Protocol Data Units (PDUs) carried in checksummed UDP exchanging application Protocol Data Units (PDUs) carried in
datagrams or by other protocols with integrity protection against checksummed UDP datagrams or by other protocols with integrity
corruption. These control packets should also carry any protection against corruption. These control packets should also
negotiation required to enable the tunnel endpoint to accept UDP carry any negotiation required to enable the tunnel endpoint to
datagrams with a zero checksum and identify the set of ports that accept UDP datagrams with a zero checksum and identify the set of
are used. It is important that the control traffic is robust ports that are used. It is important that the control traffic is
against corruption because undetected errors can lead to long- robust against corruption because undetected errors can lead to
lived and significant failures that affect not only the single long-lived and significant failures that may affect much more
packet that was corrupted. than the single packet that was corrupted.
o Keep-alive datagrams with a zero UDP checksum should be sent to 2. Keep-alive datagrams with a zero UDP checksum should be sent to
validate the network path, because the path between tunnel validate the network path, because the path between tunnel
endpoints can change and therefore the set of middleboxes along endpoints can change and therefore the set of middleboxes along
the path may change during the life of an association. Paths with the path may change during the life of an association. Paths
middleboxes that drop datagrams with a zero UDP checksum will drop with middleboxes that drop datagrams with a zero UDP checksum
these keep-alives. To enable the tunnel endpoints to discover and will drop these keep-alives. To enable the tunnel endpoints to
react to this behavior in a timely way, the keep-alive traffic discover and react to this behavior in a timely way, the keep-
should include datagrams with both a non-zero checksum and ones alive traffic should include datagrams with a non-zero checksum
with a zero checksum. and datagrams with a zero checksum.
o Corruption of the address information in an encapsulating packets, 3. Receivers should attempt to detect corruption of the address
i.e. IPv6 source address, destination address and/or the UDP information in an encapsulating packet. A robust tunnel protocol
source port, and destination port fields. A robust tunnel should track tunnel context based on the 5-tuple (tunneled
protocol should track tunnel context based on the 5-tuple, i.e. protocol number, IPv6 source address, IPv6 destination address,
the protocol and both the address and port for both the source and UDP source port, UDP destination port). A corrupted datagram
destination. A corrupted datagram that arrives at a destination that arrives at a destination may be filtered based on this
may be filtered based on this check. check.
* If the datagram header matches the 5-tuple with a zero checksum * If the datagram header matches the 5-tuple and the node has
enabled, the payload is matched to the wrong context. The the zero checksum enabled for this port, the payload is
tunneled packet will then be decapsulated and forwarded by the matched to the wrong context. The tunneled packet will then
tunnel egress. be decapsulated and forwarded by the tunnel egress.
* If a corrupted datagram matches a different 5-tuple with a zero * If a corrupted datagram matches a different 5-tuple and the
checksum enabled, the payload is matched to the wrong context, zero checksum was enabled for the port, the datagram payload
and may be processed by the wrong tunneling protocol, if it is matched to the wrong context, and may be processed by the
passes the verification of that protocol. wrong tunnel protocol, if it also passes the verification of
that protocol.
* If a corrupted datagram matches a 5-tuple that does not have a * If a corrupted datagram matches a 5-tuple and the zero
zero checksum enabled, it will be discarded. checksum has not been enabled for this port, the datagram will
be discarded.
When only the source information is corrupted, the datagram could When only the source information is corrupted, the datagram could
arrive at the intended applications/protocol which will process it arrive at the intended applications/protocol, which will process
and try to match it against an existing tunnel context. If the the datagram and try to match it against an existing tunnel
protocol restricts processing to only the source addresses with context. The likelihood that a corrupted packet enters a valid
established contexts the likelihood that a corrupted packet enters context is reduced when the protocol restricts processing to only
a valid context is reduced. When both source and destination the source addresses with established contexts. When both source
fields are corrupted, this increases the likelihood of failing to and destination fields are corrupted, this increases the
match a context, with the exception of errors replacing one packet likelihood of failing to match a context, with the exception of
header with another one. In this case it is possible that both errors replacing one packet header with another one. In this
are tunnels and thus the corrupted packet can match a previously case, it is possible that both packets are tunnelled and
defined context. therefore the corrupted packet could match a previously defined
context.
o Corruption of source-fragmented encapsulating packets: In this 4. Receivers should attempt to detect corruption of source-
case, a tunneling protocol may reassemble fragments associated fragmented encapsulating packets. A tunnel protocol may
with the wrong context at the right tunnel endpoint, or it may reassemble fragments associated with the wrong context at the
reassemble fragments associated with a context at the wrong tunnel right tunnel endpoint, or it may reassemble fragments associated
endpoint, or corrupted fragments may be reassembled at the right with a context at the wrong tunnel endpoint, or corrupted
context at the right tunnel endpoint. In each of these cases, the fragments may be reassembled at the right context at the right
IPv6 length of the encapsulating header may be checked (though tunnel endpoint. In each of these cases, the IPv6 length of the
[I-D.ietf-6man-udpzero] points out the weakness in this check). encapsulating header may be checked (though
In addition, if the encapsulated packet is protected by a [I-D.ietf-6man-udpzero] points out the weakness in this check).
transport (or other) checksum, these errors can be detected (with In addition, if the encapsulated packet is protected by a
some probability). transport (or other) checksum, these errors can be detected (with
some probability).
o Tunnel protocols using UDP have some advantages that reduce the 5. Tunnel protocols using UDP have some advantages that reduce the
risk for a corrupted tunnel packet reaching a destination that risk for a corrupted tunnel packet reaching a destination that
will receive it, compared to other applications. This results will receive it, compared to other applications. This results
from processing by the network of the inner (tunneled) packet from processing by the network of the inner (tunneled) packet
after being forwarded from the tunnel egress using a wrong after being forwarded from the tunnel egress using a wrong
context: context:
* A tunneled packet may be forwarded to the wrong address domain, * A tunneled packet may be forwarded to the wrong address
for example a private address domain where the inner packet's domain, for example, a private address domain where the inner
address is not routable, or may fail a source address check, packet's address is not routable, or may fail a source address
such as Unicast Reverse Path Forwarding [RFC2827], resulting in check, such as Unicast Reverse Path Forwarding [RFC2827],
the packet being dropped. resulting in the packet being dropped.
* The destination address of a tunneled packet may not at all be * The destination address of a tunneled packet may not at all be
reachable from the delivered domain. For example an Ethernet reachable from the delivered domain. For example, an Ethernet
packet where the destination MAC address is not present on the frame where the destination MAC address is not present on the
LAN segment that was reached. LAN segment that was reached.
* The type of the tunneled packet may prevent delivery for * The type of the tunneled packet may prevent delivery. For
example if an IP packet payload was attempted to be interpreted example, an attempt to interpret an IP packet payload as an
as an Ethernet packet. This is likely to result in the packet Ethernet frame, would likely to result in the packet being
being dropped as invalid. dropped as invalid.
* The tunneled packet checksum or integrity mechanism may detect * The tunneled packet checksum or integrity mechanism may detect
corruption of the inner packet caused at the same time as corruption of the inner packet caused at the same time as
corruption to the outer packet header. The resulting packet corruption to the outer packet header. The resulting packet
would likely be dropped as invalid. would likely be dropped as invalid.
These different examples each help to significantly reduce the These checks each significantly reduce the likelihood that a
likelihood that a corrupted inner tunneled packet is finally corrupted inner tunneled packet is finally delivered to a protocol
delivered to a protocol listener that can be affected by the packet. listener that can be affected by the packet. While the methods do
While the methods do not guarantee correctness, they can reduce the not guarantee correctness, they can reduce the risk of relaxing the
risk of relaxing the UDP checksum requirement for a tunnel UDP checksum requirement for a tunnel application using IPv6.
application using IPv6.
4.2. Limitation to Tunnel Protocols 4.2. Limitation to Tunnel Protocols
This document describes the applicability of using a zero UDP This document describes the applicability of using a zero UDP
checksum to support tunnel protocols. There are good motivations checksum to support tunnel protocols. There are good motivations
behind this and the arguments are provided here. behind this and the arguments are provided here.
o Tunnels carry inner packets that have their own semantics that o Tunnels carry inner packets that have their own semantics, which
makes any corruption less likely to reach the indicated may make any corruption less likely to reach the indicated
destination and be accepted as a valid packet. This is true for destination and be accepted as a valid packet. This is true for
IP packets with the addition of verification that can be made by IP packets with the addition of verification that can be made by
the tunnel protocol, the networks' processing of the inner packet the tunnel protocol, the network processing of the inner packet
headers as discussed above, and verification of the inner packet headers as discussed above, and verification of the inner packet
checksums. Also non-IP inner packets are likely to be subject to checksums. Non-IP inner packets are likely to be subject to
similar effects that reduce the likelihood that an mis-delivered similar effects that may reduce the likelihood of a misdelivered
packet are delivered. packet being delivered to a protocol listener that can be affected
by the packet.
o Protocols that directly consume the payload must have sufficient o Protocols that directly consume the payload must have sufficient
robustness against mis-delivered packets from any context, robustness against misdelivered packets from any context,
including the ones that are corrupted in tunnels and any other including the ones that are corrupted in tunnels and any other
usage of the zero checksum. This will require an integrity usage of the zero checksum. This will require an integrity
mechanism. Using a standard UDP checksum reduces the mechanism. Using a standard UDP checksum reduces the
computational load in the receiver to verify this mechanism. computational load in the receiver to verify this mechanism.
o Stateful protocols or protocols where corruption causes cascade o The design for stateful protocols or protocols where corruption
effects need to be extra careful. In tunnel usage each causes cascade effects requires extra care. In tunnel usage, each
encapsulating packet provides only a transport mechanism from encapsulating packet provides only a transport mechanism from
tunnel ingress to tunnel egress. A corruption will commonly only tunnel ingress to tunnel egress. A corruption will commonly only
effect the single packet, not established protocol state. One affect the single tunneled packet, not the established protocol
common effect is that the inner packet flow will only see a state. One common effect is that the inner packet flow will only
corruption and mis-delivery of the outer packet as a lost packet. see a corruption and misdelivery of the outer packet as a lost
packet.
o Some non-tunnel protocols operate with general servers that do not o Some non-tunnel protocols operate with general servers that do not
know from where they will receive a packet. In such applications, know the source from which they will receive a packet. In such
the usage of a zero UDP checksum is especially unsuitable because applications, a zero UDP checksum is unsuitable because there is a
there is a need to provide the first level of verification that need to provide the first level of verification that the packet
the packet was intended for the server. This verification was intended for the receiving server. A verification prevents
prevents the server from processing the datagram payload and spend the server from processing the datagram payload and without this
any significant amount of resources on it, including sending it may spend significant resources processing the packet,
replies or error messages. including sending replies or error messages.
Tunnel protocols encapsulating IP this will generally be safe, since Tunnel protocols that encapsulate IP will generally be safe for
all IPv4 and IPv6 packets include at least one checksum at either the deployment, since all IPv4 and IPv6 packets include at least one
network or transport layer and the network delivery of the inner checksum at either the network or transport layer. The network
packet will further reduce the effects of corruption. Tunnel delivery of the inner packet will then further reduce the effects of
protocols carrying non-IP packets may provide equivalent protection corruption. Tunnel protocols carrying non-IP packets may offer
due to the non-IP networks reducing the risk of delivery to equivalent protection when the non-IP networks reduce the risk of
applications. However, there is need for further analysis to misdelivery to applications. However, there is a need for further
understand the implications of mis-delievery of corrupted packets for analysis to understand the implications of misdelievery of corrupted
that each non-IP protocol. The analysis above suggests that non- packets for that each non-IP protocol. The analysis above suggests
tunnel protocols can be expected to have significantly more cases that non-tunnel protocols can be expected to have significantly more
where a zero checksum would result in mis-delivery or negative side- cases where a zero checksum would result in misdelivery or negative
effects. side-effects.
One unfortunate side-effect of increased use of a zero-checksum is One unfortunate side-effect of increased use of a zero-checksum is
that it also increases the likelihood of acceptance when a datagram that it also increases the likelihood of acceptance when a datagram
with a zero UDP checksum is mis-delivered. This requires all tunnel with a zero UDP checksum is misdelivered. This requires all tunnel
protocols using this method to be designed to be robust to mis- protocols using this method to be designed to be robust to
delivery. misdelivery.
4.3. Middleboxes 4.3. Middleboxes
Applicability Statement for the use of IPv6 UDP Datagrams with Zero "Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums [I-D.ietf-6man-udpzero] notes that middlebox devices that Checksums" [I-D.ietf-6man-udpzero] notes that middleboxes that
conform to RFC 2460 will discard datagrams with a zero UDP checksum conform to RFC 2460 will discard datagrams with a zero UDP checksum
and should log this as an error. Thus tunnel protocols intending to and should log this as an error. Tunnel protocols intending to use a
use a zero UDP checksum needs to ensure that they have defined a zero UDP checksum need to ensure that they have defined a method for
method for handling cases when a middlebox prevents the path between handling cases when a middlebox prevents the path between the tunnel
the tunnel ingress and egress from supporting transmission of ingress and egress from supporting transmission of datagrams with a
datagrams with a zero UDP checksum. zero UDP checksum.
5. The Zero-Checksum Update 5. The Zero-Checksum Update
This specification updates IPv6 to allow a zero UDP checksum in the This specification updates IPv6 to allow a zero UDP checksum in the
outer encapsulating datagram of a tunneling protocol. UDP endpoints outer encapsulating datagram of a tunnel protocol. UDP endpoints
that implement this update MUST follow the node requirements that implement this update MUST follow the node requirements in
"Applicability Statement for the use of IPv6 UDP Datagrams with Zero "Applicability Statement for the use of IPv6 UDP Datagrams with Zero
Checksums" [I-D.ietf-6man-udpzero]. Checksums" [I-D.ietf-6man-udpzero].
The following text in [RFC2460] Section 8.1, 4th bullet should be The following text in [RFC2460] Section 8.1, 4th bullet should be
deleted: deleted:
"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 text should be replaced by: This text should be replaced by:
Whenever originating a UDP packet in the default mode, an IPv6 An IPv6 node associates a mode with each active UDP port.
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 by default discard UDP packets containing a zero
checksum, and SHOULD log the error. As an alternative usage for
some protocols, such as protocols that use UDP as a tunnel
encapsulation, MAY enable the zero-checksum mode for specific sets
of ports. Any node implementing the zero-checksum mode MUST
follow the node requirements specified in Section 4 of
Applicability Statement for the use of IPv6 UDP Datagrams with
Zero Checksums [I-D.ietf-6man-udpzero].
Any protocol using the zero-checksum mode MUST follow the usage Whenever originating a UDP packet for a port in the default mode,
requirements specified in Section 5 of Applicability Statement for an IPv6 node MUST compute a UDP checksum over the packet and the
the use of IPv6 UDP Datagrams with Zero Checksums pseudo-header, and, if that computation yields a result of zero,
[I-D.ietf-6man-udpzero]. it MUST be changed to hex FFFF for placement in the UDP header.
IPv6 receivers MUST by default discard UDP packets containing a
zero checksum, and SHOULD log the error.
Middleboxes supporting IPv6 MUST follow the requirements 9, 10 and As an alternative, certain protocols that use UDP as a tunnel
11 of the usage requirements specified in Section 5 of encapsulation, MAY enable the zero-checksum mode for a specific
Applicability Statement for the use of IPv6 UDP Datagrams with port (or set of ports). Any node implementing the zero-checksum
Zero Checksums [I-D.ietf-6man-udpzero]. mode MUST follow the node requirements specified in Section 4 of
"Applicability Statement for the use of IPv6 UDP Datagrams with
Zero Checksums" [I-D.ietf-6man-udpzero].
Any protocol that enables the zero-checksum mode for a specific
port or ports MUST follow the usage requirements specified in
Section 5 of "Applicability Statement for the use of IPv6 UDP
Datagrams with Zero Checksums" [I-D.ietf-6man-udpzero].
Middleboxes supporting IPv6 MUST follow requirements 9, 10 and 11
of the usage requirements specified in Section 5 of "Applicability
Statement for the use of IPv6 UDP Datagrams with Zero Checksums"
[I-D.ietf-6man-udpzero].
6. Additional Observations 6. Additional Observations
This update was motivated by the existence of a number of protocols This update was motivated by the existence of a number of protocols
being developed in the IETF that are expected to benefit from the being developed in the IETF that are expected to benefit from the
change. The following observations are made: change. The following observations are made:
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) corruption (with or without checksums) has not (to our knowledge)
been conducted since about 2000. At the time of publication, it been conducted since about 2000. At the time of publication, it
is now 2012. We strongly suggest a new empirical study, along is now 2012. We strongly suggest a new empirical study, along
with an extensive analysis of the corruption probabilities of the with an extensive analysis of the corruption probabilities of the
IPv6 header. IPv6 header.
o A key motivation for the increase in use of UDP in tunneling is a o A key motivation for the increase in use of UDP in tunneling is a
lack of protocol support in middleboxes. Specifically, new lack of protocol support in middleboxes. Specifically, new
protocols, such as LISP [I-D.ietf-lisp], may prefer to use UDP protocols, such as LISP [I-D.ietf-lisp], may prefer to use UDP
tunnels to traverse an end-to-end path successfully and avoid tunnels to traverse an end-to-end path successfully and avoid
having their packets dropped by middleboxes. If middleboxes were having their packets dropped by middleboxes. If middleboxes were
updated to support UDP-Lite [RFC3828], this would provide better updated to support UDP-Lite [RFC3828], UDP-Lite would provide
protection than offered by this update. This may be suited to a better protection than offered by this update. This may be suited
variety of applications and would be expected to be preferred over to a variety of applications and would be expected to be preferred
this method for many tunnel protocols. over this method for many tunnel protocols.
o Another issue is that the UDP checksum is overloaded with the task o Another issue is that the UDP checksum is overloaded with the task
of protecting the IPv6 header for UDP flows (as is the TCP of protecting the IPv6 header for UDP flows (as is the TCP
checksum for TCP flows). Protocols that do not use a pseudo- checksum for TCP flows). Protocols that do not use a pseudo-
header approach to computing a checksum or CRC have essentially no header approach to computing a checksum or CRC have essentially no
protection from mis-delivered packets. protection from misdelivered 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
Less work is required required to generate an attack using a zero UDP Less work is required to generate an attack using a zero UDP checksum
checksum than one using a standard full UDP checksum. However, this than one using a standard full UDP checksum. However, this does not
does not lead to significant new vulnerabilities because checksums lead to significant new vulnerabilities because checksums are not a
are not a security measure and can be easily generated by any security measure and can be easily generated by any attacker.
attacker. Properly configured tunnels should check the validity of Properly configured tunnels should check the validity of the inner
the inner packet and perform security checks. packet and perform security checks.
9. Acknowledgements 9. Acknowledgements
We would like to thank Brian Haberman, Dan Wing, Joel Halpern and the We would like to thank Brian Haberman, Dan Wing, Joel Halpern and the
IESG of 2012 for discussions and reviews. Gorry Fairhurst has been IESG of 2012 for discussions and reviews. Gorry Fairhurst has been
very diligent in reviewing and help ensuring alignment between this very diligent in reviewing and help ensuring alignment between this
document and [I-D.ietf-6man-udpzero]. document and [I-D.ietf-6man-udpzero].
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-6man-udpzero] [I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "Applicability Statement Fairhurst, G. and M. Westerlund, "Applicability Statement
for the use of IPv6 UDP Datagrams with Zero Checksums", for the use of IPv6 UDP Datagrams with Zero Checksums",
draft-ietf-6man-udpzero-07 (work in progress), draft-ietf-6man-udpzero-08 (work in progress),
October 2012. December 2012.
[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.
10.2. Informative References 10.2. Informative References
[I-D.ietf-lisp] [I-D.ietf-lisp]
 End of changes. 52 change blocks. 
211 lines changed or deleted 218 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/