[70237] in North American Network Operators' Group
Re: BGP Exploit
daemon@ATHENA.MIT.EDU (Christopher L. Morrow)
Wed May 5 19:31:54 2004
Date: Wed, 05 May 2004 23:31:11 +0000 (GMT)
From: "Christopher L. Morrow" <christopher.morrow@mci.com>
In-reply-to: <B7FE33C6-9EC4-11D8-91A9-000A9578BB58@ianai.net>
To: "Patrick W.Gilmore" <patrick@ianai.net>
Cc: nanog@merit.edu
Errors-To: owner-nanog-outgoing@merit.edu
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.
>
> 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.
