[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                             G. Fairhurst
Internet-Draft                                                  T. Jones
Intended status: Standards Track                                R. Zullo
Expires: April 22, 2019                           University of Aberdeen
                                                        October 19, 2018


             Checksum Compensation Options for UDP Options
                 draft-fairhurst-udp-options-cco-00.txt

Abstract

   This document describes a robust method for calculating checksums for
   use with UDP Options.  The new method proposes an alternative
   checksum calculation for coverage of the option space.  This is based
   on the IP checksum calculation, but uses an updated pseudoheader.
   The new method only checks the option portion of a UDP packet, but
   creates a checksum that compensates for the range of IP and UDP
   chekcsum validation methods that have been deployed, in this way the
   new method enhances the proability of NAPT traversal for packets that
   carry UDP-Options.

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 https://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 22, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Fairhurst, et al.        Expires April 22, 2019                 [Page 1]


Internet-Draft                  UDPO CCO                    October 2018


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Middlebox Pathologies . . . . . . . . . . . . . . . . . . . .   3
   4.  Checksum Compensation Option  . . . . . . . . . . . . . . . .   4
     4.1.  Calculating the CCO . . . . . . . . . . . . . . . . . . .   6
     4.2.  Validating CCO  . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  CCO Calculation Examples  . . . . . . . . . . . . . . . .   8
     4.4.  Interaction with other UDP Options  . . . . . . . . . . .   9
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Revision Notes . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   UDP Options [I-D.ietf-tsvwg-udp-options] adds support for transport
   options in UDP [RFC0768].  When UDP is carried in IP two length
   fields describe the UDP datagram, the IP transport carries a payload
   length and the UDP header carries the length of the UDP datagram.  In
   most datagrams currently forwarded by network devices the IP payload
   length is equal to the UDP length, UDP Options
   [I-D.ietf-tsvwg-udp-options] creates a surplus area by increasing the
   IP payload length while not varying the UDP length.  Transport
   Options are then added in this surplus area in the form of a TLV
   encoded list.

   The current specification for UDP permits sending datagrams with
   surplus data, but are not commonly observed, and many network devices
   assume that IP payload length is equal to UDP length and have used
   this value when calculating UDP checksums.  This leads to the case
   where some middlebox devices (e.g.  Firewalls, NAPT) and some
   endpoint implementations check or modify the UDP checksum in a way
   that leads to discard of UDP datagrams that carry UDP options.

   This document describes common pathologies of network devices that
   incorrectly calculate the UDP checksum and proposes a new UDP Option
   to compensate for incorrect UDP checksum calculation.




Fairhurst, et al.        Expires April 22, 2019                 [Page 2]


Internet-Draft                  UDPO CCO                    October 2018


2.  Terminology

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

3.  Middlebox Pathologies

   Middleboxes and network interfaces can compute the UDP Checksum
   incorrectly in the presence of UDP Options based on the assumption
   that IP Payload Length and UDP Length coincide (an assumption that
   was equivalent before UDP Options).

   These middleboxes use the IP Payload Length (obtained as IP Total
   Length - IP Header Length) to fill UDP pseudo-header Length field and
   also compute the checksum over the all IP Payload bytes.

   This can lead to UDP Options packets that carry a correctly
   calculated checksum to be discarded by end-hosts or by middleboxes
   along the path.

   Figure 1 shows UDP Checksum computation based on UDP Length and based
   on IP Payload Length and the fields that are different for the two
   calculation methods.



























Fairhurst, et al.        Expires April 22, 2019                 [Page 3]


Internet-Draft                  UDPO CCO                    October 2018


     Sum based on UDP Len   Sum basd on IP len       Delta between two

     +--------+--------+    +--------+--------+    +--------+--------+
     |     Source      |    |     Source      |    |                 |
     |     Address     |    |     Address     |    |                 |
     +--------+--------+    +--------+--------+    +--------+--------+
     |   Destination   |    |   Destination   |    |                 |
     |     Address     |    |     Address     |    |                 |
     +--------+--------+    +--------+--------+    +--------+--------+
     |  zero  |  PTCL  |    |  zero  |  PTCL  |    |        |        |
     +--------+--------+    +--------+--------+    +--------+--------+
     |   UDP Length    |    |IP Payload Length|    | Options Length  |
     +--------+--------+    +--------+--------+    +--------+--------+

     +--------+--------+    +--------+--------+    +--------+--------+
     |   Source Port   |    |   Source Port   |    |                 |
     +--------+--------+    +--------+--------+    +--------+--------+
     |    Dest Port    |    |    Dest Port    |    |                 |
     +--------+--------+    +--------+--------+    +--------+--------+
     |  UDP  Checksum  |    |  UDP  Checksum  |    |                 |
     +--------+--------+    +--------+--------+    +--------+--------+
     |   UDP Length    |    |   UDP Length    |    |                 |
     +--------+--------+    +--------+--------+    +--------+--------+

     +--------+--------+    +--------+--------+    +--------+--------+
     |                 |    |                 |    |                 |
     |                 |    |                 |    |                 |
     |   UDP Payload   |    |   UDP Payload   |    |                 |
     |                 |    |                 |    |                 |
     |                 |    |                 |    |                 |
     +--------+--------+    +--------+--------+    +--------+--------+

                            +--------+--------+    +--------+--------+
                            |                 |    |                 |
                            |   UDP Options   |    |   UDP Options   |
                            |                 |    |                 |
                            +--------+--------+    +--------+--------+

                      Figure 1: Checksum calculations

4.  Checksum Compensation Option

   This section introduces the Checksum Compensation Option (CCO), which
   suggests a new way to calculate the checksum for the option field.

   The design of the CCO seeks to increase UDP Options compatibility
   with middleboxes and other existing network equipment, while at the
   same time providing error detection on UDP Options area in the same



Fairhurst, et al.        Expires April 22, 2019                 [Page 4]


Internet-Draft                  UDPO CCO                    October 2018


   way that the UDP Checksum provides an integrity check for the UDP
   Header and UDP Payload.

   CCO provides a checksum for UDP Option packets that is compatible
   with both variants of the checksum computation making the final value
   of the UDP Checksum computed on the whole IP Payload coincide with
   the the value that would be correctly computed soley on the UDP
   Length.

   The Checksum Compensation Option (CCO) is the 2 byte one's complement
   sum of the one's complement sum of all 2 byte words in the UDP
   Options.  Figure 2 describes the format of the CCO.  The UDP Options
   area is divided into 2 byte words based on their alignment with the
   first byte of UDP packet (and not the first byte of UDP Options).
   This means that the first and the last byte of UDP Options can not
   preceded or be followed by another byte: in these cases the unpaired
   byte must padded respectively on the left and on the right with zero
   to form a 2 byte word.

                         +---------+--------+------------+
                         | Kind=xx | Len=4  |  Checksum  |
                         +---------+--------+------------+
                           1 byte    1 byte    2 bytes

                      Figure 2: UDP CCO Option Format

   [RFC0793] specifies: "The checksum field is the 16 bit one's
   complement of the one's complement sum of all 16 bit words in the
   header and text.  If a segment contains an odd number of header and
   text octets to be checksummed, the last octet is padded on the right
   with zeros to form a 16 bit word for checksum purposes.  The pad is
   not transmitted as part of the segment.  While computing the
   checksum, the checksum field itself is replaced with zeros."  This
   method is equivalent to that specified for UDP [RFC0768].

   The checksum also covers a 2 byte pseudo header conceptually prefixed
   to the UDP Options area.  This pseudo header contains the length of
   UDP Options area.  (The length also forms a part of the TCP and UDP
   pseudo field [RFC0793]).

   Figure 3 shows the bytes on which CCO is computed and how, when
   present, the unpaired byte at the start and/or at end of Options area
   are included in the sum.








Fairhurst, et al.        Expires April 22, 2019                 [Page 5]


Internet-Draft                  UDPO CCO                    October 2018


                               +--------+--------+
                               | Options  Length |
                               +--------+--------+
                               +--------+--------+
                               |                 |
                               |                 |
                               |   UDP Options   |
                               |                 |
                               |                 |
                               +--------+--------+

                               +--------+--------+
                               | Options  Length |
                               +--------+--------+
                               +--------+--------+
                               |  0x00  |        |
                               +--------+ - - - -|
                               |                 |
                               |   UDP Options   |
                               |                 |
                               |- - - - +--------+
                               |        |  0x00  |
                               +--------+--------+

                    Figure 3: UDP ECHORES Option Format

   When this CCO checksum and the UDP Options field are covered by the
   UDP checksum calculation [RFC0768], the resulting UDP checksum value
   is numerically the same as when the UDP checksum calculation is
   calculated over only the UDP Payload.  That is, the result retuned by
   both checksum computations Figure 1 coincide.

4.1.  Calculating the CCO

   The CCO can be present at any position within the Options space, the
   checksum field of the CCO MUST be aligned on a 2 byte boundary.  This
   condition can be achieved by placing a NOP Option before the CCO in
   the case the number of bytes preceding the CCO (UDP Payload + UDP
   Options placed before CCO) is odd (see Figure 4).












Fairhurst, et al.        Expires April 22, 2019                 [Page 6]


Internet-Draft                  UDPO CCO                    October 2018


                            +--------+--------+
                            |    UDP Header   |
                            |       ...       |
                            +--------+--------+
                            |   UDP Payload   |
                            |    and other    |
                            |   UDP Options   |
                            |       ...       |
                            |        +--------+
                            |        |  NOP   |
                            +--------+--------+
                            |  CCO   | CCOLen |
                            +--------+--------+
                            |    CCO  value   |
                            +--------+--------+
                            |Other UDP Options|
                            |       ...       |
                            +--------+--------+

                       Figure 4: Option Space layout

   When calculated in this way, the CCO value is initialized to zero and
   the checksum is calculated over the UDP Options and the pseudo-
   header: the one's complement of the result is then stored in the CCO
   field.

   An alternative implementation could be to initialise the CCO field
   with the size of the UDP Options area (instead of initialising the
   CCO value to zero and combining with a pseudo header).  This produces
   the same result, but allows the checksum to be performed using solely
   the UDP Options area.

4.2.  Validating CCO

   When a UDP packet containing CCO is received the Internet Checksum
   should be computed on the UDP Options area (2 byte aligned as
   described in Section 4.3) and the pseudo-header (the length of the
   received UDP Options), and the Options is valid if the one's
   complement of the result is zero.

   If the option checksum fails, all options MUST be ignored and any
   trailing surplus data (and Lite data, if used) silently discarded.
   UDP data that is validated by a correct UDP checksum MUST be
   delivered to the application layer, even if the UDP option checksum
   fails.






Fairhurst, et al.        Expires April 22, 2019                 [Page 7]


Internet-Draft                  UDPO CCO                    October 2018


4.3.  CCO Calculation Examples

   This section provides examples of calculating the Checksum
   Compensation Option, similar to those presented in [RFC1071].

   XXX IANA NOTE: The type of the CCO option has yet too be assigned,
   and may change.  XXX

   These examples use 204 (0xCC) as the type for the CCO option

   In the first example the UDP Payload length is even and a MSS Option
   has been already placed in UDP Options area.  CCO value is
   initialized with UDP Options Length (0x0008).

         UDP Length:               Even
         Preceding UDP Options:    MSS (kind 5, len 4, val 0x5c0)
         Following UDP Options:    None

         NOP Padding before CCO:   No
         Total UDP Options Length: 8

         UDP Options bytes 0/1:    0504
         UDP Options bytes 2/3:    05c0
         UDP Options bytes 4/5:    cc04
         UDP Options bytes 6/7:    0008
                                   ----
         Sum:                      d6d0

         CCO:                      292f

                      Figure 5: Checksum calculations

   In the second example the UDP Payload length is odd and a MSS Option
   has been already placed in UDP Options area.  The available space for
   CCO starts at an odd byte (NOP padding before CCO) and also UDP
   options space starts at odd byte (left zero padding of first byte).
   CCO value is initialized with UDP Options Length (0x0009).














Fairhurst, et al.        Expires April 22, 2019                 [Page 8]


Internet-Draft                  UDPO CCO                    October 2018


         UDP Length:               Odd
         Preceding UDP Options:    MSS (kind 5, len 4, val 0x5c0)
         Following UDP Options:    None

         NOP Padding before CCO:   Yes
         Total UDP Options Length: 9

         UDP Options bytes   0:    0005
         UDP Options bytes 1/2:    0405
         UDP Options bytes 3/4:    c001
         UDP Options bytes 5/6:    cc04
         UDP Options bytes 7/8:    0009
                                   ----
         Sum:                      9019

         CCO:                      6fe6

                      Figure 6: Checksum calculations

4.4.  Interaction with other UDP Options

   Interaction with other UDP Options

   AE:  Similarly to what happens with OCS, AE can be computed as if the
      AE hash and CCO value are zero.  CCO value can be computed as if
      the CCO value is zero and after the AE hash has been computed.

   ACS:  The CCO has no interference with ACS since an ACS is computed
      only on UDP Payload bytes (no Header, no Options).  The CCO value
      must be computed after the ACS has already been computed.

   LITE:  The CCO covers the entire UDP Option area, including any LITE
      option as formatted after swapping (or relocation) for
      transmission (or, equivalently, before the swap/relocation after
      reception).  The CCO is computed after LITE swapping/relocation to
      guarantee the checksum compensation of the packet actually sent.

5.  Acknowledgements

   This work is partially supported by the European Commission under
   Horizon 2020 grant agreement no. 688421 Measurement and Architecture
   for a Middleboxed Internet (MAMI).

6.  IANA Considerations

   This memo includes no requests to IANA





Fairhurst, et al.        Expires April 22, 2019                 [Page 9]


Internet-Draft                  UDPO CCO                    October 2018


7.  Security Considerations

   The security considerations for are described in
   [I-D.ietf-tsvwg-udp-options].  The proposed new method does not
   change the integrity protection offered by the UDP options method.

8.  Normative References

   [I-D.ietf-tsvwg-udp-options]
              Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
              udp-options-05 (work in progress), July 2018.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [RFC1071]  Braden, R., Borman, D., and C. Partridge, "Computing the
              Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
              September 1988, <https://www.rfc-editor.org/info/rfc1071>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Appendix A.  Revision Notes

   Note to RFC-Editor: please remove this entire section prior to
   publication.

   Individual draft -00:

   o  Comments and corrections are welcome directly to the authors or
      via the IETF TSVWG working group mailing list.

   o  This update is proposed for WG comments.

Authors' Addresses









Fairhurst, et al.        Expires April 22, 2019                [Page 10]


Internet-Draft                  UDPO CCO                    October 2018


   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen  AB24 3UE
   UK

   Email: gorry@erg.abdn.ac.uk


   Tom Jones
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen  AB24 3UE
   UK

   Email: tom@erg.abdn.ac.uk


   Raffaele Zullo
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen  AB24 3UE
   UK

   Email: raffaele@erg.abdn.ac.uk























Fairhurst, et al.        Expires April 22, 2019                [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/