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

[<[e-mail]>]

Re-, 

I think we are in agreement about the splitting of the core functionalities vs. others. 

I have a question about this:

> For DPLPMTU (#6) the complexity is in another spec (which seems correct
> to me).

I guess you are referring to what is used to be Section 6.2 of DPLPMTU (-07), but that section was removed from your draft for some reason. 

I fail to find the same level of details/discussion in the current udp-options I-D. For example, how nonce (token in DPLPMTU) is defined, used, etc. 

Worse, udp-options I-D states:

==
Their use is described as part of the
   UDP variant of packetization layer path MTU discovery (PLPMTUD)
   [Fa19].
==

But DPLPMTU I-D says the following: 

==
   Support for using DPLPMTUD with UDP-Options is defined in the UDP-
   Options specification [I-D.ietf-tsvwg-udp-options].
==

Cheers,
Med

> -----Message d'origine-----
> De : tsvwg [mailto:[e-mail]] De la part de Gorry Fairhurst
> Envoyé : jeudi 18 juillet 2019 12:39
> À : [e-mail]
> Cc : gorry Fairhurst
> Objet : Re: [tsvwg] design assumptions - draft-ietf-udp-options - trying
> to see the bigger picture
> 
> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>