[tsvwg] Comments on draft-ietf-tsvwg-udp-options-19

[Magnus Westerlund <[e-mail]>]

Hi,

Sorry for the late review, but I hope these comments can be addressed anyway. I think the UENC is blocking progress in its current form.


Section 6:

They commence

   with a 2-byte Option Checksum (OCS) field aligned to the first 2-

   byte boundary (relative to the start of the IP datagram) of that

   area, using zeroes for alignment.

   >> Option area bytes used for alignment before the OCS MUST be zero.

To my understanding there can only be zero or one padding byte to achieve 16-bit alignment for the OCS. Thus, the plural of bytes used for alignment should be corrected. I would also consider if one needs a stronger wording that OCS MUST be aligned and that there can only be zero or one zero value byte used for padding.

Section 7:


When the UDP checksum is zero, the OCS MAY be unused, and is then

   indicated by a zero OCS value.

I find this formulation a bit confusing. My problem is the use of the word “unused”. I think I would prefer a formulation more like this:

When the UDP checksum is disabled, i.e. has a zero value, the OCS MAY be also disabled, and this is indicated by a zero OCS value.


Section 7:


When not used (i.e., containing zero), the OCS is assumed to be

   "correct" for the purpose of accepting UDP datagrams at a receiver

   (see Section 12).

I find this sentence strange. First, I don’t understand how it can be plural “UDP Datagrams” how can this packets OCS affect other packets? Secondly, is the intention to say that is OCS is disable, the UDP options should be processed as if OCS !=0 and passed?


Section 8:


   >> UNSAFE options are used only in with the FRAG option, in a manner

   that prevents them from being silently ignored but passing the UDP

   payload to the user when not supported.

This sentence has some issues. Is the intention to say “in combination with the FRAG option”?

I would also note the >> despite having no normative word. Was the intention to say MUST be used only in combination with the FRAG option?


Section 8:

   >> Receivers supporting UDP options MUST silently drop all UDP

   options in a datagram containing an UNSAFE option when any UNSAFE

   option it contains is unknown. See Section 10 for further discussion

   of UNSAFE options.

There is also the this sentence higher up being very similar:
   >> An endpoint supporting UDP options MUST treat unsupported options
   in the UNSAFE range as terminating all option processing.

And Unless FRAG is a MUST with UNSAFE then I think dropping the UDP DATA when unknonwn UNSAFE options are encountered is a MUST.

Section 8:

   Receivers cannot generally treat unexpected option lengths as
   invalid, as this would unnecessarily limit future revision of
   options (e.g., defining a new APC that is defined by having a
   different length). The exception is only for lengths that imply a
   physical impossibility, e.g., smaller than two for conventional
   options and four for extended length options. Impossible lengths
   should indicate a malformed surplus area and all options silently
   discarded. Lengths other than those expected should result in safe
   options being ignored and skipped over, as with any other unknown
   safe option.

Do I understand this correct to imply that if a receiver sees a TIMESTAMP option with length value of 14 it could be okay and should only be interpret as TIMESTAMP instance that the receiver don’t understand. Because first I was wondering how it could function if one couldn’t follow the L value in TLV to find the next. Maybe what to do for an receiver to do when the length don’t matches what the implementation support.

I would note that in relation to the next paragraph what “option lengths” mean appear to be inconsistent. I would probably use “sum of length of the options”


   >> Option lengths MUST NOT exceed the IP length of the overall IP

   datagram. If this occurs, the options MUST be treated as malformed

   and all options dropped, and the event MAY be logged for diagnostics

   (logging SHOULD be rate limited).


Section 8:

The requirement that must-support options come before others is

   intended to allow for endpoints to implement DOS protection, as

   discussed further in Section 22.

I would note I think this DOS is Denial of Service protection, while DOS acronym is reused in section 9.4.


Section 9.4:


The FRAG option does not need a "more fragments" bit because it

   provides the same indication by using the longer, 12-byte variant,

   as shown in Figure 11.

“same indication” is unclear. I assume you mean that “last fragment” is indicated through the 12-byte variant.
The use of the 10 byte simply means “more fragments = yes”.

Section 9.4:
I think the Datagram Option start is very unclear as there appear to exist an assumption that one start from one single large IP/UDP packet that is then with the help of the UDP FRAG option is transformed into multiple packets. I would think a figure with pointer what the values are and how the created packets with FRAG really look in structure.

I mean later parts of the section makes the process clearer, but there are inconsistencies in naming. And for example the original IP packet does not exist at all in the numbered list.

Section 9.7:

What is not clear in this section is if a REQ, actually has any impact on the receiver. For example does it imply anything more than that the receiver should include a RES in the next UDP packet sent back on this address port pairs?

Section 9.9:

I think the introduction to this section could be clearer on that AUTH is dependent on out of band agreement on mac algorithm, KDF algorithm and keying material between endpoints.

Section 10:


>> Applications using UNSAFE options SHOULD NOT also use zero-length

   UDP packets as signals, because they will arrive when UNSAFE options

   fail.

Wouldn’t this be better to state as:


>> Applications using UNSAFE options SHOULD use non-zero-length

   UDP packets as signals, because they will arrive when UNSAFE options

   fail.

Section 10.1


Its fields, coverage, and processing are the same as

   for AUTH, except that UENC encrypts the user data and (when

   configured to) the portion of the surplus area that occurs after

   UENC, although it can (optionally) depend on options that precede it

   (with certain fields zeroed, as per AUTH, e.g., providing

   authentication over the surplus area).

This is a fairly convoluted sentence. First, it creates a lot of configuration options that the out-of-band establishment needs to agree. Secondly, it becomes very unclear how you form the clear text. Also, it appears to lack a normative specification for how to do this. What I read here I don’t see how UENC can be considered defined without having To18 as a normative specification. Considering that this is appear to be an abandoned draft I would suggest that this option is dropped.


[To18]    Touch, J., "A TCP Authentication Option Extension for

             Payload Encryption," draft-touch-tcp-ao-encrypt, Jul.

             2018.

I would also note that most encryption algorithms would be dependent on unique IVs per UDP datagram. That would need definition and likely inclusion. There are also payload expansion factors to take into account especially if applying AEAD algorithms.



Section 12:

         if the UDP checksum fails then

               silently drop the entire UDP packet (per RFC1122)

           if the UDP checksum passes or is zero then

               if ((OCS != 0 and fails or OCS == 0) and UDP CS != 0)

               or ((OCS != 0 and passes) and UDP CS == 0) then

                   deliver the UDP user data but ignore other options

                   (this is required to emulate legacy behavior)

               if OCS != 0 and passes or OCS == 0 when UDP CS != 0 then

                   deliver the UDP user data after parsing

                   and processing the rest of the options,

                   regardless of whether each is supported or succeeds

                   (again, this is required to emulate legacy behavior)

There is no specification for what to do when UDP Checksum =0 and OCS=0.