> 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
