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

[Bob Briscoe <[e-mail]>]

Joe,

The point of my post was in response to:

On 7/22/2015 09:52 AM, Joe Touch wrote:

> I have students starting this fall who will look into this and do some tests. We have no information yet.
so they could go looking for the most likely place where there might be 
problems. A little manual reading could give clues on where to look, to 
save searching loads of Internet paths.

You might even find someone has already probed for this supposed 
'vulnerability' (whether for research or for nefarious puposes), then 
your student wouldn't have to do any work other than get their data, or 
even just cite their paper.

They could also search for phrases like "UDP Length Error" to find 
source code that checks for this, then see what the code does and what 
it is used in.

I am just trying to make their job easier, so they can finish early and 
perhaps do something more useful.



Here's some more links found in a few minutes of searching:

These two show that by default checkpoint firewalls (very common) check 
for consistency betw the two lengths.
Re: [FW-1] UDP length error 
<https://www.mail-archive.com/search?l=[e-mail]&q=subject:%22Re%5C%3A+%5C%5BFW%5C-1%5C%5D+UDP+length+error%22&o=newest>
Malformed Packet & UDP length error 
<https://www.cpug.org/forums/showthread.php/5387-Malformed-Packet-UDP-length-error?s=ffa052f56a7ef3059307123c94f4ac02>

This one shows that a cisco router checks the UDP length of HSRP Hello 
packets is consistent before accepting it:
<https://www.cpug.org/forums/showthread.php/5387-Malformed-Packet-UDP-length-error?s=ffa052f56a7ef3059307123c94f4ac02>Cisco 
Bug: CSCsc13766 - Both HSRP routers are active - UDP length error

I'm not expecting comment on whether you think the alleged 
vulnerabilities these firms are preventing exist, or whether they ought 
to block such packets. I'm just saying they do.


Bob


On 02/11/15 15:24, Joe Touch wrote:
> 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/
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/