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

[Joe Touch <[e-mail]>]

> On Jul 2, 2018, at 8:56 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Sun, Jul 1, 2018 at 9:03 PM, Joe Touch <[e-mail]> wrote:
>> Catching up on a series of edits...
>> 
>> On Jan 21, 2018, at 2:47 PM, Joe Touch <[e-mail]> 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.
> 
> 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.

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
> history of UDP no packets are being sent with an UDP length/IP lenght
> 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 ensure that such misinterpretion won't happen-- at a
> cost of just a few bytes.

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