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

[Gorry Fairhurst <[e-mail]>]

Hi all,

On 11/06/2021 12:43, [e-mail] wrote:
> 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 I recall, this is the last fragmentation is the last thing we need to 
nail-down. I'm  unsure
> 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.

On the one hand: I can ses it would be nice to have many things in the 
common standard and immediately available to use.

On the other hand: There seems to me to be singificantly more complexity 
and choice in managing reassembly than in the other aspects of UDP 
options- I can see how this could vary depending on usage: how much 
memory to use for reassembly, and what size is considered acceptable. To 
me, that makes it seems reasonable to ask whether a minimal implemention 
needs to offer this.

I know when someone in Aberdeen University implemented an earlier rev. 
of UDP-Options, this was the part that wasn't done.

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

I'd also like to see adoption:-). I think it would be nice if the 
UDP-Opt and UDP-DPLPMTUD could be published together with consecutive 
RFC numbers!

One way to avoid fragmentation can be to discover and cache a larger 
PMTU:-).

Gorry (as an individual tsvwg'er)

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