JunOS/FRR/Nokia et al BGP critical issue

Wed Aug 30 14:15:55 UTC 2023

>
> Or do the sensible thing and just drop the announcement and log the
> problem.
>

Which is exactly what an RFC7606 compliant device will do for an unknown
path attribute.

https://www.rfc-editor.org/rfc/rfc7606#page-5

   o  Treat-as-withdraw: In this approach, the UPDATE message containing
      the path attribute in question MUST be treated as though all
      contained routes had been withdrawn just as if they had been
      listed in the WITHDRAWN ROUTES field (or in the MP_UNREACH_NLRI
      attribute if appropriate) of the UPDATE message, thus causing them
      to be removed from the Adj-RIB-In according to the procedures of
      [RFC4271 <https://www.rfc-editor.org/rfc/rfc4271>].

   d.  If any of the well-known mandatory attributes are not present in
       an UPDATE message, then "treat-as-withdraw" MUST be used.  (Note
       that [RFC4760] reclassifies NEXT_HOP as what is effectively
       discretionary.)

   e.  "Treat-as-withdraw" MUST be used for the cases that specify a
       session reset and involve any of the attributes ORIGIN, AS_PATH,
       NEXT_HOP, MULTI_EXIT_DISC, or LOCAL_PREF.

On Wed, Aug 30, 2023 at 10:01 AM Eugeniu Patrascu <eugen at imacandi.net>
wrote:

> On Wed, Aug 30, 2023 at 4:04 PM William Herrin <bill at herrin.us> wrote:
>
>> On Wed, Aug 30, 2023 at 4:50 AM Mike Lyon <mike.lyon at gmail.com> wrote:
>> > 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
>>
>> Can you imagine, as the origin of a route, troubleshooting a
>> connectivity issue in which Internet BGP routers far from your control
>> have trouble with attributes attached by their peers and then "did
>> their best" with your route instead of dropping the session and
>> essentially demanding intervention by the network operator?
>>
>> Dumping the session may seem extreme, but there's a good reason for it.
>
>
> Or do the sensible thing and just drop the announcement and log the
> problem.
> This might be a problem in a DFZ environment, but albeit a small one.
> Or, drop the invalid attribute and treat the announcement as a regular one.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230830/418fc0ee/attachment.html>