Re: [Spud] related draft in TSVWG

[Joe Touch <[e-mail]>]

On 6/27/2016 4:34 PM, Tom Herbert wrote:
>> First, yes, if this were a strict requirement, than UDP implementations
>> would discard UDP segments that were smaller than the IP payload -- in
>> practice, they don't.
>>
> I would not be at all surprised if there are middle boxes that either
> drop such packets or truncate them to UDP length in the name of
> security.
We haven't done exhaustive tests, but so far we've seen good behavior.

>> The good news is that there are no known specs (at least none I've heard
>> of yet or know of otherwise) that use this trick except:
>>
>> a) UDP-lite, which uses a different transport protocol number and has
>> different semantics
>>     in UDP-lite, the entire IP payload is treated as the UDP payload,
>> which isn't compatible with RFC768
>>
>>     i.e., it basically delivers both what UDP considers the payload AND
>> the extended area to the app layer
>>
>> b) there's a defensive patent that talks about this, which we already
>> know about but AFAIK never got beyond the though level
>>
>>     (it's the typical patent with permissions compatible with IETF
>> standards, again AFAIK)
>>
>> This does appear to be the first system that will spec this out. We do
>> include the new OCS (option checksum), which might help avoid accidental
>> ambiguous use (I.e., UDP OCS ought to help avoid processing these other
>> uses as UDP checksum).
>>
> You might want to look at magic numbers for this purpose also.

A checksum is just a dynamic, context-sensitive magic number. There's a
lot lower chance of a checksum being correct in a random sequence than a
magic number.

> Unfortunately, similar to the idea of putting bits in UDP payload for
> interpretation in the network, protocol correctness in this method is
> only probabilistic. That is the best we could achieve is 99.999..%
> correctness, not 100%.
That's true for everything. Anyone could have deployed an unassigned TCP
option number in an unknown way too.

>
>> We can add text to address this issue, though we would appreciate also
>> knowing if anyone is aware of existing uses other than the two above.
>>
> Probably should also expressly forbid the network to modify options in
> flight, that is where things get really scary in the above ambiguous
> identification problem.
Oh, yes. FYI, the OCS is just over the option space, not over the UDP
payload, UDP header, or IP pseudoheader.

Joe