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

[Gorry Fairhurst <[e-mail]>]

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.

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.


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).
-- 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.
-- 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.

-- Sender SHOULD add an OCS when the UDP Checksum is zero - to aide 
traversal.
-- 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.

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).

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