Network Working Group                                         M. Eubanks
Internet-Draft                                        AmericaFree.TV LLC
Updates: 2460 (if approved)                                  P. Chimento
Intended status: Standards Track        Johns Hopkins University Applied
Expires: April 25, June 14, 2013                                Physics Laboratory
                                                           M. Westerlund
                                                                Ericsson
                                                        October 22,
                                                       December 11, 2012

              IPv6 and UDP Checksums for Tunneled Packets
                    draft-ietf-6man-udpchecksums-05
                    draft-ietf-6man-udpchecksums-06

Abstract

   This document provides an update of the Internet Protocol version 6
   (IPv6) specification (RFC2460) to improve the performance of IPv6 in the use
   case when a tunnel protocol uses UDP with IPv6 to tunnel packets.
   The performance improvement is obtained by relaxing the IPv6 UDP
   checksum requirement for suitable tunneling protocol where header
   information is protected on the "inner" packet being carried.  This
   relaxation removes the overhead associated with the computation of
   UDP checksums on IPv6 packets used to carry tunnel protocols and
   thereby improves the efficiency of the traversal of firewalls and
   other network middleboxes by such protocols.  We describe  The
   specification describes how the IPv6 UDP checksum requirement can be
   relaxed in for the situation where the encapsulated packet itself
   contains a checksum, the checksum.  The limitations and risks of this approach, approach are
   described, and define restrictions specified on the use of
   this relaxation to mitigate these risks. the method.

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 25, June 14, 2013.

Copyright Notice

   Copyright (c) 2012 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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Some Terminology . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Analysis of Corruption in Tunnel Context . . . . . . . . .  5
     4.2.  Limitation to Tunnel Protocols . . . . . . . . . . . . . .  7
     4.3.  Middleboxes  . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  The Zero-Checksum Update . . . . . . . . . . . . . . . . . . .  7  8
   6.  Additional Observations  . . . . . . . . . . . . . . . . . . .  8  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9 11
     10.2. Informative References . . . . . . . . . . . . . . . . . .  9 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 11

1.  Introduction

   This work constitutes an update of the Internet Protocol Version 6
   (IPv6) Specification [RFC2460], in the use case when a tunnel
   protocol uses UDP with IPv6 to tunnel packets.  With the rapid growth
   of the Internet, tunneling protocols have become increasingly
   important to enable the deployment of new protocols.  Tunneled
   protocols can be deployed rapidly, while the time to upgrade and
   deploy a critical mass of routers, switches middleboxes and end hosts on the
   global Internet for a new protocol is now measured in decades.  At
   the same time, the increasing use of firewalls and other security security-
   related middleboxes means that truly new tunnel protocols, with new
   protocol numbers, are also unlikely to be deployable in a reasonable
   time frame, which has resulted in an increasing interest in and use
   of UDP-based tunneling protocols.  In such protocols, there is an
   encapsulated "inner" packet, and the "outer" packet carrying the
   tunneled inner packet is a UDP packet, which can pass through
   firewalls and other middleboxes that perform filtering that is a fact
   of life on the current Internet.

   Tunnel endpoints may be routers or middleboxes aggregating traffic
   from a large number of tunnel users, therefore the computation of an
   additional checksum on the outer UDP packet, may be seen as an
   unwarranted burden on nodes that implement a tunneling protocol,
   especially if the inner packet(s) are already protected by a
   checksum.  In IPv4, there is a checksum on over the IP packet itself, header,
   and the checksum on the outer UDP packet can may be set to zero.  However
   in IPv6 there is not a no checksum on in the IP packet header and RFC 2460 [RFC2460]
   explicitly states that IPv6 receivers MUST discard UDP packets with a
   zero checksum.  So, while sending a UDP packet datagram with a zero checksum
   is permitted in IPv4 packets, it is explicitly forbidden in IPv6
   packets.  To improve support for IPv6 UDP tunnels, this document
   updates RFC 2460 to allow tunnel endpoints to use a zero UDP checksum under
   constrained situations (IPv6 (primarily IPv6 tunnel transports that carry
   checksum-protected packets), following the considerations applicability statements
   and constraints in [I-D.ietf-6man-udpzero].

   Unicast UDP Usage Guidelines for Application Designers [RFC5405]
   should be consulted when reading this specification.  It discusses
   both UDP tunnels (Section 3.1.3) and the usage of Checksums checksums (Section
   3.4).

   While the origin of this specification is the problem raised by the
   draft titled "Automatic IP Multicast Without Explicit Tunnels", also
   known as "AMT," [I-D.ietf-mboned-auto-multicast] we expect it to have
   wide applicability.  Since the first version of this document, the
   need for an efficient UDP tunneling mechanism has increased.  Other
   IETF Working Groups, notably LISP [I-D.ietf-lisp] and Softwires

   [RFC5619] have expressed a need to update the UDP checksum processing
   in RFC 2460.  We therefore expect this update to be applicable in
   future to other tunneling protocols specified by these and other IETF
   Working Groups.

2.  Some Terminology

   For the remainder of this document, we discuss

   This document discusses only IPv6, since this problem does not exist
   for IPv4.  Therefore all reference to 'IP' should be understood as a
   reference to IPv6.

   The document uses the terms "tunneling" and "tunneled" as adjectives
   when describing packets.  When we refer to 'tunneling packets' we
   refer to the outer packet header that provides the tunneling
   function.  When we refer to 'tunneled packets' we refer to the inner
   packet, i.e., the packet being carried in the tunnel.

2.1.  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].

