[tsvwg] A counterproposal to Section 5.5 of draft-ietf-tsvwg-udp-options-12

"C. M. Heard" <heard@pobox.com> Fri, 04 June 2021 02:22 UTC

Return-Path: <heard@pobox.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635F33A2439 for <tsvwg@ietfa.amsl.com>; Thu, 3 Jun 2021 19:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NFwv55TRggI for <tsvwg@ietfa.amsl.com>; Thu, 3 Jun 2021 19:22:41 -0700 (PDT)
Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA143A2447 for <tsvwg@ietf.org>; Thu, 3 Jun 2021 19:22:41 -0700 (PDT)
Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 43E4C14765B for <tsvwg@ietf.org>; Thu, 3 Jun 2021 22:22:38 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:content-type; s=sasl; bh=ownFlEwuZkYzzDB60YyqFlz6D1gf/FxJ/nd 2SHBJTTM=; b=noAbndBSPmSy2RmVdWUnbt1L4D0OvlnEkzNEMBdYCGsBw/O3B/U jyFDBwxJrsb5L9pZUzvxhEsNSkAbTL797L9MWcq1u1nxj6biQyiaj38gL+tIz4LE eZS1HTQerGYgr+wLSDIFL9TKVvYqYNQ/zK+SGBOi9nUIuF7+ASLFoVZI=
Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id 3E3C614765A for <tsvwg@ietf.org>; Thu, 3 Jun 2021 22:22:38 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-io1-f50.google.com (unknown [209.85.166.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id CC333147657 for <tsvwg@ietf.org>; Thu, 3 Jun 2021 22:22:35 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-io1-f50.google.com with SMTP id p66so6598069iod.8 for <tsvwg@ietf.org>; Thu, 03 Jun 2021 19:22:35 -0700 (PDT)
X-Gm-Message-State: AOAM533WSlhLPavgwGZf/yZctIVRuZjHNFWUlPLem22I0And57gSZsSm FiJAWtYXUwGsyIqz5xGep+P4bqe5kxm7UaaALys=
X-Google-Smtp-Source: ABdhPJzXdFhpe6wVVJA0NH6dRsoJGGPb5EdNhquQl1sZACaWJdzbISERvR6Dn9q3B1No+Dt1FeKuWO1q9EuJbObh4hg=
X-Received: by 2002:a6b:5112:: with SMTP id f18mr1802936iob.142.1622773354480; Thu, 03 Jun 2021 19:22:34 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VEyLdQZ-3hvzXxyA8ehtWs2hXESZ2OqyAx+BeSg85+-cA@mail.gmail.com>
In-Reply-To: <CACL_3VEyLdQZ-3hvzXxyA8ehtWs2hXESZ2OqyAx+BeSg85+-cA@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 03 Jun 2021 19:22:22 -0700
X-Gmail-Original-Message-ID: <CACL_3VFE4TjKvmkfZjvNpWo6vVfKjz5w85=Q+yqnYZKcwbYLmQ@mail.gmail.com>
Message-ID: <CACL_3VFE4TjKvmkfZjvNpWo6vVfKjz5w85=Q+yqnYZKcwbYLmQ@mail.gmail.com>
To: TSVWG <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000584d4905c3e75dce"
X-Pobox-Relay-ID: B9C4EA86-C4DB-11EB-94F5-D5C30F5B5667-06080547!pb-smtp20.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/N1fmoBxQ5iOL5X7o34oVSA8Ayvw>
Subject: [tsvwg] A counterproposal to Section 5.5 of draft-ietf-tsvwg-udp-options-12
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2021 02:22:54 -0000

TSVWG,

In a previous message, I made some rather unkind comments about he FRAG
option as proposed in Section 5.5 of draft-ietf-tsvwg-udp-options-12. In
this missive I wish to present proposed relacement text for the entire
section. If some of the packet diagrams end up a bit garbled, please accept
my apologies; I am working within the limits of the gmail client, and I
can't always tell what will look good to list recipents or those who browse
the TSWG archive. This proposal first appeared in
https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg/.
The central idea is to make the FRAG option the very last option in the
packet and to have it consume all following octets. I want to acknowledge
freeley borrowing/stealing the best of some of Joe Touch's excellent text
in draft-ietf-tsvwg-udp-options-12.

--cut here--

5.5. Fragmentation (FRAG)



   The Fragmentation (FRAG) option supports UDP fragmentation and
   reassembly, which can be used to transfer UDP messages larger than
   limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically
   used with the UDP MSS option to enable more efficient use of large
   messages, both at the UDP and IP layers.  FRAG is designed similar
   to the IPv6 Fragmentation Header [RFC8200], except that the UDP
   variant uses a 16-bit Offset measured in bytes, rather than IPv6's
   13-bit Fragment Offset measured in 8-byte units.  FRAG

   provides transport-layer fragmentation and reassembly in which each
   fragment includes a copy of the same UDP transport ports, enabling
   the fragments to traverse Network Address (and port) Translation
   (NAT) devices, in contrast to the behavior of IP fragments.


   >> When FRAG is present, the UDP payload MUST be empty. If the
   payload is not empty, all UDP options MUST be silently ignored
   and the UDP payload received MUST be sent to the user.

   Legacy receivers interpret FRAG messages as zero-length payload
   packets (i.e., UDP Length field is 8, the length of just the UDP
   header), which would not affect the receiver unless the presence
   of the packet itself were a signal.


   >> When FRAG is present, it MUST come LAST in the UDP options list.

   All remaining octets in the packet are interpreted as fragment data.


   The FRAG option has two formats; non-terminal fragments set the
   More Fragments (MF) field to 1 and terminal fragments set the MF
   field to 0.  The latter includes stand-alone fragments, i.e., when
   data is contained in the FRAG option but reassembly is not required.

   In both cases the option length is implicitly eight octets.


                   +--------+--------+--------+--------+
                   | Kind=5 |  MF=1  |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   |       ... Fragment Data ...       |
                   +--------+--------+--------+--------+

                    UDP non-terminal FRAG option format

                   +--------+--------+--------+--------+
                   | Kind=5 |  MF=0  |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   |       ... Fragment Data ...       |
                   +--------+--------+--------+--------+

                      UDP terminal FRAG option format

   >> The Fragment Offset is 16 bits and indicates the location of the
   UDP payload fragment in bytes from the beginning of the original
   unfragmented payload.  The MF field indicates whether there are more
   fragments (MF=1) or no more fragments (MF=0).

   >> The Identification field is a 32-bit value that MUST be unique
   over the expected fragment reassembly timeout.

   >> The Identification field SHOULD be generated in a manner similar
   to that of the IPv6 Fragment ID [RFC8200].

   >> UDP fragments MUST NOT overlap.  Note that exact duplicates may

   occur when packets are duplicated in the network.


   UDP fragmentation relies on a fragment expiration timer, which can
   be preset or could use a value computed using the UDP Timestamp
   option.

   >> The default UDP reassembly SHOULD be no more than 2 minutes.

   Implementers are advised to limit the space available for UDP
   reassembly.

   >> UDP reassembly space SHOULD be limited to reduce the impact of
   DOS attacks on resource use.

   >> UDP reassembly space limits SHOULD NOT be implemented as an
   aggregate, to avoid cross-socketpair DOS attacks.

   >> Individual UDP fragments MUST NOT be forwarded to the user.  The
   reassembled datagram is received only after complete reassembly,
   and continued processing of the remaining UDP options.


   >> Only per-fragment UDP options may accompany the FRAG header in
   non-terminal fragments.  These include NOP, OCS, and AE.  All options
   that apply to a reassembled UDP datagram MUST accompany the FRAG
   header in the terminal fragment.  These include ACS, MSS, MRSS,
   TIME, REQ, and RES.  UNSAFE may appear in either place, depending.
   on the nature of the UNSAFE Ukind.


   In general, UDP packets are fragmented as follows:

   1. Create a datagram with data and any UDP options that apply to the
      complete UDP datagram, which we will call "D".  Note that these
      options must accompany the terminal fragment.  They are prepared
      before the rest of the fragmentation steps below.

   2. Identify the desired fragment size, which we will call "S".  This
      value should take into account the path MTU (if known) and allow
      space for per-fragment options (e.g., OCS).

   3. Fragment "D" into chunks of size no larger than "S"-8 each.  Note
      that all of the per-datagram options in step #1 MUST appear in
      the terminal fragment.

   4. For each chunk of "D" in step #3, create a zero-data UDP packet
      followed by the per-fragment options, with the final option being
      the FRAG option followed by the FRAG data chunk.

      The last chunk includes the non-FRAG options noted in step #1.
      These UDP options apply to the reassembled data as a whole.

   5. Process the UDP options of each fragment, e.g., computing its
      OCS.

   Receivers reverse the above sequence.  They process all received
   options in each fragment.  When the FRAG option is encountered, the
   FRAG data is used in reassembly.  After all fragments are received,
   the entire packet is processed with any per-datagram UDP options
   accompanying the terminal fragment applying to the reassembled data.

--cut here--


This is what typical UDP datagrams containing UDP fragments would look like:


                   +--------+--------+--------+--------+
                   |  Source Port    |   Dest. Port    |

                   +--------+--------+--------+--------+
                   |   UDP Len=8     |  UDP Checksum   |

                   +--------+--------+--------+--------+
                   | NOP=1  | OCS=2  | Option Checksum |
                   +--------+--------+--------+--------+
                   | FRAG=5 |  MF=1  |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   |       ... Fragment Data ...       |
                   +--------+--------+--------+--------+

                     UDP non-terminal FRAG packet


                   +--------+--------+--------+--------+
                   |  Source Port    |   Dest. Port    |

                   +--------+--------+--------+--------+
                   |   UDP Len=8     |  UDP Checksum   |

                   +--------+--------+--------+--------+
                   | NOP=1  | OCS=2  | Option Checksum |
                   +--------+--------+--------+--------+
                   |       ... Other Options ...       |
                   +--------+--------+--------+--------+
                   | FRAG=5 |  MF=0  |  Frag. Offset   |
                   +--------+--------+--------+--------+
                   |          Identification           |
                   +--------+--------+--------+--------+
                   |       ... Fragment Data ...       |
                   +--------+--------+--------+--------+

                     UDP terminal FRAG packet

Kindly review and send send constructive comments to the WG list

Thanks and regards,

Mike Heard