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

[Gorry Fairhurst <[e-mail]>]

The thread split, so this is a reply to Joe.

On 18/07/2019, 15:50, Joe Touch wrote:
> Hi, Gorry,
>
> True LITE (not just LITE with no user data) is definitely complex...
>
>> On Jul 18, 2019, at 3:38 AM, Gorry Fairhurst<[e-mail]>  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.
> This is the case that makes the most complications for us.
>
>> ... 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.
> If we take this off the table, things get a little simpler...
>
>> (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.
> Tunnels are links, and links terminate at both routers and hosts.
>
> This doesn’t erode anything; it follows the IPv6 policy of not duplicating the same kind of check at multiple layers (i.e., it’s odd that we keep citing IPv6 as the reason we can’t set UDP to zero, when in fact the reason we can drop the checksum for tunnels is exactly the same reasoning used to drop the header checksum in IPv6 - thankfully that’s now understood).
>
Expecting hosts to set zero checksum is something we need to be careful 
about. If Frag did not do this, I'd expect easier acceptance.
>> (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,
> That’s part of the issue with computing the checksum over the fragment parts vs. whole...
Sure - or we compute an *additional* checksum when we have fragments. It 
will cost (a little), but if it solves DNS issues, then I'd already be 
excited.
>> and I'd expect hosts to see the entire payload, so at least a host implementation does not seem to need that.
> Hosts don’t want to touch the data twice to check the fragments AND check the reassembled set.
Right, that's a question I would like tested.
There are other cases: e.g. Frag usually involves a move, doing checksum 
and move can be efficient.
> (and the byte swap in the current LITE is part of RDMA-like zero-copy placement of fragments once received into a single place before making that final check).
>
>> 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.
> Hardware offload doesn’t help if checksumming is done multiple times.
Well, it save the per-fragment CPU processing. The host then only needs 
to worry
about other checks.
>> (*) 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.
> But it’s not equivalent. Remember that data in the host can have errors once each fragment is received too. TCP gives up on that because it HAS to deliver each fragment once previous ones were received; UDP doesn’t.
Yes - what you I proposed would be weaker.  Doing seprate reassembly 
check would be the best thing.
>> 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)?
> Those are ones I’d be worried about - esp. at root servers, in fact.
>
>> * 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.
> I think you mean receiver, so assuming that…
>
> No, OCS still needs to be checked on receipt (if UDP CS !=0). ACS and AE apply to the UDP user data, not the surplus area.
>
Ah - understood.
>> -- 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.
> (receiver…)
>
> Ignore ACS. Again, ACS is over the user data, not surplus area.
Same, understood.
>> -- Sender SHOULD add an OCS when the UDP Checksum is zero - to aide traversal.
> Yes…let’s call this what it is, though - to aid traversal of middlebox bugs.
Fine.
>> -- 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.
> (receiver…)
>
> Hmm. Now I’m confused. You’ve just re-enabled everything LITE had in the first place (including UDP-LITE emulation), but then you have to parse into the area to figure out when to ignore OCS...
Then let's not drill there, becaiuse I really want to know if we need 
LIGHT for Frag.
>> 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).
> We can, but IMO the criticality of fragmentation support means that it’s not particularly relevant to have UDP options that don’t support fragmentation.
I think we are making progress on this and other threads. Let's see how 
far we get by the time of the meeting.
> Joe
>
Gorry
>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>