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

[Magnus Westerlund <[e-mail]>]

Hi,

Trying to answer and comment on the issues that appears to need it.


On Tue, 2019-07-23 at 10:40 -0700, Joe Touch wrote:
> Some notes...
> 
> On 7/20/2019 11:42 AM, Magnus Westerlund wrote:
> > ...
> > 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.

Yes, there are complexities with allowing new options that are
dependent on the options area. However, it might be required, thus I
think we should think about if we can enable this. I think some forms
are clearly possible assuming that you have a way of indicating that
support of an option is 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.  
> > 
> > 
> > 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 .

Please include a citation. 
> 
> > 
> > 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.
> 

This is about the length of the ACS. I think using a 16-bit CRC appears
a bit weak for something that may be upto 64k. Thus using CRC32C might
be more appropriate for the ACS? 

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

Okay, but I think you should be more explicit that this is allowed. 
Although I don't see the reason for including a 0 byte LITE area is to
signal the capability. 

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

Not necessary. Although an error will build up if you do the
timestamping as part of the UDP options processing. However, the issue
of having no delta is that it adds the time between reception of the
latest packet in the flow and the transmission of the next outgoing
packet in the flow. To my understanding this UDP option will be
attached to the next outgoing packet, not be initiated by the
recepition of the UDP option. Thus, there could easily be many 10's of
milliseconds between reception of one Timestamp option and sending a
respnse. 

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

So, I do find this problematic and needing some important
clarifications. For the Authentication option I think it need to be
worked through so that it can actually be implemented. For example why
has Key-ID been removed? Are there important differences on the key
selector for UDP compared to TCP? For example are there always the 5-
tuple that matters or are there cases where the destination 3-tuple
that matters? 

When it comes to the encryption I think that is not really working in
this context. What are allowed plaintexts, are that UDP payload, Lite
DATA or only Options? Thus there are a lot needed to be defined for the
plaintext <-> cipher text transformation and how to deal with AEAD's
that have larger cipher text than plain text. 




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

Yes, it is an ongoing debate, and I want to make it clear that I do see
usage of it to enable certain type of futre options. But clearly the
scope of what it means needs to be defined. 


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

Yes, it is a requirement on new options. It can also be read as a
requirement on other nodes which was why I though it made sense to be
moved to another 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)

Sorry, I made a misstake. 


Cheers

Magnus Westerlund 


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