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

[Joe Touch <[e-mail]>]

We did find a few vendors that don't block those packets.

On 11/1/2015 10:05 PM, Bob Briscoe 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.

Well, since "that which isn't prohibited ought to be permitted", IMO
that' an error in their code.

> Whether or not there is a buffer overflow vulnerability in any host,

This would be an underflow issue, not an overflow one, FWIW.

Joe

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