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

["C. M. Heard" <[e-mail]>]

On Thu, Jun 10, 2021 at 9:08 PM Joseph Touch <[e-mail]> wrote:

> Hi, Mike,
>
> I’ve been waiting for others to participate, but given it’s been a week…
>
>
Joe, I share your desire to see greater WG participation. Silence is not a
good sign :-(


> On the primary issues, below summarizes my perspective. I hope others on
> the list will weigh in.
>
>
I will give a brief answer to each point and encourage others to weigh in.
These comments are mainly to clarify my position


> - 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.
>
>
There have been some other comments on this (thank you, Med and Gorry) and
I will respond separately.


> - 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).
>
>
I would be satisfied if the sender MUST set all data past EOL to zero and a
provision that the receiver MAY check this.

IOW my major objection is requiring that the receiver check this. If the
receiver is required to check, the fill may as well be NOPs.

I agree that there is no need to make provision for other uses of this area
and that it MUST be covered by OCS.


> - 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)
>
>
OK by me. All I asked for was to allow eight-octet alignment.


>
- 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.
>
>
First, let me say that the method proposed in the -12 draft will work. I
just don't think it's an efficient way to go. If there is consensus in the
WG for what's in the -12 draft I can live with it.


>
- 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.
>
>
I do not agree that this behaviour is optimum ... I'm of the opinion that
authentication should be a contract between the two ends. TC-AO could not
have done anything else because unknown TCP options are ignored. UDP-AE can
do better. That being said, if there is consensus in the WG for what's in
the -12 draft I can live with it.

Mike Heard