Re: Did your BGP crash today?

[Thomas Mangin <thomas.mangin () exa-networks co uk>]

> 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. 

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