3.  Problem Statement

   This document provides an update for the case where a

   When using tunnel protocol
   transports tunneled packets that already have a transport header with
   a checksum.  There is protocols based on UDP, there can be both a benefit
   and a cost to computing and checking the UDP checksum of the outer
   (encapsulating) UDP transport header.  In certain cases, where
   reducing the forwarding cost is important, such as for systems nodes that
   perform the check checksum in software, where the cost may outweigh the benefit; this
   benefit.  This document describes a means to
   avoid that cost.  In the case where there is provides an inner header update for usage of the UDP
   checksum with IPv6.  The update is specified for use by a tunnel
   protocol that transports packets that are themselves protected by a
   checksum.

4.  Discussion

   Applicability Statement for the use of IPv6 UDP Checksum Considerations Datagrams with Zero
   Checksums [I-D.ietf-6man-udpzero] describes
   the issues related to
   allowing UDP over IPv6 to have a valid checksum
   of zero UDP checksum and is not repeated here. the
   starting point for this discussion.  Section 5 4 and 6 5 of
   [I-D.ietf-6man-udpzero], identifies respectively identify node implementation
   and inner
   protocol usage requirements respectively that for datagrams sent and received with a zero
   UDP checksum.  These introduce constraints on the 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
   is still the possibility  The remainder of deep-inspection firewall devices or other
   middleboxes checking this section analyses
   the UDP checksum field use of the outer packet general tunnels and
   thereby discarding the tunneling packets.  This would be an issue
   also for any legacy IPv6 system that has not implemented this update motivates why tunnel protocols are
   being permitted to use the IPv6 specification.  In method described in this case, update.  Issues
   with middleboxes are also discussed.

