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

[Magnus Westerlund <[e-mail]>]

Hi,

I am not done with this email, manged to accidentally hit send. Will
follow up with complete message. 

/Magnus

On Sat, 2019-07-20 at 17:25 +0000, Magnus Westerlund wrote:
> 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]
----------------------------------------------------------------------