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

From: "C. M. Heard" <[email-masked]>
Date: Tue, 28 Feb 2017 10:58:24 -0800

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 12:03:59 -0800

Hi, Mike,

On 2/28/2017 10:58 AM, C. M. Heard wrote:
> filtering IPv4 or IPv6 fragments.

That's a very good point - I'll add that to the discussion of the option.

>  Application layer solutions have been
I have to give credit to Mike Smith for suggesting it.

> the UDP header.
I'm thinking now about the ordering of options. I'd really like to allow
FRAG to precede others, especially LITE. I see your point about the
checksums of the pieces vs. the whole...

>  Finally, if used in conjunction with the Lite option, it
Is see how that's useful, but it would also appear to mean we might be
able to use LITE twice - once as this trick to hide fragments (which is
elegant - thanks!), but also to allow the use of LITE in the final
result. I'm not sure whether that makes sense yet, though - if you check
to see that the whole thing is there, there's little point in allowing
part of the packet to not be checksummed (it already would be).

So maybe LITE couples with FRAG only in the way you mention, and no other?

> it also needs a new caption.
Yeah - sorry. That was sloppy of me. I did (FWIW) try to push all the
pending updates into the text in about half a day yesterday, so I
apologize for it being draftier than it should be. Thanks for pointing
that out.

> presence or absence of Lite and Fragmentation, but it would be good to

Absolutely - as I noted, I need to think a little more about this issue
and make a recommendation. Glad to hear what others think.

AFAICT:
    OCS covers the header in each fragment
    ACS, being an alternative to the UDP checksum, covers the UDP user
data in each fragment (same as the UDP checksum, so not LITE)

As was noted, we might need a total "reassembled" checksum.

I'm not clear on whether it makes sense to use LITE with FRAG (except as
the trick noted before, to hide fragments from legacy receivers).

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 28 Feb 2017 15:06:15 -0800

> So maybe LITE couples with FRAG only in the way you mention, and no other?

That is exactly how I would envision it.

Thanks,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 Feb 2017 15:15:42 -0800

Mike,

Consider this:

if we use LITE before FRAG as you propose, then the reassembled result
has no checksum yet.

so the FRAG header could incorporate LITE if it used two different
length fields: one for the whole length, one for the checksummed length.

I.e., rather than require full "option" processing after FRAG, we could
build LITE support into FRAG itself.

Would that make sense?

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 28 Feb 2017 16:41:49 -0800

> build LITE support into FRAG itself.

I definitely like the idea of building LITE support into FRAG,
particularly if one of the side effects is that we always hide
fragments from legacy implementations. But let me walk through
it to make sure that I understand how it would work.

With LITE at the beginning of the payload before FRAG, as I initially
suggested, the UDP length is 8 and the UDP checksum protects only
the UDP header. LITE specifies how much of the surplus area is user
data; the rest is transport options, including FRAG itself. FRAG
specifies the fragment offset, the M bit, the identification, and
(if the rest of my suggestion is accepted), a post-reassembly length
and checksum,

If FRAG were to incorporate LITE, it would still appear immediately
after the UDP header (which would be unchanged). If you want to
incorporate per-fragment UDP options, FRAG would now need to have
the offset to the remaining UDP options. So, its fields would now
be: kind, length (16 bytes),  fragment offset, M bit, identification,
post-reassembly length that was checksummed, checksum value,
post-reassembly length that was not checksummed, and offset to
remaining options. Is that what you had in mind? If so, it would
certainly work for me.

I believe that a technically viable alternative would be to have instead
per-fragment length that was checksummed, checksum value, and per-fragment
length that was not checksummed. In that case the offset to the remaining
options could be inferred. Another alternative would be to use post-reassembly
values and only one set of UDP options for the entire message; the options
would then be whatever surplus remained after the last fragment was
reassembled, and a separate length field again would not be needed.

Let me mention in passing that I tend to agree with the sentiment that
the standard Internet checksum is probably the right way to go. If that
is provided for the entire reassembled message, you will have feature
parity with what is provided by UDP + IP fragmentation.

Mike Heard