Re: [Spud] [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-01.txt

[Jana Iyengar <[e-mail]>]

What Bob said.
Also, what problem is this draft seeking to solve, especially given that
there's no negotiation of options support possible?

- jana

On Sun, Nov 1, 2015 at 10:05 PM, Bob Briscoe <[e-mail]> wrote:

> Joe,
>
> Before starting measurements, I would recommend searching the Web for the
> manuals of middleboxes that might block such packets.
>
> For instance, with a quick search of "UDP header length inconsistency" I
> found Alcatel-Lucent's "Brick" Intrusion Detection System blocks such
> packets.
>
> Whether or not there is a buffer overflow vulnerability in any host, there
> will be firewalls and IDSs that block these packets in case someone is
> probing for such vulnerabilities.
>
>
>
> bob
>
>
> On 14/08/15 19:35, C. M. Heard wrote:
>
>> On 7/22/2015 09:52 AM, Joe Touch wrote:
>>
>>> On 7/21/2015 11:22 PM, Brian Trammell wrote:
>>>
>>>> hi Joe,
>>>>
>>>> Thanks for this draft; I appreciate the elegant redundancy-reducing
>>>> length hack. :)
>>>>
>>>> Data in this case is, I know, hard to come by, but would you have
>>>> any feel for how much stuff out there will just break when they see an
>>>> inconsistency between IP and UDP length information?
>>>>
>>> I have students starting this fall who will look into this and do some
>>> tests. We have no information yet.
>>>
>> In an off-list e-mail exchange with Joe a couple of weeks ago, I noted
>> that every host stack implementation whose code I have inspected simply
>> ignores bytes that are past the UDP length but within the IP payload
>> length.  The BSD-derived stacks trim the excess bytes before the data
>> is passed to the application via the sockets interface.  However, one
>> embedded stack I have seen (which does not use a sockets API) makes
>> all data available to the application, including the UDP header, and
>> lets the application deal with excess bytes as it sees fit.
>>
>> I have zero information on the behavior of middleboxes (NAT/NAPT).
>>
>> Assuming that Joe's tests confirm these observations for both end
>> systems and middleboxes, then the proposed UDP option trailer should be
>> incrementally deployable as long as all options therein can be safely
>> ignored if not understood.  The degree of utility (or, at least, the
>> length of time needed to make them useful) will of course depend
>> strongly on whether middleboxes trim the trailer or leave it intact;
>> if the prevalent middlebox practice is to trim it, then they won't be
>> useful without updating middleboxes as well as end systems.
>>
>> Also, Joe, if you and your students have the time and resources to look at
>> what middleboxes do with UDP packets where the IP header indicates a
>> shorter length than the UDP header, that would be useful information, as
>> it
>> could open up a possible means to incorporate fragmentation in the UDP
>> layer, independent of whether or not an options trailer is present.
>>
>> Mike Heard
>>
>>
>>
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>
>
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud
>