4.1.  Analysis of Corruption in Tunnel Context

   This section analyzes the impact of the different corruption modes in
   the system (according context of a tunnel protocol.  It indicates what needs to
   RFC 2460) will discard be
   considered by the zero-checksum UDP packets, designer and should log
   this as an error.

   The points below discuss how path errors can user of a tunnel protocol to be detected and handled
   in an
   robust.  It also summarizes why use of a zero UDP tunneling protocol when the checksum protection is
   disabled.  Note that other (non-tunneling) protocols may have
   different approaches, but these are not the topic of this update.  We
   propose the following approach to handle this problem: thought
   safe for deployment.

   o  Context (i.e. tunneling state) should be established via by exchanging
      application Protocol Data Units (PDUs) that are carried in checksummed UDP packets.  That is, any control packets flowing
      between the tunnel endpoints should be protected
      datagrams or by UDP checksums.
      The other protocols with integrity protection against
      corruption.  These control packets can should also contain carry any
      negotiation required to enable the endpoint/adapters tunnel endpoint to accept UDP packets
      datagrams with a zero
      checksum.  The control packets may also carry any negotiation
      required to enable the endpoint/adapters to checksum and identify the set of ports that need
      are used.  It is important that the control traffic is robust
      against corruption because undetected errors can lead to enable reception of UDP long-
      lived and significant failures that affect not only the single
      packet that was corrupted.

   o  Keep-alive datagrams with a zero
      checksum.

   o  A system never sets the UDP checksum to zero in packets that do
      not contain tunneled packets.

   o  UDP keep-alive packets with checksum zero can be sent should be sent to
      validate
      paths, given that paths the network path, because the path between tunnel
      endpoints can change and so therefore the set of middleboxes in along
      the path may vary change during the life of the an association.  Paths with
      middleboxes that are intolerant of drop datagrams with a zero UDP checksum of zero will drop
      these keep-alives.  To enable the keep-alives and the tunnel endpoints will to discover that.  Note that and
      react to this need only be done per tunnel
      endpoint pair, not per tunnel context.  Keep-alive behavior in a timely way, the keep-alive traffic can
      should include both packets datagrams with tunnel checksums both a non-zero checksum and packets ones
      with
      checksums equal to a zero to enable the remote end to distinguish
      between path failures and the blockage of packets with checksum
      equal to zero. checksum.

   o  Corruption of the address information in an encapsulating packets,
      i.e.  IPv6 source address, destination address and/or the UDP
      source port, and destination port fields :
      If the restrictions in [I-D.ietf-6man-udpzero] are followed, fields.  A robust tunnel
      protocol should track tunnel context based on the
      inner packets (tunneled packets) will be protected and run 5-tuple, i.e.
      the
      usual (presumably small) risk of having undetected corruption(s).
      If tunneling protocol contexts contain (at a minimum) source and
      destination IP addresses both the address and port for both the source and destination ports, there
      are 16 possible corruption outcomes.  We note
      destination.  A corrupted datagram that these outcomes
      are not equally likely.  The possible corruption outcomes may be:

      *  Half of the 16 possible corruption combinations have arrives at a
         corrupted destination address.
      may be filtered based on this check.

      *  If the incorrect destination is
         reached and datagram header matches the node doesn't have an application for 5-tuple with a zero checksum
         enabled, the
         destination port, payload is matched to the wrong context.  The
         tunneled packet will then be dropped.  If decapsulated and forwarded by the
         application at
         tunnel egress.

      *  If a corrupted datagram matches a different 5-tuple with a zero
         checksum enabled, the incorrect destination payload is matched to the same tunneling
         protocol wrong context,
         and may be processed by the wrong tunneling protocol, if it has
         passes the verification of that protocol.

      *  If a matching context (which can be assumed
         to be corrupted datagram matches a very low probability event) the inner packet 5-tuple that does not have a
         zero checksum enabled, it will be
         decapsulated and forwarded.  Application developers can verify discarded.

      When only the context of source information is corrupted, the packets they receive using UDP, as described
         in [RFC5405].  Applications that verify the context of a datagram are expected to have a high probability of discarding
         corrupted data.  [I-D.ietf-6man-udpzero] presents examples of
         cases where corruption can inadvertently impact application
         state.

      *  Half of could
      arrive at the 8 possible corruption combinations with a correct
         destination address have a corrupted source address. intended applications/protocol which will process it
      and try to match it against an existing tunnel context.  If the
         tunnel contexts contain all elements of
      protocol restricts processing to only the address-port
         4-tuple, then source addresses with
      established contexts the likelihood is that this corruption will be
         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 a corrupted packet enters
      a valid context is reduced.  When both source and destination IPv6 addresses, one has all 4
      fields valid, are corrupted, this increases the
         other three have one or both ports corrupted.  Again, if likelihood of failing to
      match a context, with the
         tunneling endpoint context contains sufficient information,
         these exception of errors should be detected replacing one packet
      header with high probability. another one.  In this case it is possible that both
      are tunnels and thus the corrupted packet can match a previously
      defined context.

   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 may
      reassemble fragments associated with a context at the wrong tunnel
      endpoint, or corrupted fragments may be reassembled at the right
      context at the right tunnel endpoint.  In each of these cases, the
      IPv6 length of the encapsulating header may be checked (though
      [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).

   o  Tunnel protocols using UDP have some advantages that reduce the
      risk for a corrupted tunnel packet reaching a destination that
      will receive it, compared to other applications.  This results
      from processing by the network of the inner (tunneled) packet
      after being forwarded from the tunnel egress using a wrong
      context:

      *  A tunneled packet may be forwarded to the wrong address domain,
         for example a private address domain where the inner packet's
         address is not routable, or may fail a source address check,
         such as Unicast Reverse Path Forwarding [RFC2827], resulting in
         the packet being dropped.

      *  The destination address of a tunneled packet may not at all be
         reachable from the delivered domain.  For example an Ethernet
         packet where the destination MAC address is not present on the
         LAN segment that was reached.

      *  The type of the tunneled packet may prevent delivery for
         example if an IP packet payload was attempted to be interpreted
         as an Ethernet packet.  This is likely to result in the packet
         being dropped as invalid.

      *  The tunneled packet checksum or integrity mechanism may detect
         corruption of the inner packet caused at the same time as
         corruption to the outer packet header.  The resulting packet
         would likely be dropped as invalid.

   These different examples each help to significantly reduce the
   likelihood that a corrupted inner tunneled packet is finally
   delivered to a protocol listener that can be affected by the packet.
   While the methods do not guarantee correctness, they can reduce the
   risk of relaxing the UDP checksum requirement for a tunnel
   application using IPv6.

4.2.  Limitation to Tunnel Protocols

   This document describes the applicability of using a zero UDP
   checksum to support tunnel protocols.  There are good motivations
   behind this and the arguments are provided here.

   o  Tunnels carry inner packets that have their own semantics that
      makes any corruption less likely to reach the indicated
      destination and be accepted as a valid packet.  This is true for
      IP packets with the addition of verification that can be made by
      the tunnel protocol, the networks' processing 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
      similar effects that reduce the likelihood that an mis-delivered
      packet are delivered.

   o  Protocols that directly consume the payload must have sufficient
      robustness against mis-delivered packets from any context,
      including the ones that are corrupted in tunnels and any other
      usage of the zero checksum.  This will require an integrity
      mechanism.  Using a standard UDP checksum reduces the
      computational load in the receiver to verify this mechanism.

   o  Stateful protocols or protocols where corruption causes cascade
      effects need to be extra careful.  In tunnel usage each
      encapsulating packet provides only a transport mechanism from
      tunnel ingress to tunnel egress.  A corruption will commonly only
      effect the single packet, not established protocol state.  One
      common effect is that the inner packet flow will only see a
      corruption and mis-delivery of the outer packet as a lost packet.

   o  Some non-tunnel protocols operate with general servers that do not
      know from where they will receive a packet.  In such applications,
      the usage of a zero UDP checksum is especially unsuitable because
      there is a need to provide the first level of verification that
      the packet was intended for the server.  This verification
      prevents the server from processing the datagram payload and spend
      any significant amount of resources on it, including sending
      replies or error messages.

   Tunnel protocols encapsulating IP this will generally be safe, since
   all IPv4 and IPv6 packets include at least one checksum at either the
   network or transport layer and the network delivery of the inner
   packet will further reduce the effects of corruption.  Tunnel
   protocols carrying non-IP packets may provide equivalent protection
   due to the non-IP networks reducing the risk of delivery to
   applications.  However, there is need for further analysis to
   understand the implications of mis-delievery of corrupted packets for
   that each non-IP protocol.  The analysis above suggests that non-
   tunnel protocols can be expected to have significantly more cases
   where a zero checksum would result in mis-delivery or negative side-
   effects.

   One unfortunate side-effect of increased use of a zero-checksum is
   that it also increases the likelihood of acceptance when a datagram
   with a context at the wrong zero UDP checksum is mis-delivered.  This requires all tunnel
      endpoint, or corrupted fragments may
   protocols using this method to be reassembled at the right
      context at designed to be robust to mis-
   delivery.

4.3.  Middleboxes

   Applicability Statement for the right tunnel endpoint.  In each use of these cases, the IPv6 length of the encapsulating header may be checked (though UDP Datagrams with Zero
   Checksums [I-D.ietf-6man-udpzero] points out the weakness in notes that middlebox devices that
   conform to RFC 2460 will discard datagrams with a zero UDP checksum
   and should log this check).
      In addition, if the encapsulated packet is protected by as an error.  Thus tunnel protocols intending to
   use a
      transport (or other) checksum, these errors can be detected (with
      some probability).

   While zero UDP checksum needs to ensure that they do not guarantee correctness, these mechanism can reduce have defined a
   method for handling cases when a middlebox prevents the risks of relaxing path between
   the tunnel ingress and egress from supporting transmission of
   datagrams with a zero UDP checksum requirement for IPv6. checksum.

5.  The Zero-Checksum Update

   This specification updates IPv6 to allow a zero UDP checksum of zero for in the
   outer encapsulating packet datagram of a tunneling protocol.  UDP endpoints
   that implement this update MUST change their behavior for
   any destination port explicitly configured for zero checksum and MUST
   NOT discard UDP packets received with a checksum value of zero on follow the
   outer packet.  When this is done, it requires node requirements
   "Applicability Statement for the constraints in
   Section 5 and 6 use of IPv6 UDP Datagrams with Zero
   Checksums" [I-D.ietf-6man-udpzero].

   Specifically, the

   The following text in [RFC2460] Section 8.1, 4th bullet is
   updated.  We refer to the following text: should be
   deleted:

   "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 zero checksum, and
   should log the error."

   This text should be replaced by:

      Whenever originating a UDP packet, packet in the default mode, an IPv6
      node SHOULD MUST compute a UDP checksum over the packet and the pseudo-header, pseudo-
      header, and, if that computation yields a result of zero, it must MUST
      be changed to hex FFFF for placement in the UDP header.  IPv6
      receivers SHOULD MUST by default discard UDP packets containing a zero
      checksum, and SHOULD log the error.  However,  As an alternative usage for
      some protocols, such as tunneling protocols that use UDP as a tunnel
      encapsulation, MAY omit computing enable the UDP
      checksum zero-checksum mode for specific sets
      of ports.  Any node implementing the encapsulating UDP header and set it to zero,
      subject to zero-checksum mode MUST
      follow the constraints described node requirements specified in Section 4 of
      Applicability Statement for the use of IPv6 UDP Datagrams with
      Zero Checksums [I-D.ietf-6man-udpzero].  In cases where the encapsulating

      Any protocol uses a zero checksum for UDP, using the receiver of packets
      sent to a port enabled to receive zero-checksum packets mode MUST NOT
      discard packets solely for having a UDP checksum of zero.  Note
      that these constraints apply only to encapsulating protocols that
      omit calculating the UDP checksum and set it to zero.  An
      encapsulating protocol can always choose to compute the UDP
      checksum, in which case, its behavior is not updated and uses follow the
      method usage
      requirements specified in Section 8.1 of RFC2460.

      Middleboxes MUST allow IPv6 packets with UDP checksum equal to
      zero to pass.  Implementations of middleboxes MAY allow
      configuration 5 of specific port ranges Applicability Statement for which a zero UDP
      checksum is valid and may drop IPv6 UDP packets outside those
      ranges.

      The path between tunnel endpoints can change, thus also the
      middleboxes in the path may vary during the life of
      the
      association.  Paths with middleboxes that are intolerant use of a IPv6 UDP
      checksum of zero will drop any keep-alives sent to validate the
      path using checksum zero and the endpoints will discover that.
      Therefore keep-alive traffic SHOULD include both packets with
      tunnel checksums and packets Datagrams with checksums equal to zero to
      enable Zero Checksums
      [I-D.ietf-6man-udpzero].

      Middleboxes supporting IPv6 MUST follow the remote end to distinguish between path failures requirements 9, 10 and the
      blockage
      11 of packets with checksum equal to zero.  Note that path
      validation need only be done per tunnel endpoint pair, not per
      tunnel context. 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

   The

   This update was motivated by the existence of this issue among a significant number of protocols
   being developed in the IETF motivates this specified change.  The
   authors would also like that are expected to make benefit from the
   change.  The following observations: observations are made:

   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  At the time of publication, it
      is now 2012.  We strongly suggest that an a new empirical study is in order, study, along
      with an extensive analysis of IPv6 header the corruption probabilities. probabilities of the
      IPv6 header.

   o  A key cause to motivation for the increased usage increase in use of UDP in tunneling is the a
      lack of protocol support in middleboxes.  Specifically, new
      protocols, such as LISP [I-D.ietf-lisp], may prefer to use UDP
      tunnels to traverse an end-to-end path successfully and avoid
      having their packets dropped by middleboxes.  If this middleboxes were not the case, the
      use
      updated to support UDP-Lite [RFC3828], this would provide better
      protection than offered by this update.  This may be suited to a
      variety of UDP-lite [RFC3828] might become more viable applications and would be expected to be preferred over
      this method for some (but
      not necessarily all) tunneling many tunnel protocols.

   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
      checksum for TCP flows).  Protocols that do not use a pseudo-
      header approach to computing a checksum or CRC have essentially no
      protection from mis-delivered packets.

