[129159] in North American Network Operators' Group
Re: Did your BGP crash today?
daemon@ATHENA.MIT.EDU (Thomas Mangin)
Sat Aug 28 03:50:17 2010
From: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
In-Reply-To: <70B436DB-9705-454F-907D-854D2C20B706@kumari.net>
Date: Sat, 28 Aug 2010 08:49:56 +0100
To: Warren Kumari <warren@kumari.net>
Cc: bmanning@vacation.karoshi.com, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> I'm assuming that they weren't really expecting this to cause =
issues... Where does one draw the line? I'm planning on announcing =
x.y.z.0/20 later in the week -- x, y and z are all prime and the sum of =
all 3 is also a prime. There is a non-zero chance that something =
somewhere will go flooie, shall I send mail now or later?
In this case the researchers sent an new packet that would never have =
been generated by any operational router ever before to their peer. They =
knew their packet would cause the router to run less/un tested and code =
path in BGP. To their defence, the risk was low.=20
That said when I wrote my own BGP injector I accidentally sent badly =
formed known messages (like UPDATE,etc.) with bad attributes (like =
transitive when the RFC it MUST not be, and vice versa) to my routers.
Juniper would kill the session at the validation stage and be quite =
verbose in the log but Cisco - at least on the 7301 I tested last year =
with a then recent IOS - would accept the packet as it. Yep, IOS do =
accept INVALID packets.
I have no idea what happens after but if a Cisco router is passing the =
packet to a Juniper router it could have the same effect that what we =
saw, again, and tear down a session which is not the one which initiated =
the badly formed packet. That said I suspect that the message may not =
have been fully parsed, for performance reasons, with the outgoing =
packet partially generated following the RFC.
Quagga is even worse that Cisco when it comes to packet validation but =
it should not surprise anyone :p
Now, Should I research the described BGP behaviour (for a white hat =
conference for example) and send my possibly risking packets to my peer =
without telling them ?
Hell no ! I am pretty sure that if I did I would loose quite a few =
session afterwards. People trust me not to absuse my BGP connections but =
for sending safe known message about my network and not some research =
stuff.
That said vendor SHOULD research (and hopefully did) this kind of =
behaviour, but as yesterday shown, causing packet corruption through a =
router is bad for its stability :p
> Also, I would prefer that this gets discovered and dealt with (in this =
case by stopping the announcement :-)) than having folk not willing to =
try things and ending up with a weaponized version...
No argument here.
Thomas=
