nanog mailing list archives

Re: Did your BGP crash today?


From: Raymond Dijkxhoorn <raymond () prolocation net>
Date: Sat, 28 Aug 2010 14:21:31 +0200 (CEST)

Hi!

I think you blame the wrong people. The vendor should make sure that
their implementation does not violate the very basics of the BGP
protocol.

The curious thing here is that the peer that resets the session, as
required by the spec, causes the actual damage (the session reset),
and not the peer producing the wrong update.

This whole thread is quite schizophrenic because the consensus appears
to be that (a) a *researcher is not to blame* for sending out a BGP
message which eventually leads to session resets, and (b) an
*implementor is to blame* for sending out a BGP messages which
eventually leads to session resets.  You really can't have it both
ways.

I'm fed up with this situation, and we will fix it this time.  My take
is that if you reset the session, you're part of the problem, and
consequently deserve part of the blame.  So if you receive a
properly-framed BGP update message you cannot parse, you should just
log it, but not take down the session.

Not sure if the link was posted allready ...

http://www.cisco.com/en/US/products/products_security_advisory09186a0080b4411f.shtml

'The vulnerability manifests itself when a BGP peer announces a prefix with a specific, valid but unrecognized transitive attribute. On receipt of this prefix, the Cisco IOS XR device will corrupt the attribute before sending it to the neighboring devices. Neighboring devices that receive this corrupted update may reset the BGP peering session.'

Bye,
Raymond.


Current thread: