Subject: Re: [tsvwg] UDP options list of issues

From: "C. M. Heard" <[email-masked]>
Date: Fri, 25 May 2018 11:10:21 -0700

Greetings,

I am in general agreement with Joe's positions in the trailing message
below. Regarding some other things raised during the recent discussion:

   - Mitigation of potential DOS attack from potentially long list of TLVs:
   Gorry's suggestion to include a beefed-up discussion of this issue in the
   Security Considerations section of the document seems to me the correct
   approach.
   - Mandatory options: these are the options that must be supported by all
   implementations of the UDP options specification. IMHO they should comprise
   the minimal set of options needed for proper parsing and validation of the
   UDP options trailer, with the expectation that the list will *not* be
   further expanded. That minimal set is EOL, NOP, OCS, and LITE. Note that I
   have added LITE to the list in the current draft because an implementation
   that doesn't understand it will skip over it and start consuming part of
   the LITE data as if they were TLVs. That will not work. An implementation
   must be able to perform the swap/slide operation to put the LITE option in
   its proper place in order to parse the rest of the options trailer.

I see some other things not yet discussed that need correction or
clarification:

   - Options that depend on the contents of the option area: this set
   should include AE, alone. It should not include ACS, as ACS covers the
   payload alone, excluding the UDP header and the UDP options trailer. (Note
   that there is a typo in this connection at the top of page 7:
   s/independent/dependent/.)
   -  ACS coverage: does this include LITE data or not? This point needs to
   be made explicit. I can see arguments both ways, but I would like to see
   the LITE data included so that ACS can be used when FRAG is combined with
   LITE. If there is worry about a redundant checksum calculation in this
   case, just set the checksum the final FRAG option to zero and don't compute
   it.

Mike Heard

On Thu, 24 May 2018 11:43:47 -0700, Joe Touch wrote:

