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

[Magnus Westerlund <[e-mail]>]

Hi,

This is provided as an individual contributor. 

I read -07 of the UDP options on the plane over and have some comments.
After I did the review I have read through the many mails sent on this
topic the last few days. I may bring up things you have made progress
in that discussion but where I have missed the actual conclusion in my
read through. 

1. Section Abstract.

Why not move the abstract to before the Status of this memo to ensure
that is available on the first page? 

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" in the above sentence is a bit
confusing for something that is heading for standards track. I think
what is experimental needs to be clarified so that one immediately not
asking/thinking the future RFC should be/is experimental. 

3. Section 2. 

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

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

6. Section 5.1:

The "unused" part of the options area. 

>> All bytes after EOL MUST be ignored by UDP option processing.

First of all, isn't there an exception here that OCS MUST be calculated
over the whole Options Area, including this unused part? 

Secondly, is the potential for sticking anything into this area and
attempt to use that as a covert channel something that should be noted
in security considerations section? 

Third, does the draft need to define all three terms, i.e. that the
Options area consistes of the two parts, the one with actual options
and the unused part? When reading my brain had a tendency to think that
the Options area was actually only the area with options, not the whole
surplus area. 

7. Section 5.3:

   The Option Checksum (OCS) is conventional Internet checksum that
   covers all of the UDP options.

This first sentence is missleading as the later sentence indicates that
the OCS is calculated over the whole Options Area. Something it clearly
needs to be to ensure that the surplus area is checksum neutral. 

8. Section 5.3: 
The Option Checksum (OCS) is conventional Internet checksum that
   covers all of the UDP options.

-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------