Did your BGP crash today?
raymond at prolocation.net
Sat Aug 28 07:21:31 CDT 2010
>> I think you blame the wrong people. The vendor should make sure that
>> their implementation does not violate the very basics of the BGP
> 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
> 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 ...
'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.'
More information about the NANOG