Re: [Idr] Questions regarding BGP capabilities (RFC5492)

[Claudio Jeker <[e-mail]>]

On Thu, Apr 18, 2024 at 02:59:35PM +0300, Donatas Abraitis wrote:
> Hi,
> 
> >Are there still BGP implementations out there that do not support
> capabilities (RFC5492)?
> 
> Most likely some random parsers/scripts don't care about capabilities, but
> I think this is not a big deal.
> 
> >I checked some other opensource BGP implementations and noticed that
> both FRR and bird send this suberr 7 NOTIFICATION without any data!
> 
> Speaking of FRR: what is the configuration of FRR? It SHOULD send
> NOTIFICATION(7) only when there is a strict capability requirement
> (neighbor ... strict-capability-match), or the AFI/SAFI is not enabled at
> all when MP is used.

I just looked at the code:
https://github.com/FRRouting/frr/blob/master/bgpd/bgp_open.c#L1454

First of all yes this needs strict-capability-match to be on but
the sent NOTIFICATION messages are not RFC conforming.
The call on line 1457 is for unsupported / superfluous capabilities (which
should just be ignored) and the call on line 1468 does not include data.

> >The Data field in the NOTIFICATION
>    message MUST list the set of capabilities that causes the speaker to
>    send the message.
> 
> I double-checked this, and FRR sends capability(-ies) that are not in
> compliance with what is expected. At least wireshark/tcpdump shows it
> correctly.
> 
> Donatas.
> 
> On Thu, Apr 18, 2024 at 1:33 PM Claudio Jeker <[e-mail]>
> wrote:
> 
> > Hi all,
> >
> > I have a few questions about BGP capabilities since we want to enforce
> > some capabilities long term in OpenBGPD.
> >
> > As a first step we want to remove an old fallback to start over with no
> > capabilities in case of a NOTIFICATION with error code 2 (OPEN) and
> > suberr 4 (Unsupported Optional Parameter).
> >
> > Are there still BGP implementations out there that do not support
> > capabilities (RFC5492)?
> >
> >
> >
> > On top of this I have a question about NOTIFICATION error code 2 (OPEN)
> > suberr 7 (Unsupported Capability). From the RFC5492:
> >
> > 5.  Extensions to Error Handling
> >
> >    This document defines a new Error Subcode, Unsupported Capability.
> >    The value of this Subcode is 7.  The Data field in the NOTIFICATION
> >    message MUST list the set of capabilities that causes the speaker to
> >    send the message.  Each such capability is encoded in the same way as
> >    it would be encoded in the OPEN message.
> >
> >    As explained in the "Overview of Operations" section, the Unsupported
> >    Capability NOTIFICATION is a way for a BGP speaker to complain that
> >    its peer does not support a required capability without which the
> >    peering cannot proceed.  It MUST NOT be used when a BGP speaker
> >    receives a capability that it does not understand; such capabilities
> >    MUST be ignored.
> >
> > I have an issue with "Each such capability is encoded in the same way
> > as it would be encoded in the OPEN message".  The thing is for some
> > capabilities the system may not really know the exact encoding of the
> > missing capability. For example graceful restart could include some
> > AFI/SAFI pairs but those are optional.
> >
> > For OpenBGPD when parsing notifications only the first byte of data is
> > looked at so that we can log which capability code caused the problem.
> > When sending such a notification we build a capability with valid code and
> > length fields but apart from capa 1 the payload of the capability is 0.
> > For capa 1 we do send the AFI/SAFI pair that is missing.
> >
> > How do other implementations handle this?
> >
> > I checked some other opensource BGP implementations and noticed that
> > both FRR and bird send this suberr 7 NOTIFICATION without any data!
> > I can not really check the behaviour of other propretary implementations.
> >
> > Also FRR seems to send suberr 7 NOTIFICATIONs for unknown or superfluous
> > capabilities. Which violates the last sentence of Section 5.
> > Again, do other implementations do the same?
> >
> > --
> > :wq Claudio
> >
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >
> 
> 
> -- 
> Donatas

-- 
:wq Claudio