Subject: [tsvwg] UDP Options: on the coverage and presence of OCS

From: "C. M. Heard" <[email-masked]>
Date: Fri, 28 Jun 2019 09:22:23 -0700

Greetings,

Apologies for the late follow-up on this matter.

I notice the following on the "Other issues raised (2)" slide for the UDP
Options draft (draft-ietf-tsvwg-udp-options-07) from IETF 104:

• Other uses of the surplus area
– Currently allow this to be used if not defined as an option
– But then ALL BETS ARE OFF (we don’t ensure middlebox traversal,
  protect, etc.) – nor should we (they’re not ours)

• Other proposals have been considered before
– Fixed header (all options are optional)
– Lack of a required OCS (UDP CS=0 is valid, so should OCS=0, but
  without wasting space)
– Surplus area indicators are redundant with EOL

and the following on the "Pending Changes" slide:

• Middlebox traversal in Sec 12
 – Update to explain that new OCS works only when the remaining surplus is
   zero length (but this is user choice)

If I correctly understand what I have read, the proposed path forward is:
(a) allow the OCS to be optional to send under all circumstances
(b) do not have the OCS protect the surplus area (i.e., anything at the
    end of the options area past an EOL marker)

I disagree with both of those proposals, and instead advocate for these:
(a') OCS must be included by a sender whenever the UDP checksum is enabled
     (I agree that OCS seems pointless when the user has requested CS=0)
(b') OCS, when present, should provide coverage from the start of the
     options area (before LITE is moved on transmit or after it is moved on
     receive) to the end of the packet

Measures (a') and (b') would have the following advantages.

1.) The reliable presence of OCS (when UDP CS<>0) will provide a means of
    distinguishing UDP options use of the trailer area from possible
    existing non-standard uses of that area. Thanks to Tom Herbert for
    raising this point in the WG discussion.
2.) Middlebox traversal is provided for without the need for a separate OCS
    for the surplus area (why perform two computations when one will do).
3.) A receiver will easily be able to check the OCS without iterating
    through the entire set of UDP options to find the end. This is
    important, because we really do not want to process a bunch of TLVs
    without having some assurance that the length fields have not been
    corrupted. Note that both the IPv4 header checksum and the TCP segment
    checksum have this very desirable feature. That would not be the case
    if they did not cover both the options and any padding that may be
    present between the last option and the user data.
4.) It is no longer critical that OCS appear first (or second after LITE).
    The receiver knows to do the OCS check based on the the presence of a
    non-zero UDP checksum. OCS could appear at any convenient place.

Thanks and regards,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Fri, 28 Jun 2019 11:14:07 -0700

See notes below...

On 2019-06-28 09:22, C. M. Heard wrote:

> * Other uses of the surplus area
> - Currently allow this to be used if not defined as an option
> - But then ALL BETS ARE OFF (we don't ensure middlebox traversal,
> protect, etc.) - nor should we (they're not ours)
> 
> * Other proposals have been considered before
> - Fixed header (all options are optional)
> - Lack of a required OCS (UDP CS=0 is valid, so should OCS=0, but
> without wasting space)
> - Surplus area indicators are redundant with EOL
> 
> * Middlebox traversal in Sec 12
> - Update to explain that new OCS works only when the remaining surplus is

First, let's talk about these existing non-standard uses. Have any ever
been seen? 

Unless such uses persist, then we're adding work for a problem that goes
away. So we're basically designing for "those who don't follow
standards". Again, that's not how we design protocols (we'd never get
anywhere if we took this to the n-th degree). 

> for the surplus area (why perform two computations when one will do).

If you mean other uses, we don't need to support that. Other uses should
be defined as UDP options. We don't design for designers who don't
follow the rules (see "byzantine-robust" above). 

> present between the last option and the user data.

By definition, OCS requires iterating through the options. If your
concern is the need to parse to find then end, then let's define the end
as the end of the packet and declare that it would be a fatal error to
receive a packet with anything beyond the options. 

I.e., your real issue here is allowing anything beyond the options. So
let's not.

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 28 Jun 2019 22:12:12 -0700

On Fri, Jun 28, 2019 at 11:14 AM Joe Touch <wrote:
[ ... ]
> concern is the need to parse to find then end, then let's define the
> end as the end of the packet and declare that it would be a fatal
> error to receive a packet with anything beyond the options.
>
> I.e., your real issue here is allowing anything beyond the options.
> So let's not.

That would be fine with me. My concern is iterating through the options
before the option checksum (if present) has been verified. If the UDP
options occupy the entire trailer, and we tie the presence or absence of
the OCS to the presence or absence of the UDP checksum, then it's not
necessary to do so.

Mike Heard