Re: [Spud] related draft in TSVWG

[Joe Touch <[e-mail]>]

On 6/27/2016 3:53 PM, Tom Herbert wrote:
> On Mon, Jun 27, 2016 at 2:14 PM, Joe Touch <[e-mail]> wrote:
>> Hi, all,
>>
>> The following draft may be of potential utility in SPUD/PLUS:
>>
>>      draft-touch-tsvwg-udp-options
>>
>> It describes an extension to UDP to allow for trailing options at the
>> transport layer.
>>
> Hi Joe,
>
> >From the draft:
>
> "This length field is typically redundant with IP datagram length and
> header length information as follows:
>
>                   UDPlen = IPlen - IPhdrlen - 8
>
> As a result of this redundancy, the UDP length field can be used in other ways."
>
> "typically" is a key word here; this is not a requirement of UDP. As
> long as the UDP length is less than or equal to IP payload length it
> would be a valid UDP packet. The draft exploits this characteristic,
> however that does not preclude that packets with smaller UDP length
> than IP payload length already exist (maybe even using the same trick
> to extend UDP!). Seems like that leads to a potential ambiguity?

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.

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

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.

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