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

From: Magnus Westerlund <[email-masked]>
Date: Sat, 20 Jul 2019 18:42:48 +0000

Hi,

(Now complete)

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/

The RFC-editor will not change this, and I think there is point to
reference the common wording and resource, even if the result is
equivalent. 

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.

Shouldn't this be explicit that this is an 16-bit Internet checksum? 

9. Section 5.3: 

   >> The OCS checksum MUST be half-word coordinated with the start of
   the UDP options area.

I don't understand what "half-word" coordinated here means. I take it
to mean that the individual bytes of the 16-bit checksum result needs
to be stored in the corresponding byte position mod 2 from the start of
the options area. This could be significantly clearer.

10. Section 5.3: 

   The adjustment above helps enable that OCS, together with the other
   options, result in an overall zero ones-complement sum. This feature
   is intended to potentially help the UDP options traverse devices
   that incorrectly attempt to checksum the surplus area (as originally
   proposed as the Checksum Compensation Option, i.e., CCO [Fa18]).
   Note that this incorrect checksum traversal feature is defeated by
   the use of LITE, whether alone or with FRAG, because the LITE area
   is deliberately not covered by OCS. It also is defeated by the use
   of a zero UDP checksum (i.e., UDP checksum disabled).

What is actually menat with the two last sentences? My understanding
make me conclude what you are saying is that in case LITE Is used and
the UDP checksum is !=0 then the LITE data area plus options area will
not be chekcsum neutral, nor can it as the Data Lite area is accepting
corruption and thus can't be covered. Instead of calling it defeated
simply stating that they are non functionally compatible. 

And in the case of the UDP checksum is 0, do we have any data that it
matters if the options area is checksum netural or not? As the receiver
know it can't evaluate it, it can determine that something is wrong.
Thus, I think the word defated becomes very strange here. 

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? Especially when using it
combined with FRAG as then we start talking about receiver buffer
limiations to some degree so that 16kbyte or 64kbyte is not impossible.

I think a clarification in regards to FRAG should be present in this
section, and not only in the FRAG section. 

12. Section 5.5:

So LITE has been heavily discussed this last week. Gorry also
referenced me, which was a comment to the WG chairs. So lets provide my
view on the LITE here. 

First of all the intended usages should be made clearer so that it is
easier to evalute if the solution fits the bill. Becasue comparing this
fully with UDP-Lite ends up with one part which is problematic. Namely
the intention of having the link layer let bit errors leak up. With the
designs possible for LITE in UDP options such mechansism to puncturing
the coverage of the link layer becomes a bit complex. I also think they
are very unecessary. 

From my perspective the UDP-Lite standardization was driven with the
intention to enable for example an IP/UDP/RTP/AMR (Encoded voice) to be
mapped onto a custom radio bearer in the mobile networks to minimize
the cost of transport. Thus using a radio bearer adapted to those
packets only, and with a controlled weaker channel coding for the least
important bits was a possibility. This was already done in the ciruit
switched radio bearers used for voice in GSM as well as in 3G UMTS
systems. So this was in large parts standardized, but to my knowledge
never deployed, as mobile systems use of putting their cellular voice
services on IP packets wasn't becoming common until 4G where LTE
doesn't had any circuit switched voice, thus VoLTE becoming necessary. 

Also I think media is becoming less and less a good use case for the
above described allowance of errors. Becasue as encoding progresses the
redundancy in the encoding has become so low that purposeful
concealemnt of lost data is better than erronous data, although both
are bad options compared to receiving it.

Also, if one are going to have a link layer weaken its checksums or
maybe even how it does channel coding, then one needs to know that the
resulting error profile fits what being subject to that. That requires
an integration that is contrary to what makes IP successful. 

So I think if one skip the intention to support any L2 integration one
simplifies the requirement. Thus usage of LITE should be focused on
cases where we for other reasons have data that don't require
checksums. Which I think is primarly tunnels that like to skip the
checksumming of what they encapsulate. Here I see a point that LITE can
enable checksumming the IPv6 + UDP headers instead of zero checksum. 

The other case is the FRAG combination. With the exception for tunnel
like cases, I am of the opinion that as FRAG anyway needs some prior
negotation, the legacy receiver reason for using LITE+FRAG is very
limited. 

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.

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? 

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.
I would also expect the case where you can get key-reuse could be a
significant issue for a number of encryption algorithm. 

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? 

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. 

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. 

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. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 21 Jul 2019 14:19:51 -0700

Third-party comments below.

> interaction. Making it harder and harder to extend this type of options

Thank you for bringing this up. I'm inclined to agree with the text
as-is but the point is worth consideration. If a plausible use case
could be demonstrated that would help to cinch the case.

> over the whole Options Area, including this unused part?

+1 -- that's essential for proper checksum compensation (more below)

> in security considerations section?

Seems right, and maybe even a proviso that any fill after EOL SHOULD
be all zeroes. There is a use case for this, namely PLPMTUD probe
packets, but in that case what's in the fill doesn't matter.

> the Options area was actually only the area with options, not the whole

