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

[Gorry Fairhurst <[e-mail]>]

On 18/07/2019, 16:46, C. M. Heard wrote:
> 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 curious as to who in the WG thinks otherwise, and if so why.
> > 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 fragmentation 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).
>
It would be interesting to understand the real desire to eliminate the
cost of doing both a UDP and a reassembly checksum - so we can rule
that out. It's going to waste cycles when there is no off-load, but
it also allows full offload, and means you don't need LITE to do Frag.
> > 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.
>
If I'm reading this wrong, sorry.
> > -- 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).
>
Possible yes.
> > -- 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.
Right - there are too many exit points for the discussion. The only 
place  I rceall
it traversal is when you have a proxy that reintroduces the checksum - 
which I
think is perverse to start with. So on checking, MAY is fine with me and
"might" improve is a more reasonable note (if we still wish that).
>
> > -- 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.
>
Does anybody still think that is a good idea?
> > 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.
DPLPMTUD works best with *just* padding packets (i.e. that carry no
payloads or fragments). It's just so much easier to run the algorithm.
> 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.
>
Something to indeed get correct.

Gorry
> >
> > Gorry
> >
> >
> >
> > On 18/07/2019, 09:47, [e-mail] 
> <mailto:[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] 
> <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] 
> <mailto:[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] 
> <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
> >>>>
> >>>
> >>
> >