[PATCH] bgp: Implement RFC 9234

[Eugene Bogomazov]

I will add a documentation patch in attachment.

I will also add a patch that removes BGP ROLE MAX from consideration, as
was discussed before in a private conversation. This will make the previous
patch with Roles more reliable and secure in case new roles suddenly appear
in the future.

However, after creating a documentation patch and consulting with the main
RFC author, I ran into trouble.

TL;DR: What are the best ways to include AFI/SAFI channel check during
attribute creation?

RFC 9234 specifically clarifies that it can only be applied on IPv4/IPv6
unicast sessions. On all other sessions the OTC attribute should be decoded
from and also transferred to such sessions without any change.

The problem is how to include AFI/SAFI checks in the code:
1) If we have information about a channel (as in *bgp_update_attrs*), we
can simply run the following check
proto/bgp/attrs.c
if (bgp_channel_is_role_applicable(c)) { ... }
proto/bpg/bgpd.h
static inline int bgp_channel_is_role_applicable(struct bgp_channel *c)
{ return (c->afi == BGP_AF_IPV4 || c->afi == BGP_AF_IPV6); }

static inline int bgp_cc_is_role_applicable(struct bgp_channel_config *c)
{ return (c->afi == BGP_AF_IPV4 || c->afi == BGP_AF_IPV6); }
2) However, in *bgp_decode_attrs *the AFI/SAFI information is only
available after NLRI decoding. There is also a side approach with using
*bgp_find_update_afi,* a static function from proto/bgp/packets.c to
extract AFI/SAFI from a packet payload. The question is - what is the best
way to extract AFI/SAFI information: apply OTC rules after NLRI is decoded
(but where?) or change and reuse static bgp_find_update_afi (if possible)
to get AFI/SAFI information before processing the OTC attribute?
3) But the biggest problem is with *bgp_preexport*. It uses bgp_proto,
which doesn't use channel information when filtering routes with BGP
specific rules. And I don't find a way to add this support to this filter.
The question is - how to apply AFI/SAFI check for OTC attribute rules
during bgp export and where is the best place to do so? Of course, if we
want it to be like a predefined route-map.

On Thu, Jun 2, 2022 at 6:31 PM Ondrej Zajicek <santiago at crfreenet.org>
wrote:

> On Tue, May 31, 2022 at 02:38:07PM +0300, Eugene Bogomazov wrote:
> > Hello,
> >
> > RFC 9234 provides a new mechanism for route leak detection and
> prevention.
> >
> > In the attachment you can find a patch which introduces this
> functionality
> > for BIRD 2.0.9.
>
> Hello
>
> Thanks for the patch, i will check it soon. One issue i just noticed,
> could you also add patch for documentation (doc/bird.sgml), documenting
> these options?
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220614/a5caed77/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-PATCH-Update-documentation-for-RFC-9234.patch
Type: application/octet-stream
Size: 2701 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220614/a5caed77/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-PATCH-Remove-ROLE-MAX-and-update-config-option.patch
Type: application/octet-stream
Size: 1791 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220614/a5caed77/attachment-0001.obj>