draft-ietf-6man-udpchecksums-04.txt   draft-ietf-6man-udpchecksums-05.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: March 9, 2013 Physics Laboratory Expires: April 25, 2013 Physics Laboratory
M. Westerlund M. Westerlund
Ericsson Ericsson
September 5, 2012 October 22, 2012
UDP Checksums for Tunneled Packets UDP Checksums for Tunneled Packets
draft-ietf-6man-udpchecksums-04 draft-ietf-6man-udpchecksums-05
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 of IPv6 in (IPv6) specification (RFC2460) to improve the performance of IPv6 in
the use case when a tunnel protocol uses UDP with IPv6 to tunnel the use case when a tunnel protocol uses UDP with IPv6 to tunnel
packets. The performance improvement is obtained by relaxing the packets. The performance improvement is obtained by relaxing the
IPv6 UDP checksum requirement for suitable tunneling protocol where IPv6 UDP checksum requirement for suitable tunneling protocol where
header information is protected on the "inner" packet being carried. header information is protected on the "inner" packet being carried.
This relaxation removes the overhead associated with the computation This relaxation removes the overhead associated with the computation
of UDP checksums on IPv6 packets used to carry tunnel protocols and of UDP checksums on IPv6 packets used to carry tunnel protocols and
thereby improves the efficiency of the traversal of firewalls and thereby improves the efficiency of the traversal of firewalls and
other network middleboxes by such protocols. We describe how the other network middleboxes by such protocols. We describe how the
IPv6 UDP checksum requirement can be relaxed in the situation where IPv6 UDP checksum requirement can be relaxed in the situation where
the encapsulated packet itself contains a checksum, the limitations the encapsulated packet itself contains a checksum, the limitations
and risks of this approach, and defines restrictions on the use of and risks of this approach, and define restrictions on the use of
this relaxation to mitigate these risks. this relaxation to mitigate these risks.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 9, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 6 5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 7
6. Additional Observations . . . . . . . . . . . . . . . . . . . 9 6. Additional Observations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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 when 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, tunneling protocols have become increasingly
important to enable the deployment of new protocols. Tunneled important to enable the deployment of new protocols. Tunneled
protocols can be deployed rapidly, while the time to upgrade and protocols can be deployed rapidly, while the time to upgrade and
deploy a critical mass of routers, switches and end hosts on the deploy a critical mass of routers, switches and end hosts on the
skipping to change at page 4, line 20 skipping to change at page 4, line 20
2. Some Terminology 2. Some Terminology
For the remainder of this document, we discuss only IPv6, since this For the remainder of this document, we discuss only IPv6, since this
problem does not exist for IPv4. Therefore all reference to 'IP' problem does not exist for IPv4. Therefore all reference to 'IP'
should be understood as a reference to IPv6. should be understood as a 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
function. When we refer to 'tunneled packets' we refer to the inner function. When we refer to 'tunneled packets' we refer to the inner
packet, i.e. the packet being carried in the tunnel. packet, i.e., the packet being carried in the tunnel.
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
This document provides an update for the case where a tunnel protocol This document provides an update for the case where a tunnel protocol
transports tunnelled packets that already have a UDP header with a transports tunneled packets that already have a transport header with
checksum, there is both a benefit and a cost to compute and check the a checksum. There is both a benefit and a cost to computing and
UDP checksum of the outer (encapsulating) UDP transport header. In checking the UDP checksum of the outer (encapsulating) UDP transport
certain cases, where reducing the forwarding cost is important, such header. In certain cases, where reducing the forwarding cost is
as for systems that perform the check in software, the cost may important, such as for systems that perform the check in software,
outweigh the benefit; this document describes a means to avoid that the cost may outweigh the benefit; this document describes a means to
cost, in the case where there is an inner header with a checksum. avoid that cost. In the case where there is an inner header with a
checksum.
4. Discussion 4. Discussion
IPv6 UDP Checksum Considerations [I-D.ietf-6man-udpzero] describes IPv6 UDP Checksum Considerations [I-D.ietf-6man-udpzero] describes
the issues related to allowing UDP over IPv6 to have a valid checksum the issues related to allowing UDP over IPv6 to have a valid checksum
of zero and is not repeated here. of zero and is not repeated here.
Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements Section 5 and 6 of [I-D.ietf-6man-udpzero], identifies node and inner
that introduce constraints on the usage of a zero checksum for UDP protocol requirements respectively that introduce constraints on the
over IPv6. This document is intended to satisfy these requirements. usage of a zero checksum for UDP over IPv6. This document is
intended to satisfy these requirements.
[I-D.ietf-6man-udpzero] and mailing list discussions have noted there [I-D.ietf-6man-udpzero] and mailing list discussions have noted there
is still the possibility of deep-inspection firewall devices or other is still the possibility of deep-inspection firewall devices or other
middleboxes checking the UDP checksum field of the outer packet and middleboxes checking the UDP checksum field of the outer packet and
thereby discarding the tunneling packets. This would be an issue thereby discarding the tunneling packets. This would be an issue
also for any legacy IPv6 system that has not implemented this update also for any legacy IPv6 system that has not implemented this update
to the IPv6 specification. In this case, the system (according to to the IPv6 specification. In this case, the system (according to
RFC 2460) will discard the zero-checksum UDP packets, and should log RFC 2460) will discard the zero-checksum UDP packets, and should log
this as an error. this as an error.
The below discuss how path errors can be detected and handled in an The points below discuss how path errors can be detected and handled
UDP tunneling protocol when the checksum protection is disabled. in an UDP tunneling protocol when the checksum protection is
Note that other (non-tunneling) protocols may have different disabled. Note that other (non-tunneling) protocols may have
approaches, but these are not the topic of this update. We propose different approaches, but these are not the topic of this update. We
the following approach to handle this problem: propose the following approach to handle this problem:
o Context (i.e. tunneling state) should be established via o Context (i.e. tunneling state) should be established via
application Protocol Data Units (PDUs) that are carried in application Protocol Data Units (PDUs) that are carried in
checksummed UDP packets. That is, any control packets flowing checksummed UDP packets. That is, any control packets flowing
between the tunnel endpoints should be protected by UDP checksums. between the tunnel endpoints should be protected by UDP checksums.
The control packets can also contain any negotiation required to The control packets can also contain any negotiation required to
enable the endpoint/adapters to accept UDP packets with a zero enable the endpoint/adapters to accept UDP packets with a zero
checksum. The control packets may also carry any negotiation checksum. The control packets may also carry any negotiation
required to enable the endpoint/adapters to identify the set of required to enable the endpoint/adapters to identify the set of
ports that need to enable reception UDP datagrams with a zero ports that need to enable reception of UDP datagrams with a zero
checksum. checksum.
o A system shall not set the UDP checksum to zero in packets that do o A system never sets the UDP checksum to zero in packets that do
not contain tunneled packets. not contain tunneled packets.
o UDP keep-alive packets with checksum zero can be sent to validate o UDP keep-alive packets with checksum zero can be sent to validate
paths, given that paths between tunnel endpoints can change and so paths, given that paths between tunnel endpoints can change and so
middleboxes in the path may vary during the life of the middleboxes in the path may vary during the life of the
association. Paths with middleboxes that are intolerant of a UDP association. Paths with middleboxes that are intolerant of a UDP
checksum of zero will drop the keep-alives and the endpoints will checksum of zero will drop the keep-alives and the endpoints will
discover that. Note that this need only be done per tunnel discover that. Note that this need only be done per tunnel
endpoint pair, not per tunnel context. Keep-alive traffic should endpoint pair, not per tunnel context. Keep-alive traffic can
include both packets with tunnel checksums and packets with include both packets with tunnel checksums and packets with
checksums equal to zero to enable the remote end to distinguish checksums equal to zero to enable the remote end to distinguish
between path failures and the blockage of packets with checksum between path failures and the blockage of packets with checksum
equal to zero. equal to zero.
o Corruption of the encapsulating IPv6 source address, destination o Corruption of the encapsulating IPv6 source address, destination
address and/or the UDP source port, destination port fields : If address and/or the UDP source port, and destination port fields :
the 9 restrictions in [I-D.ietf-6man-udpzero] are followed, the If the restrictions in [I-D.ietf-6man-udpzero] are followed, the
inner packets (tunneled packets) should be protected and run the inner packets (tunneled packets) will be protected and run the
usual (presumably small) risk of having undetected corruption(s). usual (presumably small) risk of having undetected corruption(s).
If tunneling protocol contexts contain (at a minimum) source and If tunneling protocol contexts contain (at a minimum) source and
destination IP addresses and source and destination ports, there destination IP addresses and source and destination ports, there
are 16 possible corruption outcomes. We note that these outcomes are 16 possible corruption outcomes. We note that these outcomes
are not equally likely. The possible corruption outcomes may be: are not equally likely. The possible corruption outcomes may be:
* Half of the 16 possible corruption combinations have a * Half of the 16 possible corruption combinations have a
corrupted destination address. If the incorrect destination is corrupted destination address. If the incorrect destination is
reached and the node doesn't have an application for the reached and the node doesn't have an application for the
destination port, the packet will be dropped. If the destination port, the packet will be dropped. If the
application at the incorrect destination is the same tunneling application at the incorrect destination is the same tunneling
protocol and if it has a matching context (which can be assumed protocol and if it has a matching context (which can be assumed
to be a very low probability event) the inner packet will be to be a very low probability event) the inner packet will be
decapsulated and forwarded. Application developers should decapsulated and forwarded. Application developers can verify
verify the context of the packets they receive using UDP, as the context of the packets they receive using UDP, as described
described in [RFC5405]. Applications that verify the context in [RFC5405]. Applications that verify the context of a
of a datagram are expected to have a high probability of datagram are expected to have a high probability of discarding
discarding corrupted data. [I-D.ietf-6man-udpzero] presents corrupted data. [I-D.ietf-6man-udpzero] presents examples of
examples of cases where corruption can inadvertently impact cases where corruption can inadvertently impact application
application state. state.
* Half of the 8 possible corruption combinations with a correct * Half of the 8 possible corruption combinations with a correct
destination address have a corrupted source address. If the destination address have a corrupted source address. If the
tunnel contexts contain all elements of the address-port tunnel contexts contain all elements of the address-port
4-tuple, then the likelihood is that this corruption will be 4-tuple, then the likelihood is that this corruption will be
detected. detected. It may in fact be discarded on route due to source
address validation techniques, such as Unicast Reverse Path
Forwarding [RFC2827].
* Of the remaining 4 possibilities, with valid source and * Of the remaining 4 possibilities, with valid source and
destination IPv6 addresses, 1 has all 4 fields valid, the other destination IPv6 addresses, one has all 4 fields valid, the
three have one or both ports corrupted. Again, if the other three have one or both ports corrupted. Again, if the
tunneling endpoint context contains sufficient information, tunneling endpoint context contains sufficient information,
these error should be detected with high probability. these errors should be detected with high probability.
o Corruption of source-fragmented encapsulating packets: In this o Corruption of source-fragmented encapsulating packets: In this
case, a tunneling protocol may reassemble fragments associated case, a tunneling protocol may reassemble fragments associated
with the wrong context at the right tunnel endpoint, or it may with the wrong context at the right tunnel endpoint, or it may
reassemble fragments associated with a context at the wrong tunnel reassemble fragments associated with a context at the wrong tunnel
endpoint, or corrupted fragments may be reassembled at the right endpoint, or corrupted fragments may be reassembled at the right
context at the right tunnel endpoint. In each of these cases, the context at the right tunnel endpoint. In each of these cases, the
IPv6 length of the encapsulating header may be checked (though IPv6 length of the encapsulating header may be checked (though
[I-D.ietf-6man-udpzero] points out the weakness in this check). [I-D.ietf-6man-udpzero] points out the weakness in this check).
In addition, if the encapsulated packet is protected by a In addition, if the encapsulated packet is protected by a
skipping to change at page 7, line 6 skipping to change at page 7, line 10
some probability). some probability).
While they do not guarantee correctness, these mechanism can reduce While they do not guarantee correctness, these mechanism can reduce
the risks of relaxing the UDP checksum requirement for IPv6. the risks of relaxing the UDP checksum requirement for IPv6.
5. The Zero-Checksum Update 5. The Zero-Checksum Update
This specification updates IPv6 to allow a UDP checksum of zero for This specification updates IPv6 to allow a UDP checksum of zero for
the outer encapsulating packet of a tunneling protocol. UDP the outer encapsulating packet of a tunneling protocol. UDP
endpoints that implement this update MUST change their behavior for endpoints that implement this update MUST change their behavior for
any destination port explicitly configured for zero checksum and not any destination port explicitly configured for zero checksum and MUST
discard UDP packets received with a checksum value of zero on the NOT discard UDP packets received with a checksum value of zero on the
outer packet. When this is done, it requires the constraints in outer packet. When this is done, it requires the constraints in
Section 5.1 of [I-D.ietf-6man-udpzero]. Section 5 and 6 of [I-D.ietf-6man-udpzero].
Specifically, the text in [RFC2460] Section 8.1, 4th bullet is Specifically, the text in [RFC2460] Section 8.1, 4th bullet is
updated. We refer to the following text: updated. We refer to the following text:
"Unlike IPv4, when UDP packets are originated by an IPv6 node, the "Unlike IPv4, when UDP packets are originated by an IPv6 node, the
UDP checksum is not optional. That is, whenever originating a UDP UDP checksum is not optional. That is, whenever originating a UDP
packet, an IPv6 node must compute a UDP checksum over the packet and packet, an IPv6 node must compute a UDP checksum over the packet and
the pseudo-header, and, if that computation yields a result of zero, the pseudo-header, and, if that computation yields a result of zero,
it must be changed to hex FFFF for placement in the UDP header. IPv6 it must be changed to hex FFFF for placement in the UDP header. IPv6
receivers must discard UDP packets containing a zero checksum, and receivers must discard UDP packets containing a zero checksum, and
skipping to change at page 7, line 33 skipping to change at page 7, line 37
replaced by: replaced by:
Whenever originating a UDP packet, an IPv6 node SHOULD compute a Whenever originating a UDP packet, an IPv6 node SHOULD compute a
UDP checksum over the packet and the pseudo-header, and, if that UDP checksum over the packet and the pseudo-header, and, if that
computation yields a result of zero, it must be changed to hex computation yields a result of zero, it must be changed to hex
FFFF for placement in the UDP header. IPv6 receivers SHOULD FFFF for placement in the UDP header. IPv6 receivers SHOULD
discard UDP packets containing a zero checksum, and SHOULD log the discard UDP packets containing a zero checksum, and SHOULD log the
error. However, some protocols, such as tunneling protocols that error. However, some protocols, such as tunneling protocols that
use UDP as a tunnel encapsulation, MAY omit computing the UDP use UDP as a tunnel encapsulation, MAY omit computing the UDP
checksum of the encapsulating UDP header and set it to zero, checksum of the encapsulating UDP header and set it to zero,
subject to the constraints described in RFCXXXX. In cases where subject to the constraints described in Applicability Statement
the encapsulating protocol uses a zero checksum for UDP, the for the use of IPv6 UDP Datagrams with Zero Checksums
receiver of packets sent to a port enabled to receive zero- [I-D.ietf-6man-udpzero]. In cases where the encapsulating
checksum packets MUST NOT discard packets solely for having a UDP protocol uses a zero checksum for UDP, the receiver of packets
checksum of zero. Note that these constraints apply only to sent to a port enabled to receive zero-checksum packets MUST NOT
encapsulating protocols that omit calculating the UDP checksum and discard packets solely for having a UDP checksum of zero. Note
set it to zero. An encapsulating protocol can always choose to that these constraints apply only to encapsulating protocols that
compute the UDP checksum, in which case, its behavior is not omit calculating the UDP checksum and set it to zero. An
updated and uses the method specified in RFC2460. encapsulating protocol can always choose to compute the UDP
checksum, in which case, its behavior is not updated and uses the
1. IPv6 protocol stack implementations SHOULD NOT by default method specified in Section 8.1 of RFC2460.
allow the new method. The default node receiver behavior 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. 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).
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 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.
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
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 Middleboxes MUST allow IPv6 packets with UDP checksum equal to
zero to pass. Implementations of middleboxes MAY allow zero to pass. Implementations of middleboxes MAY allow
configuration of specific port ranges for which a zero UDP configuration of specific port ranges for which a zero UDP
checksum is valid and may drop IPv6 UDP packets outside those checksum is valid and may drop IPv6 UDP packets outside those
ranges. ranges.
The path between tunnel endpoints can change, thus also the The path between tunnel endpoints can change, thus also the
middleboxes in the path may vary during the life of the middleboxes in the path may vary during the life of the
association. Paths with middleboxes that are intolerant of a UDP association. Paths with middleboxes that are intolerant of a UDP
checksum of zero will drop any keep-alives sent to validate the checksum of zero will drop any keep-alives sent to validate the
path using checksum zero and the endpoints will discover that. path using checksum zero and the endpoints will discover that.
Therefore keep-alive traffic SHOULD include both packets with Therefore keep-alive traffic SHOULD include both packets with
tunnel checksums and packets with checksums equal to zero to tunnel checksums and packets with checksums equal to zero to
enable the remote end to distinguish between path failures and the enable the remote end to distinguish between path failures and the
blockage of packets with checksum equal to zero. Note that path blockage of packets with checksum equal to zero. Note that path
validation need only be done per tunnel endpoint pair, not per validation need only be done per tunnel endpoint pair, not per
tunnel context. tunnel context.
RFC-Editor Note: Please replace RFCXXXX above with the RFC number
this specification receives and remove this note.
6. Additional Observations 6. Additional Observations
The existence of this issue among a significant number of protocols The existence of this issue among a significant number of protocols
being developed in the IETF motivates this specified change. The being developed in the IETF motivates this specified change. The
authors would also like to make the following observations: authors would also like to make the following observations:
o An empirically-based analysis of the probabilities of packet o An empirically-based analysis of the probabilities of packet
corruptions (with or without checksums) has not (to our knowledge) corruptions (with or without checksums) has not (to our knowledge)
been conducted since about 2000. It is now 2012. We strongly been conducted since about 2000. It is now 2012. We strongly
suggest that an empirical study is in order, along with an suggest that an empirical study is in order, along with an
skipping to change at page 10, line 23 skipping to change at page 9, line 10
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
It requires less work to generate zero-checksum attack packets than It requires less work to generate zero-checksum attack packets than
ones with full UDP checksums. However, this does not lead to any ones with full UDP checksums. However, this does not lead to any
significant new vulnerabilities as checksums are not a security significant new vulnerabilities as checksums are not a security
measure and can be easily generated by any attacker, as properly measure and can be easily generated by any attacker. Properly
configured tunnels should check the validity of the inner packet and configured tunnels should check the validity of the inner packet and
perform any needed security checks, regardless of the checksum perform any needed security checks, regardless of the checksum
status, and finally as most attacks are generated from compromised status. Most attacks are generated from compromised hosts which
hosts which automatically create checksummed packets (in other words, automatically create checksummed packets (in other words, it would
it would generally be more, not less, effort for most attackers to generally be more, not less, effort for most attackers to generate
generate zero UDP checksums on the host). zero UDP checksums on the host).
9. Acknowledgements 9. Acknowledgements
We would like to thank Brian Haberman and Gorry Fairhurst for We would like to thank Brian Haberman and Gorry Fairhurst for
discussions and reviews. discussions and reviews.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "Applicability Statement
for the use of IPv6 UDP Datagrams with Zero Checksums",
draft-ietf-6man-udpzero-07 (work in progress),
October 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.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004. (UDP-Lite)", RFC 3828, July 2004.
[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent, [RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
"Softwire Security Analysis and Requirements", RFC 5619, "Softwire Security Analysis and Requirements", RFC 5619,
August 2009. August 2009.
10.2. Informative References 10.2. Informative References
[I-D.ietf-6man-udpzero]
Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
Considerations", draft-ietf-6man-udpzero-06 (work in
progress), June 2012.
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-23 (work in progress), May 2012. draft-ietf-lisp-23 (work in progress), May 2012.
[I-D.ietf-mboned-auto-multicast] [I-D.ietf-mboned-auto-multicast]
Bumgardner, G., "Automatic Multicast Tunneling", Bumgardner, G., "Automatic Multicast Tunneling",
draft-ietf-mboned-auto-multicast-14 (work in progress), draft-ietf-mboned-auto-multicast-14 (work in progress),
June 2012. June 2012.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, for Application Designers", BCP 145, RFC 5405,
November 2008. November 2008.
Authors' Addresses Authors' Addresses
Marshall Eubanks Marshall Eubanks
AmericaFree.TV LLC AmericaFree.TV LLC
P.O. Box 141 P.O. Box 141
Clifton, Virginia 20124 Clifton, Virginia 20124
skipping to change at page 12, line 4 skipping to change at page 10, line 31
Marshall Eubanks Marshall Eubanks
AmericaFree.TV LLC AmericaFree.TV LLC
P.O. Box 141 P.O. Box 141
Clifton, Virginia 20124 Clifton, Virginia 20124
USA USA
Phone: +1-703-501-4376 Phone: +1-703-501-4376
Fax: Fax:
Email: marshall.eubanks@gmail.com Email: marshall.eubanks@gmail.com
P.F. Chimento P.F. Chimento
Johns Hopkins University Applied Physics Laboratory Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723 Laurel, MD 20723
USA USA
Phone: +1-443-778-1743 Phone: +1-443-778-1743
Fax:
Email: Philip.Chimento@jhuapl.edu Email: Philip.Chimento@jhuapl.edu
URI:
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 30 change blocks. 
135 lines changed or deleted 81 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/