Re: [Spud] related draft in TSVWG

[Tom Herbert <[e-mail]>]

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

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

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

Tom

> Joe
>
>>
>> Tom
>>
>>> NOTE: I'm not sure what space makes the most sense; for on-path info,
>>> IMO IP is a more appropriate location than transport, but IF there is
>>> info that is useful to exchange at the transport layer in the header,
>>> this might be useful for UDP.
>>>
>>> It will be briefly presented by the chairs in TSVWG.
>>>
>>> FYI.
>>>
>>> Joe
>>>
>>> _______________________________________________
>>> Spud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spud
>