OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field

Mailman List Mirror (Read Only)
1

I had two downstream BGP customers experience problem with an OpenBGPd bug
tonight. Before diving into detail, I would like to link this mailing list
thread, because this is not a new issue and a patch is available:
http://www.mail-archive.com/misc@openbsd.org/msg115071.html

For the following DFZ routes, I see wrong use of the fifth bit in the
Attribute Flags field:
          Aggregator (7), length: 8, Flags [OT+8]: AS #68, origin
192.65.95.253
            0x0000: 0000 0044 c041 5ffd
          Updated routes:
            128.165.0.0/16
            141.111.0.0/16
            192.65.95.0/24
            192.12.184.0/24
            204.121.0.0/16

According to RFC 4271 page 17, "the low-order four bits of the Attribute
Flags octet are unused. They MUST be zero when sent and MUST be ignored
when received." I read "ignored" to mean, don't tear down the BGP session
and print a cryptic error that the user probably will be unable to debug.
The OpenBGPd guys clearly agree and have supplied a patch, so affected
users should visit the above mailing list link, and install it.

Here are my notes for this RFC page and a small diagram of the packet
header, because surprisingly, there isn't one in the RFC already
http://inconcepts.biz/~jsw/img/1121129aa-rfc4271pg17scan.jpg Sorry about
the poor quality of this, but it is past 3am here, and I know of several
operators (besides my downstream customers) who are experiencing this
problem right now.

If I were someone who is broken by this right now, I would either patch my
OpenBGPd or ask your eBGP neighbors not to send you the above five routes
(filtering it on your own OpenBGPd router probably won't help.)

Thanks, I hope this is helpful

2

Hi Jeff (and NANOG)

This is one of our customers, and we're going to get it fixed (or worked
around) ASAP.

michael

3

Jeff and NANOG:

We are currently dropping the bad attribute within our network (as293)
and are working with the customer to determine the origin of the
attribute (equipment, code rev, etc.). The bad attribute should not be
leaking beyond our AS at all. If you're filtering routes from AS68, you
should be able to resume accepting routes from that AS.

michael

4

If you hear anything more, I'd be interesting in knowing about it. I had a
an upstream going up and down last night; reportedly their BGP process was
core dumping due to a BGP attribute issue. I never found out what vendor
it was though.

Paul

5

Note that this was committed to OpenBGP on 12 August, so if you're running
a *snapshot* from after that date, you won't be affected. It made it too
late for OpenBSD 5.2 but has just been committed to the patch branch, so
building from a newly-updated source checkout tagged OPENBSD_5_2 will also
have this.

Looks like this is in 5.2.20121014 in FreeBSD ports too.

-sthen