Re: JunOS/FRR/Nokia et al BGP critical issue
The blog was updated. Correct link: https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling The attribute was not malformed. This is the hex dump of the attribute: “E0 1C 00” It is described here. https://www.rfc-editor.org/rfc/rfc6790#section-5.2 This attribute is deprecated, but that does not prevent routers from originating it or passing it on. Kind Regards, Jakob ----------------- Original message -------------- From: Mike Lyon <mike.lyon@gmail.com> To: NANOG list <nanog@nanog.org> Ran across this article today and haven't seen posts about it so i figured I would share: https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling?fbclid=IwAR13ePY43Vf3u4X8PDyCDT39DtyXczAKkv6CGXOQbcQv90Y3aIAmTkJxn7k_aem_Ad0hzj2Mh_WlbFZug-vGdlJJdXr2Xo0RFIsPwAU2GviPz6xZDib76YHwFuzU7E0_sJk&mibextid=Zxz2cZ Curious if anyone on the list is running VyOS and has experienced any problems? Cheers, Mike -- Mike Lyon mike.lyon@gmail.com http://www.linkedin.com/in/mlyon
vendors should adopt RFC7606
Yes and not be absolutely awful at responding to vulnerability reporting. 1. This isn't exactly new. It's been possible to do this since the original days of BGP. 2. Probably not wise to assume that's accurate just because he thinks that is true. On Wed, Aug 30, 2023 at 11:02 AM <jeffm@iglou.com> wrote:
Fair update. To be clear, though, the main point of the article stands, and is maybe even strengthened by the update. A corrupted attribute def can cause the behavior (personal experience speaking here with a different attribute) and vendors should adopt RFC7606 and not be absolutely awful at responding to vulnerability reporting.
On Aug 30, 2023 10:43 AM, "Jakob Heitz (jheitz) via NANOG" < nanog@nanog.org> wrote:
The blog was updated. Correct link:
https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling
The attribute was not malformed.
This is the hex dump of the attribute: “E0 1C 00”
It is described here.
https://www.rfc-editor.org/rfc/rfc6790#section-5.2
This attribute is deprecated, but that does not prevent routers from originating it or passing it on.
Kind Regards,
Jakob
----------------- Original message --------------
From: Mike Lyon <mike.lyon@gmail.com> To: NANOG list <nanog@nanog.org>
Ran across this article today and haven't seen posts about it so i figured I would share:
Curious if anyone on the list is running VyOS and has experienced any problems?
Cheers, Mike
-- Mike Lyon mike.lyon@gmail.com http://www.linkedin.com/in/mlyon
Tom Beecher wrote on 8/30/23 8:22 AM:
vendors should adopt RFC7606
Yes
and not be absolutely awful at responding to vulnerability reporting.
1. This isn't exactly new. It's been possible to do this since the original days of BGP.
Literally the first thing that came into my mind was the as-set issue from 2 decades ago where some vendors passed it, others dropped sessions..
2. Probably not wise to assume that's accurate just because he thinks that is true.
On Wed, Aug 30, 2023 at 11:02 AM <jeffm@iglou.com <mailto:jeffm@iglou.com>> wrote:
Fair update. To be clear, though, the main point of the article stands, and is maybe even strengthened by the update. A corrupted attribute def can cause the behavior (personal experience speaking here with a different attribute) and vendors should adopt RFC7606 and not be absolutely awful at responding to vulnerability reporting.
On Aug 30, 2023 10:43 AM, "Jakob Heitz (jheitz) via NANOG" <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
The blog was updated. Correct link:
https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling
The attribute was not malformed.
This is the hex dump of the attribute: “E0 1C 00”
It is described here.
https://www.rfc-editor.org/rfc/rfc6790#section-5.2
This attribute is deprecated, but that does not prevent routers from originating it or passing it on.
Kind Regards,
Jakob
----------------- Original message --------------
From: Mike Lyon <mike.lyon@gmail.com <mailto:mike.lyon@gmail.com>> To: NANOG list <nanog@nanog.org <mailto:nanog@nanog.org>>
Ran across this article today and haven't seen posts about it so i figured I would share:
Curious if anyone on the list is running VyOS and has experienced any problems?
Cheers, Mike
-- Mike Lyon mike.lyon@gmail.com <mailto:mike.lyon@gmail.com> http://www.linkedin.com/in/mlyon
-- Thank you, Steven
IOS-XR passes on the attribute by default. Some other routers incorrectly claim it to be malformed and reset the BGP session. IOS-XR has a configuration to discard an attribute, so it will not pass it on. It will pass the route with all its other attributes. Here is an example configuration: router bgp {asn} attribute-filter group block_elc attribute 28 discard ! neighbor {ip address} update in filtering attribute-filter group block_elc ! ! ! More info: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/routing/comma... https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-8/ro... Kind Regards, Jakob From: Jakob Heitz (jheitz) <jheitz@cisco.com> Date: Wednesday, August 30, 2023 at 7:43 AM To: nanog@nanog.org <nanog@nanog.org> Subject: Re: JunOS/FRR/Nokia et al BGP critical issue The blog was updated. Correct link: https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling The attribute was not malformed. This is the hex dump of the attribute: “E0 1C 00” It is described here. https://www.rfc-editor.org/rfc/rfc6790#section-5.2 This attribute is deprecated, but that does not prevent routers from originating it or passing it on. Kind Regards, Jakob ----------------- Original message -------------- From: Mike Lyon <mike.lyon@gmail.com> To: NANOG list <nanog@nanog.org> Ran across this article today and haven't seen posts about it so i figured I would share: https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling?fbclid=IwAR13ePY43Vf3u4X8PDyCDT39DtyXczAKkv6CGXOQbcQv90Y3aIAmTkJxn7k_aem_Ad0hzj2Mh_WlbFZug-vGdlJJdXr2Xo0RFIsPwAU2GviPz6xZDib76YHwFuzU7E0_sJk&mibextid=Zxz2cZ Curious if anyone on the list is running VyOS and has experienced any problems? Cheers, Mike -- Mike Lyon mike.lyon@gmail.com http://www.linkedin.com/in/mlyon
You may treat-as-withdraw instead of discard. However, this attribute does not affect routing. It only affects whether a sender of packets to the route will add the entropy label or not to the MPLS header, if such an MPLS header is added. Therefore, it is safe to discard the attribute. Kind Regards, Jakob From: Jakob Heitz (jheitz) <jheitz@cisco.com> Date: Wednesday, August 30, 2023 at 8:15 AM To: nanog@nanog.org <nanog@nanog.org> Subject: Re: JunOS/FRR/Nokia et al BGP critical issue IOS-XR passes on the attribute by default. Some other routers incorrectly claim it to be malformed and reset the BGP session. IOS-XR has a configuration to discard an attribute, so it will not pass it on. It will pass the route with all its other attributes. Here is an example configuration: router bgp {asn} attribute-filter group block_elc attribute 28 discard ! neighbor {ip address} update in filtering attribute-filter group block_elc ! ! ! More info: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/routing/comma... https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-8/ro... Kind Regards, Jakob From: Jakob Heitz (jheitz) <jheitz@cisco.com> Date: Wednesday, August 30, 2023 at 7:43 AM To: nanog@nanog.org <nanog@nanog.org> Subject: Re: JunOS/FRR/Nokia et al BGP critical issue The blog was updated. Correct link: https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling The attribute was not malformed. This is the hex dump of the attribute: “E0 1C 00” It is described here. https://www.rfc-editor.org/rfc/rfc6790#section-5.2 This attribute is deprecated, but that does not prevent routers from originating it or passing it on. Kind Regards, Jakob ----------------- Original message -------------- From: Mike Lyon <mike.lyon@gmail.com> To: NANOG list <nanog@nanog.org> Ran across this article today and haven't seen posts about it so i figured I would share: https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling?fbclid=IwAR13ePY43Vf3u4X8PDyCDT39DtyXczAKkv6CGXOQbcQv90Y3aIAmTkJxn7k_aem_Ad0hzj2Mh_WlbFZug-vGdlJJdXr2Xo0RFIsPwAU2GviPz6xZDib76YHwFuzU7E0_sJk&mibextid=Zxz2cZ Curious if anyone on the list is running VyOS and has experienced any problems? Cheers, Mike -- Mike Lyon mike.lyon@gmail.com http://www.linkedin.com/in/mlyon
participants (4)
-
Jakob Heitz (jheitz)
-
jeffm@iglou.com
-
Steve Noble
-
Tom Beecher