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

[Jeffrey Haas <[e-mail]>]

> On Apr 18, 2024, at 6:32 AM, Claudio Jeker <[e-mail]> wrote:
> Are there still BGP implementations out there that do not support
> capabilities (RFC5492)?

"Implementations", yes.  From current vendors or major open source packages, probably not.

BGP-4 is simple enough for basic ipv4 applications that people continually make their own stuff even in spite of available tooling.

> 
>   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.

Generally, the desired behavior is you list the state you don't like.  

State you want but isn't present shouldn't be sent back in the notification.


> 
> 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?

Dirty conformance laundry: 

Junos will return unsupported capability for any known but malformed capability that isn't the multi-protocol capability with no error data.

For multi-protocol, we'll encode the received mp-caps back in our data.  We do this when there are no overlapping afi/safi to peer with.

For tracing received notifications, mp is the only thing that we pretend to understand and dig inside.  The rest is just dealt with as opaque hex data.

> 
> 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.

The notification data is handy if you're trying to determine what the remote device didn't like.  That said, if you're poking at a device in a non-consensual way (presuming they've left their bgp ports reachable), there's something to be said for less disclosure and not exercising code paths where you send in nonsense.

> Also FRR seems to send suberr 7 NOTIFICATIONs for unknown or superfluous
> capabilities. Which violates the last sentence of Section 5.

Yeah... don't do that.

-- Jeff