<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Muy buenos días,</p>
<p> Deseo reenviar este excelente mensaje de Job Snijders en la
lista de NANOG que es igualmente interesante en nuestra región.</p>
<p> Desde LACNIC hemos apoyado y hemos visto con buenos ojos el RFC
9234 que se orienta a prevenir fugas en el mundo de BGP, como bien
indica Job: "routing security is more than just RPKI!" (La
seguridad en routing es más que solo BGP) :-)</p>
<p> Les dejo aquí algún material que hemos preparado:</p>
<p>.- <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=w0WDg4TO0ug">https://www.youtube.com/watch?v=w0WDg4TO0ug</a> (Roles en BGP. Una
mirada a como se configurará BGP en el futuro cercano - Ahora RFC
9234)</p>
<p>.- <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=l4ol0kqTmX4">https://www.youtube.com/watch?v=l4ol0kqTmX4</a> (presentación
LACNIC 38/LACNOG 2022: Un cambio Interesante se avecina en BGP
RFC 9234 )</p>
<p>.-
<a class="moz-txt-link-freetext" href="https://blog.lacnic.net/un-cambio-interesante-se-avecina-en-bgp/">https://blog.lacnic.net/un-cambio-interesante-se-avecina-en-bgp/</a>
(Blog post: Un cambio interesante se avecina en BGP)</p>
<p>.- Una topología en CONTAINERlab
<a class="moz-txt-link-freetext" href="https://github.com/alejandroacostaalamo/clab-topos/tree/main/clab-roles-bgp-frr">https://github.com/alejandroacostaalamo/clab-topos/tree/main/clab-roles-bgp-frr</a>
(está muy cruda, la idea es rellenarlo, con los videos e
información anterior seguro lo hacen :-) )<br>
</p>
<p><br>
</p>
<p>Saludos,</p>
<p><br>
</p>
<p>Alejandro,<br>
</p>
<p><br>
</p>
<div class="moz-forward-container">-------- Forwarded Message
--------
<table cellpadding="0" cellspacing="0" border="0"
class="moz-email-headers-table">
<tbody>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Subject:
</th>
<td>RFC 9234 route leak prevention in the wild!</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Date: </th>
<td>Mon, 2 Sep 2024 13:33:00 +0000</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">From: </th>
<td>Job Snijders via NANOG <a class="moz-txt-link-rfc2396E" href="mailto:nanog@nanog.org"><nanog@nanog.org></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Reply-To:
</th>
<td>Job Snijders <a class="moz-txt-link-rfc2396E" href="mailto:job@fastly.com"><job@fastly.com></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:nanog@nanog.org">nanog@nanog.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
Dear all,<br>
<br>
I'd like to share an update on RFC 9234 deployment. RFC 9234
titled<br>
"BGP Open Policy" aka the "Only-To-Customer" (OTC) BGP Path
Attribute is<br>
an anti-route-leak mechanism which is *NOT* based on RPKI! (yes
...<br>
routing security is more than just RPKI! :-)<br>
<br>
The basic idea of 9234 is that BGP routers (based on their role in
the<br>
Gao-Rexford inter-domain routing model) attach a special BGP Path<br>
attribute, or take action based on the presence and contents of
this BGP<br>
Path attribute - with the intention to constrain a route's
propagation<br>
radius to just the downstream customer cone of the neighboring
ASN.<br>
<br>
Most operators will intuitively understand that any route
propagating<br>
through multiple IX route servers operated by different IXPs is a
route<br>
leak:<br>
<br>
```<br>
IXP_1 IXP_2<br>
/ \ / \<br>
/ \ / \<br>
ISP_A ISP_B ISP_C<br>
(receives) (leaker) (originates)<br>
``` (figure 1. propagation from right to left; leak scenario)<br>
<br>
In the above example, ISP_A originates a route towards IXP_1's
route<br>
servers, IXP_1 propagates the route to ISP_B (so far so good); but
for<br>
one reason or another ISP_B subsequently continues propagation of
the<br>
route towards IXP_2's route servers, who in turn propagate it to
ISP_C.<br>
ISP_B is forwarding IP traffic between ISP_A and ISP_C for zero
revenue.<br>
ISP_A and ISP_C are probably not expecting ISP_B to be in the
middle.<br>
This situation can happen as a result of a misconfiguration in
ISP_B's<br>
equipment, even when all participants use IRR & RPKI ROV to
attempt to<br>
mitigate the worst routing incidents.<br>
<br>
What does it matter / impact<br>
============================<br>
<br>
Calgary-based YYCIX deployed RFC9234 support in late 2022/early
2023<br>
using OpenBGPD; and FranceIX deployed support using BIRD in Q2
2024.<br>
Both IXPs configured their route servers to reject BGP routes that
have<br>
an OTC attribute attached, and to attach an OTC attribute when<br>
propagating routes to the Route Server's peers.<br>
<br>
As it happens to be, currently (Mon Sep 2 12:26:50 UTC 2024) a
small route leak<br>
is happening involving both YYCIX and FranceIX Route Servers via
an ISP<br>
connected to both IXP's Route Servers; with the leak being stopped
at YYCIX<br>
thanks to RFC 9234! Appendix A contains a table of leaked IPv4
routes.<br>
<br>
Let's zoom in on 1 entry:<br>
<br>
```<br>
$ bgpctl show rib 157.185.154.0/24 detail<br>
BGP routing table entry for 157.185.154.0/24<br>
6939 38040 54994<br>
Nexthop 206.126.225.20 (via 206.126.225.20) Neighbor
206.126.225.20 (216.218.252.194)<br>
Origin IGP, metric 1911, localpref 100, weight 0, ovs not-found,
avs unknown, external, otc leak<br>
Last update: 11:58:08 ago<br>
Communities: 0:2906 0:16265 0:16276 0:18638 0:41690 0:48641
0:49029<br>
Ext. Communities: ovs not-found<br>
Large Communities: 53339:11:1 53339:11:3<br>
Aggregator: 54994 [163.171.131.254]<br>
OTC: 51706<br>
``` (figure 2. inspecting an leaked route using OpenBGPD's CLI)<br>
<br>
In figure 2. one can see the route is marked as 'otc leak', this
was<br>
made possible because FranceIX's route server's attached the OTC<br>
attribute with the ASN value set to their Route Server's ASN
(51706).<br>
<br>
```<br>
YYCIX FranceIX<br>
. x <adds OTC> \<br>
. \ / \<br>
ISP_A 6939_38040 54994<br>
``` (figure 3. right to left: real world example of blocked leak)<br>
<br>
In figure 3 AS 54994 originates 157.185.154.0/24 and propagates a
route<br>
towards the FranceIX route servers. FranceIX accepts this route<br>
(probably because an IRR route object exists) and propagates it
onward<br>
with the "Only-To-Customer" attribute set to 51706. The route is<br>
received by AS 38040, who appear to propagate the route to their<br>
upstream 6939. << An AS 38040 router is likely
misconfigured! >><br>
Then 6939 sends its customer's routes to the YYCIX route server,
but the<br>
YYCIX route server recognizes that the route already passed
through a<br>
'valley' and thus considers this a leak; and blocks further
propagation<br>
towards ISP_A.<br>
<br>
Impact with partial deployment<br>
==============================<br>
<br>
RFC 9234 is an easy mechanism to configure and debug for both
small &<br>
large network operators and IXP route server operators. In the
above<br>
scenario YYCIX and FranceIX are likely the only 2 entities in the
entire<br>
AS path which support RFC 9234; but we're already seeing leaks
being<br>
blocked despite partial deployment!<br>
<br>
It's not hard to imagine that many IX-to-IX route leaks can be
blocked<br>
with only the IXP operators themselves enabling RFC 9234 support.<br>
The world's most populair RS implementations (BIRD and OpenBGPD)<br>
already support RFC 9234! Tens of thousands of IX customers would
enjoy<br>
the benefits of a few hundred IXPs taking action. RFC 9234 has no<br>
dependency on the RPKI, this means tha<br>
<br>
What can you do?<br>
================<br>
<br>
Just ask your vendors (your hardware routers and IXPs) to
implement and<br>
deploy RFC 9234! :-) The more people ask, the more it'll bubble to
the<br>
top of the priority list. The cost of implementing & deploying
RFC 9234<br>
is excellent bang for buck.<br>
<br>
Closing words<br>
=============<br>
<br>
Shout out to our friends at FranceIX and MSK-IX for being amongst
the<br>
first IXPs to deploy RFC 9234! Your effort helped reduce the
potential<br>
impact of today's route leak!<br>
<br>
Kind regards,<br>
<br>
Job<br>
(YYCIX volunteer)<br>
<br>
Appendix A:<br>
-----------<br>
<br>
Vantage point: YYCIX Route Server 1 (rs1.yycix.ca)<br>
Timestamp: Mon Sep 2 12:31:50 UTC 2024<br>
<br>
Destination Prefix AS_PATH<br>
102.164.129.0/24 6939 37613 6758 37649 i<br>
102.164.139.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i<br>
102.164.140.0/24 6939 37613 6758 37649 i<br>
102.164.141.0/24 6939 37613 6758 37649 i<br>
102.164.182.0/24 6939 37613 6758 37649 i<br>
154.65.33.0/24 6939 37613 6758 37649 i<br>
154.65.34.0/24 6939 37613 6758 37649 i<br>
154.65.35.0/24 6939 37613 6758 37649 i<br>
154.65.36.0/24 6939 37613 6758 37649 i<br>
154.65.37.0/24 6939 37613 6758 37649 i<br>
154.65.38.0/24 6939 37613 6758 37649 i<br>
154.65.39.0/24 6939 37613 6758 37649 i<br>
154.72.35.0/24 6939 37613 37100 37027 37063 327721 i<br>
157.185.151.0/24 6939 38040 54994 i<br>
157.185.154.0/24 6939 38040 54994 i<br>
163.171.164.0/24 6939 38040 54994 i<br>
192.150.250.0/23 6939 4651 4618 4618 63529 4621 3836 i<br>
196.50.8.0/24 6939 37613 6758 37649 i<br>
196.50.9.0/24 6939 37613 6758 37649 i<br>
196.50.11.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i<br>
196.50.13.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i<br>
196.50.14.0/24 6939 37613 6758 37649 i<br>
2001:67c:15f4::/48 6939 41103 i<br>
2401:c500:fd08::/48 6939 4637 38040 54994 i<br>
2a01:53c0:ff03::/48 6939 4637 38040 54994 i<br>
2a01:53c0:ff0f::/48 6939 4637 38040 54994 i<br>
2a01:58c0::/32 6939 16347 42487 i<br>
2a03:8920::/32 6939 41103 i<br>
2a03:d602::/31 6939 16347 42487 i<br>
2a03:d606::/31 6939 16347 42487 i<br>
2a0d:ee00::/32 6939 16347 42487 i<br>
2a0e:5b80::/29 6939 16347 42487 i<br>
2a0e:e080::/32 6939 16347 42487 i<br>
2a0f:c540::/29 6939 16347 42487 i<br>
<br>
</div>
</body>
</html>