Re: [tsvwg] Review comments for draft-ietf-tsvwg-udp-options-07

[Joe Touch <[e-mail]>]

Some notes...

On 7/20/2019 11:42 AM, Magnus Westerlund wrote:
> ...
> 1. Section Abstract.
>
> Why not move the abstract to before the Status of this memo to ensure
> that is available on the first page? 

The RFC Editor handles the final format anyway.

> 2. Section 1. 
>
>    This document defines an experimental extension to UDP that provides
>    space for transport options including their generic syntax and
>    semantics for their use in UDP's stateless, unreliable message
>    protocol.
>
> I think the use of "experimental" 

That's old text and will be changed.

> ...
>
> 3. Section 2. 
>
> Why not use RFC 8174 boiler plate and reference that?
> https://datatracker.ietf.org/doc/rfc8174/

Because DeLorean and hot tub are both in the shop.

Yes, we can add this now.

> ...
> 4. Section 5. 
>
> "Future options MUST NOT be
>    defined as having a value dependent on the contents of the option
>    area. Otherwise, interactions between those values, OCS, and AE
>    could be unpredictable."
>
> Is this MUST NOT required?

MUST NOT depend on the value of other options - certainly can depend on
their own option field.

Because it creates circularities between options and affects the order
in which they appear and/or are completed. The only dependencies could
be those between options defined at the same time, but they ought to be
sub-fields of a single option IMO.

I.e., options should be able to be processed independently, and this
rule follows from that.

>  Or is it that it simply MUST define any
> interactions with the option area prior to OCS and AE. Any if any
> additional such options exist, they need to define there realtive
> interaction. Making it harder and harder to extend this type of options
> but not impossible.  
>
> 5. Section 5:
>
>    >> Except for NOP, each option SHOULD NOT occur more than once in a
>    single UDP datagram. If a non-NOP option occurs more than once, a
>    receiver MUST interpret only the first instance of that option and
>    MUST ignore all others.
>
> And four paragraphs later:
>
>    >> Required options MUST come before other options. Each required
>    option MUST NOT occur more than once (if they are repeated in a
>    received segment, all except the first MUST be silently ignored).
>
> I don't see the second sentence having any value compared to the
> privious paragraph. 

Will fix.

> 6. Section 5.1:
>
> The "unused" part of the options area. 

That's going away. There is no such thing anymore - this was decided on
the list a while back.

And yes, some terminology definitions may be useful to add.
> 7. Section 5.3:
>
>    The Option Checksum (OCS) is conventional Internet checksum that
>    covers all of the UDP options.
OCS description is being revised already.
> 8. Section 5.3: 
> The Option Checksum (OCS) is conventional Internet checksum that
>    covers all of the UDP options.
>
> Shouldn't this be explicit that this is an 16-bit Internet checksum?

It will be, but Internet checksums are 16 bit, ones' complement,
inverted. I can cite the RFC .

> 9. Section 5.3: 
>
>    >> The OCS checksum MUST be half-word coordinated with the start of
>    the UDP options area.
>
> I don't understand what "half-word" coordinated here means. I take it
> to mean that the individual bytes of the 16-bit checksum result needs
> to be stored in the corresponding byte position mod 2 from the start of
> the options area. This could be significantly clearer.

It will be.

> 10. Section 5.3: 
>
>    The adjustment above helps enable that OCS, together with the other
>    options, result in an overall zero ones-complement sum. This feature
>    is intended to potentially help the UDP options traverse devices
>    that incorrectly attempt to checksum the surplus area (as originally
>    proposed as the Checksum Compensation Option, i.e., CCO [Fa18]).
>    Note that this incorrect checksum traversal feature is defeated by
>    the use of LITE, whether alone or with FRAG, because the LITE area
>    is deliberately not covered by OCS. It also is defeated by the use
>    of a zero UDP checksum (i.e., UDP checksum disabled).

We need to converge on what we want to do with LITE and FRAG before it's
useful to wordsmith this area.

...

> 11. Section 5.4:
>
> I know that it has been discussed somewhat, isn't a 16-bit a bit weak
> for the potential UDP payload lengths? 

No more weak than for TCP. ACS is available if desired as an alternative.

> ...
>
> 12. Section 5.5:
>
> So LITE has been heavily discussed this last week.
We need to discuss LITE and FRAG in the context of the design and
processing rules and our design requirements. It isn't helpful to debate
a solution if we're not all working on the same problem.
> 13. Section 5.3:
>
>    3. If the LITE data area is 4 bytes or longer, swap all four bytes
>       of the LITE option with the first 4 bytes of the LITE data area
>       (Figure 11). If the LITE data area is 0-3 bytes long, slide the
>       LITE option to the front of the LITE data area (i.e., placing the
>       0-3 bytes of LITE data after the LITE option).
>
> Is there a reasons to actually send a 0 byte LITE data area? I would
> think that would no LITE option? Or is this for indicating support? In
> any case a 0 byte LITE data area is a no-operation anyway.

It's a degenerate case that we don't need to test our way out of or
declare an error.

> 14. Section 5.9:
>
> So if I understand this option, the measurement of the RTT contains an
> error factor that is equal to the time between the peer received an TS
> options and sending a response. Why not include the peers delay between
> reception and sending a response in third field? 
Because that implies that packets are timestamped upon receipt BEFORE
being processed. That's too heavyweight a requirement, IMO.
> 15. Section 5.10:
>
> So I think the authenticaiton part you at least have some idea of how
> to build here. The encryption appears to be missing significant parts.
Yes, it's not intended to be complete. It's a framework in which AE-like
solutions can exist.
> I would also expect the case where you can get key-reuse could be a
> significant issue for a number of encryption algorithm. 

That's external to the framework.

> What is the intention here, I see this section as a strawman for
> something that could be done. But are there interest to make it really
> well specified, or should it be broken out to an extension draft? 

The intent is a placeholder for crypto capabilities that need an
exception to the "independence" and ordering rules in sec 7 and 8.

> 16. Section 7. 
>
> This was also touched upon, when it comes to new options. I have seen
> that for protocol that actually defines new extensions where the peer
> really need to understand an extension to be able to process the
> message it is good to have these capabilities. So a potential here is
> to enable indication of an "Option requrired to be understood". This
> can either be a range in the number space or a bit somewhere. The lack
> of an error indication framework do make things more complicated if one
> define that one skip to process all options in case one is required and
> not understood. 
We've been discussing that. Given - as you note - the need for
coordination, I don't see how the bit is particularly helpful, but
that's the debate.
> 17. Section 7.
>
>    >> Options MUST NOT be modified in transit. This includes those
>    already defined as well as new options. New options MUST NOT require
>    or intend optionally for modification of any UDP options, including
>    their new areas, in transit.
>
> I think this should be moved elsewhere where it would be clearer that
> this do apply to all options defined or future. 

Where else would it be moved?  Defining how new options are defined is
the whole title and purpose of that section.

> 18. Section 8.
>
> The Processing list appears to have an assumption that there is only
> one option. Otherwise this leads to not processing all things before
> delivering it higher layer. 

I don't see that; can you explain why you do? (the text mentions
multiple options all over the place, including the pseudocode)

Joe