You do need to have an active BGP session with your target to exploit, so it's not trivially exploitable. That being said, it's something that really, really should have been designed out with proper input bounds checking

This is an issue only between BGP peers, since everybody I know of is using MD5 authenticated BGP peers, this means that only somebody with those credentials can actually establish a session with you - and you have to know its IP address and have to recognize the peers IP address for this to start to be an issue.

There is also dampening that can and will be leveraged to minimize the impact of this. This is done to protect against flapping due to flaky interfaces or links and will not impact a whole lot. BGP uses TCP to communicate and will not allow exchange of routing data to parties that have not established a peer relationship.

So I am afraid this is less of an issue that portrayed.

Geir

It's a little more complicated than that. It does not require that the direct peer originate the malformed BGP update. The behavior of vendor "C" is to pass the malformed packet on. This is the behavior of the updated Juniper code as well. So, the malformed packet might enter the network many, many AS / BGP peering relationships away from the vulnerable router and still cause problem. It does not bring down the interface, but just the BGP session, and I do not believe that route dampening will help on this session.