Re: [tsvwg] design assumptions - draft-ietf-udp-options - trying to see the bigger picture

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

On Thu, Jul 18, 2019 at 3:39 AM Gorry Fairhurst wrote:
> I'm trying to understand LITE and the related topics more...
>
> (1) One use-case is to mimic UDP-Lite for layer2 networks that wish to
> do cross-layer optimisation. The AMR codec would be an example. Such
> networks *NEED* to know the transport requires them to do partial
> integrity checks at L2 (if the CRC the entire frame this approach is
> useless). To get any real advantage, I'd say they have to do much more,
> by probably changing the waveform (FEC, modulation, etc). UDP-Lite
> offers that, and I have not seen people wanting more/different features
> - Magnus provided comments recently, and I would concur this requires
> strong coordination with the App and Link design, UDP-Lite remains a
> suitable method, I would agree that adding this to another protocol is
> not helpful.
>
> (2) A second use-case is to support router/network device encapsulation
> (i.e. tunnels) where the network device has no visibility deep into the
> payload. Such devices existed and continue to exist. This was a
> motivation in GRE/UDP. However, for IPv6 a zero UDP checksum is
> restricted to specific uses-cases, and not a host function - because
> as Lloyd pointed out this erodes ability to detect rogue UDP datagrams.
>
> (3) A third use-case is when the packet contains another checksum (also
> the case for some tunnels), and we could save the cost of a second
> checksum.  I am not persauded that this is a real cost when comes to a
> frag/reassembly algorithm.
>
> (4) Some other future use, as yet unknown?
>
>
> The more I think about LITE the less I really am persauded (1) is needed.
>
> I think (2) could be useful, but I don't yet see someone asking for
> that, and I'd expect hosts to see the entire payload, so at least a host
> implementation does not seem to need that.

Recent discussions of LITE have considered a variant that uses checksum
compensation of the transmit side (which is not checked on the receive
side) to deal with middlebox traversal issues related to the checksum.
It would provide the following services:

(a) delivery of damaged payload data across an Internet where middleboxes
routinely block protocol 136 (UDP-Lite)

(b) additional transport options to accompany such payloads

If I correctly understand the discussion of (1) above, it is argued that
reaping practical benefit from delivery of damaged payload data requires
close coordination between the transport/network layers and the data link
layer. Clearly, there's no way that's going to happen in the general
Internet; such use is confined to controlled environments, where UDP-Lite
works fine. So there really isn't any benefit from (a). Additionally, it
is argued that (b) provides no evident advantage in those environments.

So this variant of LITE would not be helpful for use case (1). And since it
requires visibility into the payload to compute the compensation checksum,
it is not helpful for (2) and provides only marginal help for (3).

> I'm hessitant to agree that the complexity of LITE is worth the perceived
> cost saving and there may be other ways that don't need this:
> (*) Hardware  off-load of the checksum (e.g. Tom Herbert commened) means
> the cost can be minimal.
> (*) For a method designed just for reassembly, it is also possible to
> "checksum" the fragment checksums in a fragementation protocol to provide
> equivalent one-pass checksum.

I've argued that last point repeatedly (though Joe does not agree).

If delivery of damaged payloads is adequately covered by UDP-Lite, it
would IMO make sense to strike support for LITE (#8) from the list of
design requirements. That would leave it only as a means to support
FRAG, and I think there are much better ways to do that (I've made two
proposals for FRAG that do not require LITE).

> On the OCS topics:
>
> * DNSSEC or any host could send UDP fragments, would it really cost too
> much to send these with a full UDP checksum for IPv6? (and then why not
> IPv4)?
>
> * I have heard both sides on "middlebox checksum/payload length bug
> traversal" (#7) which requires a CCO-like sum. I really appreciated the
> thread, which I paraphrase as something like (do I understand):
>
> -- Sender SHOULD add an OCS when the UDP Datagram (Frag) Checksum is
> non-zero - recomended for traversal (and basic integrity protection).

Yes

> -- Sender MUST check ACS or AE when present and before it process other
> UDP Options, does not then need to check the OCS on reception.

I do not recall that being said. Per the draft, AE is computed first
using a zero-checksum OCS if present, and OCS is computed last before
transmission, over the entire option area, including AE. Validation
on receive would go in the reverse order.

> -- Sender MUST check one of the  OCS when the UDP Checksum is non-zero
> when present and no ACS, and before it processes other UDP Options. A
> 16b CRC isn't that strong for a full-sized IP packet (but better than
> the Internet checksum), but a CRC32 would be.

During the discussion I did suggest that the receiver should check OCS
before parsing the options (possible if its presence is tied to the UDP
checksum being non-zero, thanks to adopting CCO for the OCS).

> -- Sender SHOULD add an OCS when the UDP Checksum is zero - to aide
> traversal.

I think David Black and I converged on sender MAY add and receiver
MAY check OCS when UDP Checksum is zero. The statement that OCS aids
traversal when UDP Checksum is zero was withdrawn -- we couldn't find
the evidence in the maprg presentation from IETF 103. If that's wrong
please speak up and correct us.

> -- Sender SHOULD allow a LITE option to be processed when the OCS is
> invalid - although that IMHO needs though as to how you decide on the
> validity of the packet.

I think that is a very controversial statement -- I certainly disagree.

