Re: [tsvwg] design assumptions - draft-ietf-udp-options

[<[e-mail]>]

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