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. Donald.Smith@qwest.com GCIA http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC kill -13 111.2
-----Original Message----- From: Stephen J. Wilcox [mailto:steve@telecomplete.co.uk] Sent: Wednesday, May 05, 2004 10:16 AM To: Smith, Donald Cc: Steven M. Bellovin; Kurt Erik Lindqvist; kwallace@pcconnection.com; nanog@merit.edu Subject: RE: BGP Exploit
Of more interest.. does the router die (cpu load) before you brute force the sessions down
Steve
On Tue, 4 May 2004, Smith, Donald wrote:
I have seen 3 pubic ally available tools that ALL work. I have seen 2 privately tools that work. A traffic generator can be configured to successfully tear down bgp sessions.
Given src/dst ip and ports : I tested with a cross platform EBGP peering with md5 using
several of
the tools I could not tear down the sessions. I tested both Cisco and juniper BGP peering after code upgrades without md5 I could not tear down the sessions.
Donald.Smith@qwest.com GCIA http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC kill -13 111.2
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Steven M. Bellovin Sent: Tuesday, May 04, 2004 11:54 AM To: Kurt Erik Lindqvist Cc: kwallace@pcconnection.com; nanog@merit.edu Subject: Re: BGP Exploit
In message <C4E8C22A-9DA6-11D8-B28B-000A95928574@kurtis.pp.se>, Kurt Erik Lindq vist writes:
Now that the firestorm over implementing Md5 has quieted
down a bit,
is anybody aware of whether the exploit has been used? Feel free to reply off list.
Even more interesting, did anyone manage to reproduce it?
I don't know if it's being used; I know that reimplementations of the idea are out there.
--Steve Bellovin, http://www.research.att.com/~smb
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). 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? -- TTFN, patrick
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.
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
On Thu, 6 May 2004, Patrick W.Gilmore wrote:
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
If you employed the recieve-path acls and limits sure... the linecard can take a gig of traffic, right? :) The neighbor might not be happy since you would likely rate-limit down peer traffic to some 'normal' level and thus choke off the real peer and the session would drop in the end anyway. So, same end effect, different method.
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.
without the recieve-path stuff it surely will pain the router.
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.
correct.
Hi it would be a much better idea to force cisco to fix their bgp-feature bug (redistributing wrong as-paths and dropping after that the bgp-session) before talking long and wide about the bgp/tcp "problem". as far as i know, the last 2 big internet-blackouts could be tracked down to wrong as-paths, which waved trough the inet, but i never saw a bgp/tcp problem at the internet gobally. Kind regards, Flaschberger Ingo
participants (4)
-
Christopher L. Morrow -
Ingo -
Patrick W.Gilmore -
Smith, Donald