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

[Joe Touch <[e-mail]>]

Hi, Magnus,

> On Jul 24, 2019, at 11:15 AM, Magnus Westerlund <[e-mail]> wrote:
> 
>> ...
>> 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. 

I think we can safely (!) say that no options can depend on the currently defined ones. At best, new sets can depend on each other when proposed as a set, but like I said, that might be better accomplished as subfields within a single option.

> ...Internet checksums are 16 bit, ones' complement,
>> inverted. I can cite the RFC .
> 
> Please include a citation. 

Will do.

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

We had converged on 16-bit previously (and on the CCITT variant in particular) through list discussion, but if we need to open this up again, we can.

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

I can’t quite parse your last sentence, however, the required-to-implment options are all confirmed by the presence of a valid OCS. There should not be a need to check them individually - that’s needed for optional-to-implement ones in this first set and all that come later.

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

We can require that UDP packets with timestamps record their arrival time when received, but then that changes what the timestamp means. So we need to decide what it means - is it “echo the time when you did receive processing” in the next packet, or “tell me the time you emit the next packet”. 

I don’t think it’s particularly useful to send both all the time. It may be useful to have this decided by a flag, if we can sacrifice a bit of the time field.

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

Basically, when we wrote that down, the intent was that the endpoints can use that field however they want. They already need to have agreed on a key and an algorithm. That means the digest field can be used however they want - e.g., you and I can agree that the first two bytes are the keyIDs like TCP-AO, someone else can parse them differently.

The details can (and IMO should) be left to a separate document (or documents).

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

AE when used for encryption would only cover the payload. Since it’s between endpoints that already coordinate use of a key, they would already know it was supported.

And the option fields - which come AFTER AE - can be encrypted or not, depending on pre-agreement, just as with the AO encryption variant.

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

It would help to have an example. So far, the only example given was to use it for compression of the UDP user data, which is prohibited by other rules in Sec 7. If such compression were offered, the compressed field would need to be within the option, meaning it could be silently ignored individually.

> But clearly the
> scope of what it means needs to be defined. 

Yes, that too. But a useful, viable driving example would be helpful.

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

Ahh - modified in transit is distinct and something we can put elsewhere, sure.

Joe