OpenBGPd problems relating to misuse of RESERVED bits in BGP Attribute Flags field
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 -- Jeff S Wheeler <jsw@inconcepts.biz> Sr Network Operator / Innovative Network Concepts
Hi Jeff (and NANOG) This is one of our customers, and we're going to get it fixed (or worked around) ASAP. michael On 11/29/12 12:44 AM, Jeff Wheeler wrote:
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
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 On 11/29/12 12:44 AM, Jeff Wheeler wrote:
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
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 On Thu, Nov 29, 2012 at 12:33 PM, Michael Sinatra < michael@rancid.berkeley.edu> wrote:
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
I had two downstream BGP customers experience problem with an OpenBGPd bug tonight. Before diving into detail, I would like to link this mailing
On 11/29/12 12:44 AM, Jeff Wheeler wrote: 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
On 2012-11-29, Jeff Wheeler <jsw@inconcepts.biz> wrote:
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
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
participants (4)
-
Jeff Wheeler -
Michael Sinatra -
PC -
Stuart Henderson