I also have had issues with two distinct uses of "required option" --
one seems to mean "mandatory for conforming implementations to
implement" and another means "required by the receiver to be present."

> needs to be to ensure that the surplus area is checksum neutral.

The OCS does NOT make the surplus area checksum neutral. It actually
needs to sum to the 1's complement of the difference between the
IP Payload Length and the UDP length. The reasons are made clear in
https://tools.ietf.org/html/draft-fairhurst-udp-options-cco. Joe
already has stated this correction is in his cache but this mis-statement
comes up so often that I want to mention the point for everyone else.

As a side note, there is another reason beyond working around middlebox
brain damage to do it this way: it provides checksum protection for the
IP Payload Length, which in IPv6 is otherwise unprotected (that stands
in contract to IPv4, where there is an IP Header Checksum to protect the
Total Length).

> section, and not only in the FRAG section.

In fairness, the protection is no worse that what the UDP checksum
provides when used in conjunction with IP fragmentation (assuming
that the UDP checksum is used in the LITE+FRAG packets.

That said, several of us have advocated to use OCS as a per-fragment
checksum, which provides protection as good as TCP does for its data,
and allow a stronger post-reassembly to be used at the discretion of
the sender (more on this below). ACS would be perfect for that.

> an integration that is contrary to what makes IP successful.

Thank you for fleshing out those details. It's basically what I had
gathered from perusing available literature, but it's good to have
that impression confirmed.

> enable checksumming the IPv6 + UDP headers instead of zero checksum.

+1

> negotation, the legacy receiver reason for using LITE+FRAG is very

Indeed, FRAG (with or without LITE) cannot be sent to a legacy
implementation with the expectation that it will work. FRAG without
LITE will cause the legacy implementation to get corrupted data. But,
if FRAG is firewalled behind LITE it won't (which was my motivation for
proposing that). The other advantage is that it eliminates duplicate
per-fragment and post-reassembly checksums, since LITE data is excluded
from OCS. That spoils middlebox checksum compensation, but that fact
was not known when the design was proposed.

I've come to the point of view that we need a different solution, one
that divorces FRAG from LITE but which still puts all of the fragment
data in the surplus area. Several ideas have been proposed that do
that; if you have have not seen them and don't have the time to go
through all the traffic to find them, contact me off-list and I will
send you the links.

> define that one skip to process all options in case one is required and

+1 -- we definitely need an "Option required to be understood"
indication. Joe has correctly pointed out that we need to consider
Section 7 and Section 8 as an organic whole; my take is that they
need significant rework. I'll post detailed comments on that later.

Thanks for the review and all the detailed info on the UDP-Lite use case.

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Jul 2019 10:40:00 -0700

Some notes...

On 7/20/2019 11:42 AM, Magnus Westerlund wrote:
> ...

The RFC Editor handles the final format anyway.

> I think the use of "experimental" 

That's old text and will be changed.

> ...

Because DeLorean and hot tub are both in the shop.

Yes, we can add this now.

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

>  Or is it that it simply MUST define any

Will fix.

> The "unused" part of the options area. 

That's going away. There is no such thing anymore - this was decided on
the list a while back.

And yes, some terminology definitions may be useful to add.
>    covers all of the UDP options.
OCS description is being revised already.
> 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 .

> the options area. This could be significantly clearer.

It will be.

>    of a zero UDP checksum (i.e., UDP checksum disabled).

We need to converge on what we want to do with LITE and FRAG before it's
useful to wordsmith this area.

...

> for the potential UDP payload lengths? 

No more weak than for TCP. ACS is available if desired as an alternative.

> ...
>
> 12. Section 5.5:
>
> So LITE has been heavily discussed this last week.
We need to discuss LITE and FRAG in the context of the design and
processing rules and our design requirements. It isn't helpful to debate
a solution if we're not all working on the same problem.
> 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.

> 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.
> 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.
> significant issue for a number of encryption algorithm. 

That's external to the framework.

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

> define that one skip to process all options in case one is required and
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.
> 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.

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

Joe

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Jul 2019 18:15:19 +0000

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:
> MUST NOT depend on the value of other options - certainly can depend
> on their own option field.
> 

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. 

> inverted. I can cite the RFC .

Please include a citation. 
> No more weak than for TCP. ACS is available if desired as an

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? 

> It's a degenerate case that we don't need to test our way out of or

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. 

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

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

> coordination, I don't see how the bit is particularly helpful, but

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. 

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

> multiple options all over the place, including the pseudocode)

Sorry, I made a misstake. 

Cheers

Magnus Westerlund

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Jul 2019 20:09:52 -0700

Hi, Magnus,

> On Jul 24, 2019, at 11:15 AM, Magnus Westerlund <[email-masked]> wrote:
> 
>> ...

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,

Will do.

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

> Although I don't see the reason for including a 0 byte LITE area is to

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.

> milliseconds between reception of one Timestamp option and sending a

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.

> tuple that matters or are there cases where the destination 3-tuple

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

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

> 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

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

> moved to another section. 

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

Joe