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

[Bob Briscoe <[e-mail]>]

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/