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

[Claudio Jeker <[e-mail]>]

On Thu, Apr 18, 2024 at 09:02:10AM -0400, Jeffrey Haas wrote:
> 
> 
> > 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.

Guess people need to slowly update their own stuff :)
 
While we can configure session to have no capabilities (you need to turn
of 4-byte ASN, open policy and rrefresh) it is not our default. So people
with their own stuff need to fumble extra config knobs. Also I wonder how
many of those "implementations" do proper error handling :)

> > 
> >   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.
 
Isn't that the inverse of the text in the RFC?
    ... the Unsupported Capability NOTIFICATION is a way for a BGP speaker
    to complain that its peer does not support a required capability 

At least my understanding is that 'Unsupported Capability NOTIFICATION' is
used to inform the peer that a required capability is missing. Stuff you
don't like falls under:
    It MUST NOT be used when a BGP speaker receives a capability that it
    does not understand; such capabilities MUST be ignored.

In fact my interpretation of that sentence is that even badly encoded
capabilities need to be ignored and no NOTIFICATION should be sent back in
that case.

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

Guess our handling is good enough.
-- 
:wq Claudio