Did your BGP crash today?

James Hess 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:
[snip]
> 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.

> -Dave
-- 
-J




More information about the NANOG mailing list