7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

8.  Security Considerations

   It requires less

   Less work is required required to generate zero-checksum an attack packets using a zero UDP
   checksum than
   ones with one using a standard full UDP checksums. checksum.  However, this
   does not lead to any significant new vulnerabilities as because checksums
   are not a security measure and can be easily generated by any
   attacker.  Properly configured tunnels should check the validity of
   the inner packet and perform any needed security checks, regardless of the checksum
   status.  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). checks.

9.  Acknowledgements

   We would like to thank Brian Haberman Haberman, Dan Wing, Joel Halpern and Gorry Fairhurst the
   IESG of 2012 for discussions and reviews.  Gorry Fairhurst has been
   very diligent in reviewing and help ensuring alignment between this
   document and [I-D.ietf-6man-udpzero].

10.  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
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

10.2.  Informative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-23
              draft-ietf-lisp-24 (work in progress), May November 2012.

   [I-D.ietf-mboned-auto-multicast]
              Bumgardner, G., "Automatic Multicast Tunneling",
              draft-ietf-mboned-auto-multicast-14 (work in progress),
              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.

   [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.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405,
              November 2008.

   [RFC5619]  Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
              "Softwire Security Analysis and Requirements", RFC 5619,
              August 2009.

Authors' Addresses

   Marshall Eubanks
   AmericaFree.TV LLC
   P.O. Box 141
   Clifton, Virginia  20124
   USA

   Phone: +1-703-501-4376
   Fax:
   Email: marshall.eubanks@gmail.com

   P.F. Chimento
   Johns Hopkins University Applied Physics Laboratory
   11100 Johns Hopkins Road
   Laurel, MD  20723
   USA

   Phone: +1-443-778-1743
   Email: Philip.Chimento@jhuapl.edu

   Magnus Westerlund
   Ericsson
   Farogatan 6
   SE-164 80 Kista
   Sweden

   Phone: +46 10 714 82 87
   Email: magnus.westerlund@ericsson.com