> And so back to Frag:
>
> I'm concerned that DPLPMTU, Frag and Lite have much more complexity in
> their design than other parts of the spec - and more consideration is
> needed on their use.
>
> For DPLPMTU (#6) the complexity is in another spec (which seems correct
> to me). I'd be interested whether a separate spec of Frag is also one
> way to ensure we get experience with the core spec, and then consider
> how to design Frag (#5, #8).

For DPLPMTU the complexity is in another spec, but the tools that UDP
options provide for it are in the base spec. Those tools are:

- padding for probe packets
- request option
- response option

The request and response options are pretty straightforward, but the
details of how padding will be accommodated may well depend on what
packet format we converge to for providing other things, especially
FRAG. So I am concerned that if we take FRAG off the table for now we
might end up with a design that requires major rework to other features
when we go to add it. So I'd advocate keeping it on the list of
design requirements.

Also, there was another design requirement whose addition I requested,
but which (so far) does not seem to have made it onto the list:

9 - any option that affects the handling of payload data must share fate
with that payload data, in all receivers (legacy or otherwise)

This would be to prevent a receiver from dropping something like FRAG or
AE (especially in its encryption variant) because OCS fails but delivers
the payload because its checksum is OK. The same thing could happen if
future options that affect payload handling are defined, and the spec
says ignore unknown options. Dealing with those considerations can
affect the design of the packet format and the encoding of the options.

>
> Gorry
>
>
>
> On 18/07/2019, 09:47, [e-mail] wrote:
>> Hi Joe,
>>
>> Your reply confirms my initial thinking.
>>
>> 5#, 6#, and #8 are targeting a particular case and should not be
>> considered as such as part of the core design requirements for UDP
>> options.
>>
>> BTWs, I don’t understand well what is specific to DNSSEC fragments
>> here to traverse NATs. Such NATs will fail to handle any incoming
>> fragment, not only DNS. NATs which are compliant with REQ#14 of
>> RFC4787 will handle appropriately fragments (modulo DDoS protection
>> features).
>>
>> If a firewall/NAT is explicitly configured to reject such fragments
>> for whatever reason, these devices are likely to strip/reject the
>> FRAG options (or UDP options in general).
>>
>> We need to set first the foundations, and then build on it for
>> particular usages.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Joe Touch [mailto:[e-mail]]
>>> Envoyé : mercredi 17 juillet 2019 17:02
>>> À : BOUCADAIR Mohamed TGI/OLN
>>> Cc : tsvwg
>>> Objet : Re: [tsvwg] design assumptions - draft-ietf-udp-options
>>>
>>> FWIW, #5 Frag is a driving case for DNSSEC to allow UDP messages larger
>>> than the min MTU to traverse NATs. IP
>>>
>>> And it should never interact with IP fragmentation any more than TCP
>>> segmentation does.
>>>
>>> #6 is required to enable #5.
>>>
>>> And thus far, #8 is required to support #5 in a way that satisfies #2.
>>>
>>> I.e., the ones I listed can’t be teased out the way you’re suggesting.
>>>
>>> Joe
>>>
>>>> On Jul 17, 2019, at 7:46 AM,<[e-mail]> wrote:
>>>> Hi Joe,
>>>>
>>>> IMO, the core requirements are #1, #2, #3, #4, and #7.
>>>>
>>>> #7 should be mandatory feature.
>>>>
>>>> 5#, 6#, and #8 are nice-to-have. I would even prefer if those are
>>>> covered in a separate specification. For example, I'm not sure whether
>>>> FRAG will be useful and how it can interacts with IP fragmentation.
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : tsvwg [mailto:[e-mail]] De la part de Joe Touch
>>>>> Envoyé : mercredi 17 juillet 2019 02:31
>>>>> À : tsvwg
>>>>> Objet : [tsvwg] design assumptions - draft-ietf-udp-options
>>>>>
>>>>> Getting back to the core design assumptions:
>>>>>
>>>>> 1- support options
>>>>> 2- allow at least some options to be silently ignored by legacy
receivers
>>>>> (to enable ‘“optionally enhanced” exchanges)
>>>>> 3- allow at least some options to be required
>>>>> 4- allow the options themselves to be protected
>>>>> 5- support for fragmentation/reassembly
>>>>> 6- support for MTU discovery
>>>>> 7- support (optional?) middlebox checksum/payload length bug traversal
>>>>> 8- support LITE, i.e., where some of the payload is not covered by at
>>>>> least some checksum processing
>>>>>
>>>>> AFAICT:
>>>>>
>>>>> #7 requires a CCO-like sum, but it MUST he calculated AFTER all other
>>>>> options are populated (it depends on the value of ALL other options
and
>>>>> surplus data)
>>>>>
>>>>> #8 can depend on everything except CCO (it doesn’t need to protect
CCO),
>>>>> but it depends on the value of all other options and needs to be
computed
>>>>> next-to-last (or last if CCO isn’t present)
>>>>>
>>>>> And we need a way to know:
>>>>>    - for #7, whether CCO is included or not used (at user’s peril, but
>>>>>      to allow for transmitters to avoid work)
>>>>>    - for #8, when to end the options (either a length field OR a EOL
flag)
>>>>>
>>>>> Are there any other design requirements?
>>>>>
>>>>> Joe
>>>>
>>>
>>
>