Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt

["C. M. Heard" <[e-mail]>]

Greetings,

I am very pleased with the latest version of this draft, and in particular
with the proposed Fragmentation option. It cleanly solves the problem of
providing an optional fragmentation capability in UDP that can be
incrementally deployed. It appears to be a viable way to solve the problem
of fragmented DNSSEC responses getting dropped because of middleboxes
filtering IPv4 or IPv6 fragments. Application layer solutions have been
proposed (see https://tools.ietf.org/html/draft-muks-dns-message-fragments),
but the current proposal has the advantage that it will work for any
UDP-based protocol. It will work especially well for request-response
protocols such as DNS where the requests typically are small (not requiring
fragmentation) but the responses may be large. To use it, the client sends
the request in an unfragmented UDP datagram but appends a Fragmentation
option with Offset and M both zero. If the server does not support UDP
options, it ignores the trailing option and behaves as it does today. If
the server does support UDP options and the response won't fit in a single
UDP datagram without causing IP layer fragmentation, it transmits the
response in several datagrams, using the UDP fragmentation options. This
will work especially well for IPv6, where the path MTU is guaranteed to be
at least 1280 bytes.

Back in 2013 several proposals for UDP layer fragmentation surfaced during
a discussion on the 6man list about whether to deprecate IPv6 fragmentation
(one was in https://www.ietf.org/mail-archive/web/ipv6/current/msg18703.html).
None of those proposals solved the problem of incremental deployability,
however, as this one does. Thanks and congratulations for coming up with
an elegant solution.

I do have some technical comments to make on the Fragmentation option.

First, I would like to suggest that the post-reassembly user data length
and optionally a post-reassembly user data checksum appear in the UDP
Fragmentation option. The reason for including a post-reassembly length is
to provide a hint to the implementation how much buffer space to reserve;
in order to be foolproof in the face of packet reordering, this needs to be
in every fragment. The optional post-reassembly checksum would need to be
in at least one Fragmentation option and (like the post-reassembly length)
would have to have be the same if it appeared more than once. Its main
value is that it provides a stronger verification that the reassembly
process was done correctly than the fragment-by-fragment checksum in
the UDP header. Finally, if used in conjunction with the Lite option, it
provides a means to overcome the following issue:

   The Fragmentation option needs to be used with extreme care because
   it will present incorrect datagram boundaries to a legacy receiver.

If the Fragmentation option includes its own post-reassembly checksum,
then a Lite option could be inserted immediately following the UDP
header in each fragment, without loss of functionality. Implementations
that do not support UDP options would see UDP fragments so constructed
as empty UDP datagrams and would discard them, removing the danger of
accidental misinterpretation.

I also have an editorial comment on this option. Figure 15 shows the option
length as 12 bytes and the Identification field length as 8 bytes, while the
text says that the Identification field is 32 bits (4 bytes). This figure
needs to be updated to match the text (whatever that turns out to be) and
it also needs a new caption.

Finally, the text is silent on how Alternate Checksum (ACS) interacts with
the Lite option and with the Fragmentation option. My assumption would be
that ACS covers the entire payload in one datagram, irrespective of the
presence or absence of Lite and Fragmentation, but it would be good to
make this explicit.

Thanks and regards,

Mike Heard

On Mon, 27 Feb 2017 15:30:59 -0800, Joe Touch wrote:
>
> Hi, all,
>
> A new version of the UDP options proposal has been posted.
>
> It adds:
>
>     - fragmentation based on IPv6's mechanism (thanks to Mark Smith)
>
>     - MSS (thanks to Mark Smith) and TS based on TCP's mechanism
>
>     - auth/encryption based on TCP-AO and its extensions
>
> It clarifies the report of a non-compliant legacy device (thanks to Mike Heard).
>
> It also adds a discussion on control block caching, ala RFC2140 for TCP.
>
> Feedback welcome.
>
> Joe
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-touch-tsvwg-udp-options-05.txt
> Date: Mon, 27 Feb 2017 15:24:32 -0800
> From: internet-drafts at ietf.org
> To: Joseph Touch <touch at isi.edu>, Joe Touch <touch at isi.edu>
>
>
> A new version of I-D, draft-touch-tsvwg-udp-options-05.txt
> has been successfully submitted by Joe Touch and posted to the
> IETF repository.
>
> Name: draft-touch-tsvwg-udp-options
> Revision: 05
> Title: Transport Options for UDP
> Document date: 2017-02-27
> Group: Individual Submission
> Pages: 20
> URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-05.txt
> Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
> Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-05
> Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-05
>
> Abstract:
>    Transport protocols are extended through the use of transport header
>    options. This document experimentally extends UDP by indicating the
>    location, syntax, and semantics for UDP transport layer options.
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat