BGP Exploit

Patrick W.Gilmore patrick at ianai.net
Thu May 6 11:07:25 UTC 2004


On May 5, 2004, at 7:31 PM, Christopher L. Morrow wrote:

> On Wed, 5 May 2004, Patrick W.Gilmore wrote:
>
>>
>> On May 5, 2004, at 2:39 PM, Smith, Donald wrote:
>>
>>> No. The router stays up. The tool I use is very fast. It floods the
>>> GIGE
>>> to the point that that interface is basically unusable but the router
>>> itself stays up only the session is torn down. I did preformed these
>>> tests in a lab and did
>>> not have full bgp routing tables etc ... so your mileage may vary.
>>
>> That is DAMNED impressive.  I've never seen a router which can take a
>> Gigabit of traffic to its CPU and stay up.  What kind of router was
>> this?  You mentioned Juniper and Cisco before, but I know a cisco will
>> fall over long before a gigabit and a Juniper either does or drops
>> packets destined for the CPU (but keeps routing).
>
> recieve-path acl and recieve-path-limits perhaps on a cisco will allow
> survival? Though if this is 'bgp' from a valid peer it seems likely to
> crunch it either way.

Does this mean you think a cisco would survive a gigabit of traffic 
from a "valid" peer directed at the CPU?  I admit I have not tested 
this, but past experience with similar things would imply _any_ router 
cisco makes would fall over in such a situation - at best just wedging 
and not doing anything (pass packets, SMNP, SSH, etc.), and perhaps 
rebooting, depending upon IOS / model.


>> Perhaps it was rate limiting the # of packets which reached the CPU,
>> and the session stayed up because the "magic" packet was dropped in 
>> the
>> rate limiting?
>>
>
> That sees likely.

Agreed.  Which makes the test ... not 100% valid.

Hrmmm....  I wonder how many miscreants tried the MD5 thing and just 
sent 100K pps to the router to reset a session really fast, then failed 
'cause most of their packets were dropped?

-- 
TTFN,
patrick




More information about the NANOG mailing list