<div dir="ltr"><div>¡Hola Tomás!<br>Te respondo con comentarios en línea.<br><br>P.D.: Sé que esto suena como una charla de nerd, ¡pero me encanta este tipo de charla!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sex., 3 de fev. de 2023 às 11:42, Tomas Lynch <<a href="mailto:tomas.lynch@gmail.com">tomas.lynch@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 dir="ltr"><div 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 style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div 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></blockquote><div><br>¡No creo que me esté contradiciendo!<br>¡Dije que sí que la TIR de LACNIC está limpia! Pero no dije por qué está limpio...<br>El gran error que se cometió en IRR y no en RPKI tiene que ver con los datos autorizados.<br>- ¿Quién puede decir qué rutas del bloque IP X.Y.Z.0/22 serán originadas por el ASN de Telefónica o por el ASN de la organización propietaria del bloque X.Y.Z.0/22?<br>- Solo el "propietario" del bloque X.Y.Z.0/22.<br><br>En otras palabras... ¡MALDITO OBJETOS PROXY!<br>¿Prueba de eso?<br>¡La base de TC (<a href="http://bgp.net.br">bgp.net.br</a>), que solo guarda objetos autoritativos!<br>O la propia base de RIPE, que se convirtió en RIPE y RIPE-NONAUTH<br><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 style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div 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></blockquote><div><br>La cuestión de la firma criptográfica es realmente importante. Pero CIERTAMENTE menos impactante para limpiar las bases que las limitaciones del alcance de creación de objetos.<br>Lo que hizo que RPKI tuviera éxito fue lo mismo que hizo que tardara tanto en ganar tracción. El hecho de que se definiera exclusivamente como emisión autoritativas de ROA.<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 style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div 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></blockquote><div><br></div><div>Soy nuevo en este mundo de internet, pero por lo que he leído sobre eventos en el pasado, en algún momento se consideró que si le agregas una capa X.509 a la RSPL/IRR, y de la misma manera a la RPKI, esta cadena de delegaciones de certificados estará anclada en los respectivos RIRs. Esa idea no tuvo éxito... Todos estaban tan consternados por la cantidad de registros erróneos que había en las bases de datos de IRR que no creían que sería posible limpiar ese desorden.<br>Bueno... yo creo que si hubiera sido así, y con la purga de todos los objetos no autorizados (Proxyed) de las bases, hubiera funcionado.<br>Pero ahora ese "si" ya no sirve...<br><br>Sobre su pregunta sobre "¿quién sería el trust anchor?"<br>Me encanta la idea de la ausencia de trust anchors (me imagino algo entre anarquía y multistakeholder). Y para eso...</div><div>- Justo hoy escuché de un amigo: "Blockchain es una solución que está en busca un problema".<br>Pensando en los conceptos de la base distribuida de Blockchain (y sus criterios de desempate), y comparándolo con el concepto de bases distribuidas del ecosistema IRR y el tan deseado NRTMv4, creo que tiene sentido la idea de adaptarse a la RPSL/IRR. entro del concepto de Blockchain.<br>"¿Y esto tiene alguna posibilidad de ser adoptado?"<br>Teniendo en cuenta las etapas actuales de RPKI y ASPA, ¡estoy bastante seguro de que no! Pero académicamente podría tener sentido.<br></div><div><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 style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div 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 style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div 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 style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div 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 style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div 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 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></blockquote><div><br></div><div>En eso, ¡tienes mucha razón!<br>Pero...<br>¿Estás de acuerdo en que la pieza que hace toda esta "magia" de la sencillez en los routers no es la propia RPKI, sino la RTR?<br>¿Está de acuerdo en que hubo un tiempo muerto en el desarrollo de tecnología para mejorar los mecanismos de filtrado basados en la TIR?<br>¿Podría ser que si en lugar de RPKI este RPSL-NG-Crypto-NGAgain hubiera tenido tracción, hubiéramos visto mejoras importantes en estos mecanismos de filtrado basados en IRR?<br></div><div><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 style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div 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>
_______________________________________________<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" class="gmail_signature"><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></div>