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

[Joe Touch <[e-mail]>]

On 11/2/2015 8:28 AM, Bob Briscoe wrote:
> 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.

Absolutely - thanks for the suggestion and pointers.

Joe

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