Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

[[e-mail]]

Hi Joe, all,

Regarding the FRAG option, I'm not sure there was a consensus this is a MUST to implement/support. 

Unless I'm mistaken, I didn't even remember a conclusion for one of the main threads when FRAG and other "design assumptions" were discussed back in 07/2019.

As indicated in https://mailarchive.ietf.org/arch/msg/tsvwg/rfh1wBYzlIHIzeVQruT5BVd8BRA/, I do still think that we would better focus on key foundations and build over them. FRAG can be defined properly in a separate document. It can be tagged as unsafe but it does not need to be mandatory to implement. 

Likewise, I do still think it is weird to assign codepoints for REQ/RES, but no details about the processing of these options is provided. These options are better covered in Gorry's draft and kinds assigned there. BTW, I'm still hoping a call for adoption can be issued for it. 

Cheers,
Med

> -----Message d'origine-----
> De : tsvwg [mailto:[e-mail]] De la part de Joseph
> Touch
> Envoyé : vendredi 11 juin 2021 06:08
> À : C. M. Heard <[e-mail]>
> Cc : TSVWG <[e-mail]>
> Objet : Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12
> 
> Hi, Mike,
> 
> I’ve been waiting for others to participate, but given it’s been a
> week…
> 
> First, I want to thank you for the deep review - it’s sincerely
> appreciated.
> 
> I’ll also be the first to admit there are more than a few places
> where it needs another pair of eyes and may have inconsistencies. So
> let’s start by assuming that those are dealt with separately. At a
> minimum, assume that most of the obvious corrections will be
> included in the next update.
> 
> I will respond  to the revised LITE option in reply to your other
> post.
> 
> On the primary issues, below summarizes my perspective. I hope
> others on the list will weigh in.
> 
> Joe
> 
> -----
> 
> - regarding fragment/reassembly as being required
> 	This is one of the primary current intended use cases and
> motivations for UDP options.
> 	That’s why it’s currently a MUST support and why I do not
> think that should change.
> 
> - regarding removing EOL
> 	Removing EOL raises several questions: can other options use
> that data? Do we care if it’s a covert channel? etc.
> 	It’s simpler to declare it zeroes and let EOL be the trigger
> to use a loop with a branch predictor hint (likely zero).
> 	At a minimum, everything past EOL MUST be covered by OCS
> (otherwise OCS would need to parse all options to find EOL).
> 
> - regarding increasing NOPs
> 	There was a concern in letting these be unlimited; we can
> increase to 7, 15, or even 31 (high enough for future-proof seems
> 	to open a DOS problem; IMO, DOS detection should just check to
> see if this is a persistent load, not a specific number)
> 
> - regarding UNSAFE option format
> 	Yes, we could pick a range rather than making them longer, but
> IMO they aren’t likely except as already accounted for, so
> 	allocating space from the main range is a waste.
> 	However, if we did allocate from the range, we should NOT do
> so with a single bit; that gives the false impression
> 	that a given option value has two variants - safe and unsafe,
> and that’s not the case.
> 
> - regarding AE being safe
> 	This is not considered unsafe for two reasons:
> 	1. A(authentication) isn’t unsafe
> 	2. Encryption should only be used when sending packets to a
> party that is keyed; that can/should be known or checked before use
> anyway.
> 	i.e., there’s never a case where you send encrypted text to a
> party you don’t know should be ready.
> 
> ----


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.