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

[Donatas Abraitis <[e-mail]>]

>The call on line 1457 is for unsupported / superfluous capabilities (which
should just be ignored).

Yes, and no, IMO. If we explicitly require STRICT behavior, then I think
NOTIFICATION(7) should be sent.

>and the call on line 1468 does not include data

Yes, will fix this - thanks for noticing ;)

On Thu, Apr 18, 2024 at 5:22 PM Claudio Jeker <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>


-- 
Donatas