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

From: Joe Touch <[email-masked]>
Date: Sun, 1 Jul 2018 21:03:35 -0700

Catching up on a series of edits...

> On Jan 21, 2018, at 2:47 PM, Joe Touch <[email-masked]> wrote:
> 
>> 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)
> 
> I can add some text addressing this.

I have reconsidered this issue.

It is impractical and not useful to address the different ways in which an arbitrary byte change can “flip” and the consequences thereof.

If a header checksum is used, these might be caught, but if not, all bets are off. It’s not clear even that needs to be said.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 2 Jul 2018 08:56:20 -0700

On Sun, Jul 1, 2018 at 9:03 PM, Joe Touch <[email-masked]> wrote:
> It is impractical and not useful to address the different ways in which an
> arbitrary byte change can “flip” and the consequences thereof.
>
> If a header checksum is used, these might be caught, but if not, all bets
> are off. It’s not clear even that needs to be said.

To follow your gaming analogy, when a sender inserts a checksum or
integrity check it is making a bet that corrupted packets will be
detected (the wager is the cost of computing the checksum). Any type
of check can be assigned a probability that corrpupted packets will be
detected. Suppose that a mandatory checksum (like in TCP or IP) has
probability 'p_m' and and optional checksum has probability 'p_o'.
Then we know that 'p_m > p_o' because the the data check can detect
corruption of the checksum information, but an optional checksum
misses corruption of the type field for the checksum. Manadory
checksum is a better bet for the sender, question is how much better
is it.

For UDP options, my biggest concern is still misinterpretation of the
slack space. I don't believe it has been proven that in the 40 year
history of UDP no packets are being sent with an UDP length/IP lenght
mismatch, although I do wonder if this has ever been used covert
channel. A fixed UDP options header with a checksum would
probabilistically ensure that such misinterpretion won't happen-- at a
cost of just a few bytes.

Tom

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Jul 2018 10:42:28 -0700

> On Jul 2, 2018, at 8:56 AM, Tom Herbert <[email-masked]> wrote:
> 
> slack space.

Agreed - the question is whether that check needs to be very strong.

> I don't believe it has been proven that in the 40 year
> mismatch,

It’s impossible to prove a negative without complete information; given we can’t see every packet on the Internet over the past 40 years, there can never be such a proof...

> although I do wonder if this has ever been used covert
> channel.

Sure - but there are plenty of other covert channels in Internet protocols that are easier to use..

> A fixed UDP options header with a checksum would

Probabilistically, a single byte checksum might be sufficient to catch this happening in a sequence of such packets, though. 

We could add text that if a large number of packets fail the test, then we would assume the option area is not supported and disable it.

Joe