RFC 9234 route leak prevention in the wild!

Mailman List Mirror (Read Only)
1

Dear all,

I'd like to share an update on RFC 9234 deployment. RFC 9234 titled
"BGP Open Policy" aka the "Only-To-Customer" (OTC) BGP Path Attribute is
an anti-route-leak mechanism which is *NOT* based on RPKI! (yes ...
routing security is more than just RPKI! :slight_smile:

The basic idea of 9234 is that BGP routers (based on their role in the
Gao-Rexford inter-domain routing model) attach a special BGP Path
attribute, or take action based on the presence and contents of this BGP
Path attribute - with the intention to constrain a route's propagation
radius to just the downstream customer cone of the neighboring ASN.

Most operators will intuitively understand that any route propagating
through multiple IX route servers operated by different IXPs is a route
leak:

                 IXP_1         IXP_2
                /     \       /     \
               /       \     /       \
          ISP_A         ISP_B         ISP_C
        (receives)    (leaker)     (originates)
``` (figure 1. propagation from right to left; leak scenario)

In the above example, ISP\_A originates a route towards IXP\_1's route
servers, IXP\_1 propagates the route to ISP\_B \(so far so good\); but for
one reason or another ISP\_B subsequently continues propagation of the
route towards IXP\_2's route servers, who in turn propagate it to ISP\_C\.
ISP\_B is forwarding IP traffic between ISP\_A and ISP\_C for zero revenue\.
ISP\_A and ISP\_C are probably not expecting ISP\_B to be in the middle\.
This situation can happen as a result of a misconfiguration in ISP\_B's
equipment, even when all participants use IRR & RPKI ROV to attempt to
mitigate the worst routing incidents\.

What does it matter / impact
2

Do they have configuration snippets available anywhere?

With BIRD, it looks like a global "local role rs_server;" might be all that is needed.

3

I don’t know whether to say it’s ironic or not, but reading this, I was thinking “IX route servers may not be involved in the propagation, but I know from past experience that HE intentionally propagates some peer routes to other peers.”

And then your example leak has HE in the path. This may well be intentional and not a “leak” for some definitions of the word.

4

In addition to their own intention, they should ask if the other side agrees with that.

I don’t remember which research paper compiled this.
But the top 5 ASNs targeted by the no_export_to BGP communities at IXP Route-Servers say a lot about who mostly causes this type of problem.