<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Y me olvidé de agregar IPv6 en las líneas de listas de acceso al usar IRR pero la idea es ver la magnitud de diferencia!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 3, 2023 at 9:42 AM Tomas Lynch <<a href="mailto:tomas.lynch@gmail.com">tomas.lynch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">> <span style="font-family:Arial,Helvetica,sans-serif">Vale la pena alabar la base de IRR de LACNIC, que es casi 100% limpia ya que se crea a partir de RPKI ROA</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">Douglas, creo que te contradices con esta frase! ;) Entonces si sirve RPKI?</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">El tema de los IRR es que no fue controlado desde un principio, puede ser que haya sido por no agregar la capa X.509 pero también recuerdo que cada tránsito tenía su IRR, cualquiera podía, y puede, abrir un IRR. En algún momento esto se concentró en RADb y empezaron a cobrar un fee para que no haya abusos pero ya era tarde e incluso los abusos, aunque menores siguen existiendo.</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">Por otro lado, en los IRR, ¿quién sería el trust anchor? (¿lo dije bien?) Me parece que si los RIRs son esa entidad, entonces está todo mucho mejor organizado y controlado, entras en un solo lugar donde tienes asignados tus prefijos y ASNs, y creas tus ROAs a partir de datos confiables con poca posibilidad de error: que levante la mano el no haya hecho un route-object con el ASN equivocado.</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">En el aspecto operativo, es tan simple como configurar un servidor Fort o routinator y levantar RTR desde tus routers de borde. En el caso de los equipos que manejo yo tengo dos </span>routinator<span style="font-family:Arial,Helvetica,sans-serif"> en dos VMs y la configuración en los routers son literalmente 2 líneas. Luego agregas en tus políticas de entrada tres términos para decidir qué hacer con los "invalid", "valid", y "unknown"; en mi caso 12 líneas por proveedor de tránsito.</span><br></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">Para el caso de IRR, en el aspecto operativo nuevamente, el tema se complica: tienes que tener dos listas de acceso por ASN donde estén listados los prefijos IP4 en una, IPv6 en otra. Y encima necesitas una entrada de cron para actualizar esos listados al menos una vez por día (ymmv).</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">Tengo una estadística, nosotros hacemos peering directo, es decir no IXP, con 303 ASNs. De estos ASNs, el 60% dice propagar hasta un máximo de 1.000 prefijos según peeringdb. Gracias a que no todos usan RPKI, debo basar mis filtros en IRRs, para cubrir ese 60% (182 ASNs) y suponiendo que no todos están juntos pero muchos si, estoy agregando por router de edge unas 10.000 líneas de código.</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">RPKI: 2 + 12 * 182 ~ 2.000 líneas de código por router</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">IRR: ~ 10.000 líneas de código por router</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 3, 2023 at 5:38 AM Douglas Fischer <<a href="mailto:fischerdouglas@gmail.com" target="_blank">fischerdouglas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">¡Muy interesante!<br><br>Veo cosas buenas que se pueden hacer con este protocolo.<br>(Y muchos fat-fingers también. jajaja)<br><br>Pero, sinceramente, tengo la sensación de que estamos reinventando la rueda. Lo mismo que siento por RPKI lo siento por ASPA.<br><br>El conjunto de características que ofrecen los protocolos IRR es aún más superior que lo que se puede hacer con RPKI+ASPA.<br><br>Solo para ilustrar, la validación de origen que ofrece el IRR ha sido desacreditada por:<br> 1- La omisión de muchas ASN que no hicieron los deberes.<br> 2- Acciones hipócritas de empresas que crearon registros proxy.<br> 2.1- Ser agravado por quienes mintieron descaradamente el AS de origen en los Objetos de ROUTE[6].<br> 3- Bases de datos IRR que además eran hipócritas y no hacían ningún tipo de control de registro proxy o similar, permitiendo crear un enorme legado de objetos erróneos.<br><br>P.D.: Vale la pena alabar la base de IRR de LACNIC, que es casi 100% limpia ya que se crea a partir de RPKI ROAa, y un cumplido mayor a TC(<a href="http://bgp.net.br" target="_blank">bgp.net.br</a>) que siempre ha tenido la regla de no permitir registros de Proxy y que el 100% de su base está vinculada a delegaciones realizadas por <a href="http://NIC.BR" target="_blank">NIC.BR</a>.<br><br>"aaaa, pero el RPSL/IRR no tiene firmas criptográficas"<br>Esto se habría manejado fácilmente con la adición de una capa X.509 en la IRR.<br>O incluso, teniendo en cuenta que el concepto de TIR se basa en una base distribuida, portar estas bases a un concepto de cadena de bloques (conozco un proyecto académico que se está ocupando de esto en este momento).<br><br>Sí, sé que suena como un anciano diciendo eso:<br>"aaa, en mi época era mucho mejor..."<br>Disculpe por eso...<br>Pero cada día que pasa confirmo que las evoluciones protocolares son un ejemplo puro de Razón Dialéctica, con sus tesis, antítesis y nuevas (viejas) síntesis.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 2 de fev. de 2023 às 20:52, Alejandro Acosta <<a href="mailto:alejandroacostaalamo@gmail.com" target="_blank">alejandroacostaalamo@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>FYI, interesante.<br>
</p>
<div><br>
<br>
-------- Forwarded Message --------
<table cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap align="RIGHT">Subject:
</th>
<td>Calgary Internet Exchange (YYCIX) deploys world's first
ASPA-filtering Route Servers</td>
</tr>
<tr>
<th valign="BASELINE" nowrap align="RIGHT">Date: </th>
<td>Thu, 2 Feb 2023 18:57:09 +0000</td>
</tr>
<tr>
<th valign="BASELINE" nowrap align="RIGHT">From: </th>
<td>Job Snijders <a href="mailto:job@sobornost.net" target="_blank"><job@sobornost.net></a></td>
</tr>
<tr>
<th valign="BASELINE" nowrap align="RIGHT">To: </th>
<td><a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
CALGARY, CA-AB, Feb. 2, 2023 - The Calgary Internet Exchange
(YYCIX) is<br>
thrilled to announce the deployment of the world's first
ASPA-filtering<br>
Route Servers on a public peering fabric. The YYCIX Route Servers
drop<br>
ASPA-invalid BGP routes in order to protect multilateral peers.<br>
<br>
ASPA (Autonomous System Provider Authorization) is a free
RPKI-based<br>
technology for detection and mitigation of BGP route leaks. ASPA
enables<br>
holders of Autonomous System identifiers to securely authorize one
or<br>
more other Autonomous Systems as their upstream providers, in turn<br>
enabling Relying Parties (ISPs and IXPs) to use this
cryptographically<br>
verifiable information to automatically stop improbable BGP paths
from<br>
spreading through the global Internet routing system.<br>
<br>
ASPA complements other routing safety & security mechanisms:
RPKI-ROV<br>
helps guard against fat-finger keyboard input errors, BGPsec helps<br>
establish strong assurances about BGP message authenticity &
integrity,<br>
and finally ASPA helps stop route leaks. The key to worry-free
routing<br>
operations will be to use all three in tandem.<br>
<br>
The ASPA specification is in active development as a freely
accessible<br>
open standard through the collaborative Internet Engineering Task
Force<br>
(IETF) process. YYCIX volunteers took on a leading role as early<br>
adopters (or 'lighthouse customer') to foster an environment in
which<br>
real-world feedback can be contributed to the OpenBGPD developers
and<br>
ASPA specification authors in the SIDROPS working group. Our hope
is<br>
that many vendors and operators will embrace ASPA in the years to
come.<br>
<br>
About YYCIX Internet Exchange Community Ltd<br>
===========================================<br>
YYCIX is incorporated as a volunteer-driven tax-exempt non-profit<br>
corporation in Canada's third-largest municipality. YYCIX provides<br>
Alberta residents with direct access to local Internet content and
helps<br>
increase the transfer speed of Internet communications between
Alberta<br>
companies, friends, neighbors and family members.
<a href="https://www.yycix.ca/" target="_blank">https://www.yycix.ca/</a><br>
<br>
About OpenBGPD & Rpki-client<br>
============================<br>
Rpki-client is an freely usable and secure implementation of the
RPKI<br>
for Relying Parties to facilitate validation of BGP announcements.
The<br>
program queries the global RPKI repository system, verifies all<br>
cryptographic signatures, and outputs validated data in
configuration<br>
formats suitable for OpenBGPD and StayRTR.
<a href="https://www.rpki-client.org/" target="_blank">https://www.rpki-client.org/</a><br>
<br>
OpenBGPD is a free implementation of the IETF's Border Gateway
Protocol<br>
suitable for ISPs and IXPs. OpenBGPD allows ordinary machines to
be used<br>
as routers or route servers exchanging routes with other systems.<br>
ASPA-filtering in OpenBGPD was developed with support from the
German<br>
Ministry for Economic Affairs & Climate Action's Sovereign
Tech Fund,<br>
and the Route Server Support Foundation (RSSF -
<a href="https://www.rssf.nl/" target="_blank">https://www.rssf.nl/</a>)<br>
<a href="https://www.openbgpd.org/" target="_blank">https://www.openbgpd.org/</a><br>
<br>
OpenBGPD and rpki-client are part of the OpenBSD Project; and run
on a<br>
wide variety of operating systems such as Debian, Ubuntu, Alpine,<br>
CentOS, Fedora, FreeBSD, Red Hat, and of course OpenBSD!<br>
</div>
</div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div>
</blockquote></div>