Did your BGP crash today?
mysidia at gmail.com
Sat Aug 28 12:47:00 CDT 2010
On Fri, Aug 27, 2010 at 2:33 PM, Dave Israel <davei at otd.com> wrote:
> On 8/27/2010 3:22 PM, Jared Mauch wrote:
> an MD5 hash that can be added to the packet. If the TCP hash checks
Hello, layering violation. If the TCP MD5 option was used, the
MD5 checksum was probably correct.
Malformed BGP Protocol messages, not malformed TCP messages.
The BGP protocol that lives on top of TCP is a non-packetized stream.
Dropping the IP packets, would just mean that the IP packets
containing the malformed BGP data
need to get resent (still containing malformed BGP application
protocol data, when resent).
> out, then you know the packet wasn't garbled, and just contained
> information you didn't grok. That seems like enough evidence to be able
> to shrug and toss the packet without dropping the session.
If the attribute is malformed, and in particular, if the _length_
value is malformed,
because more bits have been transmitted as part of an update than
indicated in the length,
how do you reliably determine exactly where the "junk" ends, and
the next attribute
starts, and resume the stream without loss of other critical data?
Without a valid length of the attribute, you don't know which bit
the next attribute starts at,
or which bit the next update starts at.
If the apparently length of the update is wrong, the rest of your
session appears to be malformed.
If your guess is wrong, you could wind up interpreting part of the
attribute DATA portion
as another route update, allowing an adversary to exploit the
malformed bug to
possibly inject new routes.
A "recovery" mechanism could lead to worse problems, or lead to
problems not being discovered.
More information about the NANOG