> Hi, all,
>
> I didn't see any comments on the following - it would be useful to hear
> from anyone on the list regarding the issues below so we can run a rev on
> the doc and pin these things down.
>
> So far I've heard from only two parties - I'd appreciate both them and
> anyone else providing a very brief list of positions on these...
>
> Thanks,
> Joe
>
>
>
> On 2018-03-04 14:39, Joe Touch wrote:
>
> Hi, all,
>
> IMO, we would benefit popping up a level to the list of issues and
> summarizing our views.
>
> Here's my attempt to do that.
>
> Joe
>
> ———
>
> Some assumptions:
> a) overhead is useful to minimize (efficiency and may reduce or avoid
> fragmentation)
> b) LITE capability must be preserved
> c) LITE+FRAG capability must be preserved
> d) this solution is not expected to outperform TCP (i.e., this is not an
> opportunity to redesign transport from scratch)
>
> - TLV vs fixed header
> motivated (AFAICT) by the desire to enable hardware optimization and/or to
> detect error/misuses of spare area
> no clear hardware benefit (given the option area "floats" relative to the
> UDP header,
> which floats relative to the IPv6 header TLV chain, and given it may not
> be word aligned)
> no clear benefit regarding packet errors or other spare area uses
> (both require either CS works or TLV chain parses, neither of which is
> likely for random errors or other misuses)
> fixed wastes at least 2 bytes if CS isn't used, (maybe 4-6 if supporting
> LITE/LITE+FRAG)
>
> - Optional CS vs. mandatory
> motivated (AFAICT) by the desire to avoid processing packets with errors
> (accidental or by others misusing the extra space)
> optional is needed to correlate to lack of UDP checksum (for some types of
> tunnels, e.g.)
> mandatory also implies fixed (above), which incurs 2-6 bytes of overhead
>
> - option-area checksum details
> size
> 8 if TLV, 16 if fixed; no clear problem with either choice
> algorithm
> no clear issue with using minor mods (foldover for 8 bit, invert or not)
> there are known dangers to using the complement of the sum
> (such that the sum and data zero-out), as noted by the Partridge paper in
> the 90s.
>
> - EOL vs option length field
> length would have to be 2 bytes; EOL is an optional one byte (not needed
> if no spare area remains)
> EOL thus saves up to 2 bytes when not needed (and it should generally not
> be needed at all)
> allowing EOL (i.e., allowing remaining unused spare area) implies that
> processing needs to stop at some point,
> either based on a counter or the data seen (and given that a CS loads data
> into a register anyway, there's no clear performance win to either approach)
> EOL itself is patterned after the TCP option of the same name
> and yes, leaving the spare area available for future use by other protocol
> extensions is intended here
>
> - does CS end when EOL is seen?
> yes, as currently specified
> as noted above, leaving the spare are for future standards is a goal
>
> My conclusion is that all the choices above either fail to improve the
> situation vs. our current proposal or increase overhead (or both). I don't
> yet see a reason why any of them warrant a change vs. the existing approach.
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 May 2018 12:49:47 -0700

On 2018-05-25 11:10, C. M. Heard wrote:

> Greetings, 
> 
> I am in general agreement with Joe's positions in the trailing message below. Regarding some other things raised during the recent discussion: 
> 
> * Mitigation of potential DOS attack from potentially long list of TLVs: Gorry's suggestion to include a beefed-up discussion of this issue in the Security Considerations section of the document seems to me the correct approach.
> * Mandatory options: these are the options that must be supported by all implementations of the UDP options specification. IMHO they should comprise the minimal set of options needed for proper parsing and validation of the UDP options trailer, with the expectation that the list will _NOT_ be further expanded. That minimal set is EOL, NOP, OCS, and LITE. Note that I have added LITE to the list in the current draft because an implementation that doesn't understand it will skip over it and start consuming part of the LITE data as if they were TLVs. That will not work. An implementation must be able to perform the swap/slide operation to put the LITE option in its proper place in order to parse the rest of the options trailer.

Good point; that's the kind of thing I'm looking for. 

> I see some other things not yet discussed that need correction or clarification: 
> 
> * Options that depend on the contents of the option area: this set should include AE, alone. It should not include ACS, as ACS covers the payload alone, excluding the UDP header and the UDP options trailer. (Note that there is a typo in this connection at the top of page 7: s/independent/dependent/.)

Agreed, OCS covers the option area, nothing else. 

> *  ACS coverage: does this include LITE data or not? This point needs to be made explicit.. I can see arguments both ways, but I would like to see the LITE data included so that ACS can be used when FRAG is combined with LITE. If there is worry about a redundant checksum calculation in this case, just set the checksum the final FRAG option to zero and don't compute it.

LITE - no, because that's the point of LITE. 

FRAG - things are supposed to work so that after the reassembly, the
overall result can have UDP options that affect the reassembled whole;
ACS would be one of these. At least that's how it's intended to work - I
need to check that this actually does what I had hoped. 

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 25 May 2018 17:19:12 -0700

On Fri, May 25, 2018 at 12:49 PM, Joe Touch wrote:

>    -  ACS coverage: does this include LITE data or not? This point needs
>    to be made explicit.. I can see arguments both ways, but I would like to
>    see the LITE data included so that ACS can be used when FRAG is combined
>    with LITE. If there is worry about a redundant checksum calculation in this
In that case, the next version of the draft should say that ACS applies
only to the non-LITE user data.

That still leaves a potential redundancy or gap when using ACS (other than
when FRAG is present, more on this below). Either the checksum in the UDP
header is non-zero, which means that the non-LITE user data is protected
both by the UDP checksum and ACS, or the checksum in the UDP header is
zero, which means that the UDP header has no protection.

> overall result can have UDP options that affect the reassembled whole; ACS
> would be one of these. At least that's how it's intended to work - I need
> to check that this actually does what I had hoped.
>
Yes, the draft actually says that:

   Any additional UDP options would follow the FRAG option in the final
   fragment, and would be included in the reassembled packet.
   Processing of those options would commence after reassembly.

   >> UDP options MUST NOT follow the FRAG header in non-terminal
   fragments. Any data following the FRAG header in non-terminal
   fragments MUST be silently dropped. All other options that apply to
   a reassembled packet MUST follow the FRAG header in the terminal
   fragment.

My apologies for not remembering that.

So one rational way to use FRAG would be to combine with ACS and LITE and
have the checksum in the UDP header turned on (so that the UDP headers in
the individual fragments are protected). The checksum in the terminal
fragment would be zero, while the ACS option in the terminal fragment would
cover the reassembled user data. A degenerate case would be where there is
one and only one fragment, and that would take care of the potential
gap/redundancy that I noted above.

I'm pleased to see that the UDP options proposal is robust in this way.

Mike Heard

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 26 May 2018 08:40:16 +0100

On 25/05/2018, 20:49, Joe Touch wrote:
>> I am in general agreement with Joe's positions in the trailing 
>> message below. Regarding some other things raised during the recent 
>> discussion:
>>
>>   * Mitigation of potential DOS attack from potentially long list of
>>     TLVs: Gorry's suggestion to include a beefed-up discussion of
>>     this issue in the Security Considerations section of the document
>>     seems to me the correct approach.
>>
See also comment to Joe's email.
>>
>>   * Mandatory options: these are the options that must be supported
>>     by all implementations of the UDP options specification. IMHO
>>     they should comprise the minimal set of options needed for proper
>>     parsing and validation of the UDP options trailer, with the
>>     expectation that the list will */_not_/* be further expanded.
>>     That minimal set is EOL, NOP, OCS, and LITE. Note that I have
>>     added LITE to the list in the current draft because an
>>     implementation that doesn't understand it will skip over it and
>>     start consuming part of the LITE data as if they were TLVs. That
>>     will not work. An implementation must be able to perform the
>>     swap/slide operation to put the LITE option in its proper place
>>     in order to parse the rest of the options trailer.
>>
I'm not convinced about LITE being required to implement, unless we 
agree on a simpler version of this.
>>   * Options that depend on the contents of the option area: this set
>>     should include AE, alone. It should not include ACS, as ACS
>>     covers the payload alone, excluding the UDP header and the UDP
>>     options trailer. (Note that there is a typo in this connection at
>>     the top of page 7: s/independent/dependent/.)
>>
>>   *  ACS coverage: does this include LITE data or not? This point
>>     needs to be made explicit.. I can see arguments both ways, but I
>>     would like to see the LITE data included so that ACS can be used
>>     when FRAG is combined with LITE. If there is worry about a
>>     redundant checksum calculation in this case, just set the
>>     checksum the final FRAG option to zero and don't compute it.
>>
> ACS would be one of these. At least that's how it's intended to work - 
> I need to check that this actually does what I had hoped.
>
> Joe
>
I can see value in drawing up this list and to discuss at the next TSVWG 
meeting.

Gorry

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 26 May 2018 07:21:29 -0700

On Sat, May 26, 2018 at 12:40 AM, Gorry Fairhurst <[email-masked]>
wrote:

>> I'm not convinced about LITE being required to implement, unless we agree
> on a simpler version of this.
>

Fair enough, but there are is an associated issue that needs to be
considered. The draft says (p. 7)

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

and then (. 10, section 5.5) also says

   >> When LITE is active, it MUST come first in the UDP options list.

These statements are contradictory unless LITE is a required option. It
would be possible to settle for a "weak" version of "required" by mandating
that an implementation has to know how to do the slide/swap operation to
parse LITE but does not need to actually receive and transmit LITE data.

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 26 May 2018 08:14:31 -0700

> Agreed, OCS covers the option area, nothing else.
I see that I botched the problem statement, and my proposed remedy is
incorrect. The issue is with the following requirement (see pp. 7-8 of the
draft):

   >> Only ACS and AE options depend on the contents of the option
   area. AE is always computed as if both the AE hash and ACS checksum

   are zero; ACS is computed as if the ACS checksum is zero. Future
   options MUST NOT be defined as having a value independent of the
   contents of the option area. Otherwise, interactions between those
   values, ACS, and UDP-AE could be unpredictable.

The above says ACS where OCS is intended and independent where dependent is
intended. The corrected text should read:

   >> Only OCS and AE options depend on the contents of the option
   area. AE is always computed as if both the AE hash and OCS checksum

   are zero; OCS is computed as if the OCS checksum is zero. 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 UDP-AE could be unpredictable.

With that correction I concur with the "MUST NOT define ..." requirement.

Similarly, the following text in Section 5.9 (p. 17)

   UDP-AE can be configured to either include or exclude TCP options,
   the same way as can TCP-AO. When UDP options are covered, the ACS
   option area checksum and UDP-AE hash areas are zeroed before
   computing the AE hash. It is important to consider that options not
   yet defined might yield unpredictable results if not confirmed as
   supported, e.g., if they contain other hashes or checksums that
   depend on the option area contents.

should be changed to read

   UDP-AE can be configured to either include or exclude UDP options,
   the same way as can TCP-AO. When UDP options are covered, the OCS
   option area checksum and UDP-AE hash areas are zeroed before
   computing the AE hash. It is important to consider that options not
   yet defined might yield unpredictable results if not confirmed as
   supported, e.g., if they contain other hashes or checksums that
   depend on the option area contents.

Also, given the ban on defining new options that depend on the contents of
the option area, is that last sentence really necessary?

--cmh

---

From: Joe Touch <[email-masked]>
Date: Sat, 26 May 2018 08:20:54 -0700

> On May 26, 2018, at 8:14 AM, C. M. Heard <[email-masked]> wrote:
> 
> Also, given the ban on defining new options that depend on the contents of the option area, is that last sentence really necessary?
> 

Not strictly, but it’s worth repeating IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 26 May 2018 08:22:53 -0700

On other points, largely agreed (I will need to double-check when I do the edits, but it looks like these are all typos).

Joe

> On Fri, May 25, 2018 at 12:49 PM, Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> Options that depend on the contents of the option area: this set should include AE, alone. It should not include ACS, as ACS covers the payload alone, excluding the UDP header and the UDP options trailer. (Note that there is a typo in this connection at the top of page 7: s/independent/dependent/.)
> 
> I see that I botched the problem statement, and my proposed remedy is incorrect. The issue is with the following requirement (see pp. 7-8 of the draft):
> 
> The above says ACS where OCS is intended and independent where dependent is intended. The corrected text should read:
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 26 May 2018 17:22:37 -0500

I'd like to support Joe on this ...

> Not strictly, but it’s worth repeating IMO.

Given that we're relying on UDP for a fair amount of new work and I knew
nothing about that ban, yes, please!

Spencer