Subject: [tsvwg] Comment on draft-ietf-tsvwg-udp-options-02.txt

From: Tom Herbert <[email-masked]>
Date: Sun, 21 Jan 2018 13:16:58 -0800

Hi Joe,

A few comments:

I'm not sure what "required options" are and can't find a definition
in he draft. The term "required option" seems to be a bit of an
oxymoron.  May this refers to options that a individual receivers can
require to be present?

>From the doc: A rule that "no more than 3" consecutive NOPs creates
its own DOS vulnerability. Can you elaborate of this vulnerability?

In looking at polynomials for CRC-16 for GUE, I didn't get a strong
sense that CRC-16-CCITT is ubiquitous. CRC-16 (CRC_16-IBM) is
supported by USB, ANSI standard, and is implemented in Linux
(CRC-16-CCITT currently is not). For GUE, we defined options for
either CRC-CCITT or CRC-16, it might be worth considering that for UDP
options.

ACS and authentication fail to protect the UDP options in the case
that the kind field for these options is corrupted. For instance, if
an ACS checksum kind field flips from 3 to zero, the receiver would
see EOL instead of ACS. I believe this is a general problem any time
checksum or security is put in options. For GUE, we added a disclaimer
like this (draft-ietf-intarea-gue-extensions-02)

"Note that the GUE checksum does not protect against the checksum flag
 (K flag) being corrupted. If an encapsulator sets the checksum flag
and option but the K bit flips to be zero, then a decapsulator will
incorrectly process the GUE packet as not having a checksum field.

To mitigate this issue an encapsulator and depcapsulator might agree
that checksum is always required. This agreement could be established
by configuration or GUE capability negotiation"

Tom

---

From: Joe Touch <[email-masked]>
Date: Sun, 21 Jan 2018 14:47:02 -0800

HI, Tom,

> On Jan 21, 2018, at 1:16 PM, Tom Herbert <[email-masked]> wrote:
> 
> Hi Joe,
> 
> A few comments:
> 

If an endpoint supports UDP options, these are the ones that it is required to support. I will clarify that in the next update.

> its own DOS vulnerability. Can you elaborate of this vulnerability?

Pushing meaningful options behind dozens of NOPs increases endpoint work to parse the header. Previous list discussion indicated that because there was never a real need for more than three (e.g., for single-byte option realignment to 32-bit boundaries), that could be used as a test. The work required to perform this test is trivial compared to the work of parsing the options, so I don’t see this as creating a new vulnerability.

> either CRC-CCITT or CRC-16, it might be worth considering that for UDP

We want to pick one rather than create ambiguity and additional work. I don’t much care which one we pick; there was previous discussion on the one we picked, but we can re-open that if you have a reason.

> that the kind field for these options is corrupted.

Sure - the only alternative is to require these options, in which case their corruption would be detected. However, an endpoint that is expecting one or both of these would know when a packet failed to include it.

> For instance, if

I can add some text addressing this.

> by configuration or GUE capability negotiation”

Sure - that’s what I said above; it would depend on the expectation, which can be configured or negotiated.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 22 Jan 2018 09:04:50 -0800

> If an endpoint supports UDP options, these are the ones that it is required to support. I will clarify that in the next update.

Are all of the options defined in the draft required?

> We want to pick one rather than create ambiguity and additional work. I don’t much care which one we pick; there was previous discussion on the one we picked, but we can re-open that if you have a…

I don't have a strong preference, either CRC-16 or CRC-16-CCITT will
work. (that seems to be the consensus from original discussion also).
Both of these are used and both have been implemented in HW, and, as I
said, CRC-16 is already in Linux so that's a shorter path to bring up
support in GUE at least. I don't see much cost in allowing both as
long as it's unamiguous which one is being used.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 22 Jan 2018 09:19:20 -0800

Hi Tom,

> On Jan 22, 2018, at 9:04 AM, Tom Herbert <[email-masked]> wrote:
> 

See the “*” in the list in Sec 5. We can certainly expand that to include others. 

> long as it's unamiguous which one is being used.

The cost is implementation complexity and the benefit seems negligible. 

Joe