[70263] in North American Network Operators' Group
RE: BGP Exploit
daemon@ATHENA.MIT.EDU (Smith, Donald)
Thu May 6 12:59:24 2004
Date: Thu, 6 May 2004 10:58:37 -0600
From: "Smith, Donald" <Donald.Smith@qwest.com>
To: "Christopher L. Morrow" <christopher.morrow@mci.com>,
"Patrick W.Gilmore" <patrick@ianai.net>
Cc: <nanog@merit.edu>
Errors-To: owner-nanog-outgoing@merit.edu
I don't believe it FILLED the pipe. I suspect it made the interface
unusable by consuming buffer/processes/io ...
Other interfaces on the system were still functional. I did NOT measure
the actual through put.
Donald.Smith@qwest.com GCIA
http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xAF00EDCC
pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC
kill -13 111/2=20
> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On=20
> Behalf Of Christopher L. Morrow
> Sent: Wednesday, May 05, 2004 5:31 PM
> To: Patrick W.Gilmore
> Cc: nanog@merit.edu
> Subject: Re: BGP Exploit
>=20
>=20
>=20
> On Wed, 5 May 2004, Patrick W.Gilmore wrote:
>=20
> >
> > On May 5, 2004, at 2:39 PM, Smith, Donald wrote:
> >
> > > No. The router stays up. The tool I use is very fast. It=20
> floods the=20
> > > GIGE to the point that that interface is basically=20
> unusable but the=20
> > > router itself stays up only the session is torn down. I did=20
> > > 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=20
> can take a=20
> > Gigabit of traffic to its CPU and stay up. What kind of router was=20
> > this? You mentioned Juniper and Cisco before, but I know a=20
> cisco will=20
> > fall over long before a gigabit and a Juniper either does or drops=20
> > packets destined for the CPU (but keeps routing).
>=20
> recieve-path acl and recieve-path-limits perhaps on a cisco=20
> will allow survival? Though if this is 'bgp' from a valid=20
> peer it seems likely to crunch it either way.
>=20
> >
> > Perhaps it was rate limiting the # of packets which reached=20
> the CPU,=20
> > and the session stayed up because the "magic" packet was dropped in=20
> > the rate limiting?
> >
>=20
> That sees likely.
>=20
