[lacnog] Fwd: Calgary Internet Exchange (YYCIX) deploys world's first ASPA-filtering Route Servers

Sab Feb 4 17:04:18 -03 2023

On Fri, Feb 3, 2023 at 7:40 PM Douglas Fischer <fischerdouglas en gmail.com>
wrote:

> ¡Hola Tomás!
> Te respondo con comentarios en línea.
>
> P.D.: Sé que esto suena como una charla de nerd, ¡pero me encanta este
> tipo de charla!
>
> ++1

> Em sex., 3 de fev. de 2023 às 11:42, Tomas Lynch <tomas.lynch en gmail.com>
> escreveu:
>
>> > Vale la pena alabar la base de IRR de LACNIC, que es casi 100% limpia
>> ya que se crea a partir de RPKI ROA
>>
>> Douglas, creo que te contradices con esta frase! ;) Entonces si sirve
>> RPKI?
>>
>
> ¡No creo que me esté contradiciendo!
> ¡Dije que sí que la TIR de LACNIC está limpia! Pero no dije por qué está
> limpio...
> El gran error que se cometió en IRR y no en RPKI tiene que ver con los
> datos autorizados.
> - ¿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?
> - Solo el "propietario" del bloque X.Y.Z.0/22.
>
> En otras palabras... ¡MALDITO OBJETOS PROXY!
> ¿Prueba de eso?
> ¡La base de TC (bgp.net.br), que solo guarda objetos autoritativos!
> O la propia base de RIPE, que se convirtió en RIPE y RIPE-NONAUTH
>
>
Definitivamente los objetos proxy fueron los que crearon, y crean, mucho
del ruido en los IRRs pero también hay mucho cliente que tiene un prefijo
quiere conectarse a un proveedor de servicios y no tiene ni la más remota
idea de que existe un IRR, o registran erróneamente sus prefijos y entonces
el proveedor opta por registrar los prefijos de su cliente.

Si, se soluciona educando pero no muchos tienen tiempo. Siempre pienso en
el ISP pequeño donde el ingeniero de redes también explica cómo enviar
"attachments", repara la impresora, a las 3AM sale corriendo de su casa a
reparar un enlace y cuando puede lee estas discusiones.

>> 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.
>>
>
> 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.
> 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.
>

>> 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.
>>
>
> 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.
> Bueno... yo creo que si hubiera sido así, y con la purga de todos los
> objetos no autorizados (Proxyed) de las bases, hubiera funcionado.
> Pero ahora ese "si" ya no sirve...
>
> Desconozco la historia pero creo que la decisión fue esa: el tiempo en
limpiar las IRR contra el tiempo de crear un nuevo sistema/protocolo.
Limpiar las bases de IRR creo yo que es una tarea digna de Sísifo y por
ello se decidió crear un nuevo sistema.

> Sobre su pregunta sobre "¿quién sería el trust anchor?"
> Me encanta la idea de la ausencia de trust anchors (me imagino algo entre
> anarquía y multistakeholder). Y para eso...
> - Justo hoy escuché de un amigo: "Blockchain es una solución que está en
> busca un problema".
> 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.
> "¿Y esto tiene alguna posibilidad de ser adoptado?"
> Teniendo en cuenta las etapas actuales de RPKI y ASPA, ¡estoy bastante
> seguro de que no! Pero académicamente podría tener sentido.
>
> No puedo opinar mucho sobre blockchain pero podría haber sido adoptado.

>
>> 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 routinator 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.
>>
>> 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).
>>
>> 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.
>>
>> RPKI: 2 + 12 * 182 ~ 2.000 líneas de código por router
>> IRR: ~ 10.000 líneas de código por router
>>
>
> En eso, ¡tienes mucha razón!
> Pero...
> ¿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?
>
Para mi es RTR y la sencillez de firmar ROAs dentro del RIR. Insisto en que
por mucha buena voluntad que uno tenga, siempre puede cometer errores con
los IRR y registrar como propio a 2001:db8:0101::/48 en lugar de
2001:db8:1010::/48. En la firma de ROA estos errores se minimizan.

> ¿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?
> ¿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?
>
> Completamente de acuerdo con estas dos preguntas pero, insisto, quien
haya tomado la decisión seguramente evaluó los tiempos entre limpiar los
IRRs y crear un nuevo protocolo. También debe de haber evaluado la
utilización de RPSL para la configuración de los filtros: quién lo usa,
cuántos lo usan activamente, etc.

Por ahora lo que yo sé es que firmamos ROAs y también registramos objetos
en los IRR. Sería MUY interesante tener un solo "source of truth", creo que
con el tiempo este será RPKI.

>
>>
>>
>> On Fri, Feb 3, 2023 at 5:38 AM Douglas Fischer <fischerdouglas en gmail.com>
>> wrote:
>>
>>> ¡Muy interesante!
>>>
>>> Veo cosas buenas que se pueden hacer con este protocolo.
>>> (Y muchos fat-fingers también. jajaja)
>>>
>>> Pero, sinceramente, tengo la sensación de que estamos reinventando la
>>> rueda. Lo mismo que siento por RPKI lo siento por ASPA.
>>>
>>> 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.
>>>
>>> Solo para ilustrar, la validación de origen que ofrece el IRR ha sido
>>> desacreditada por:
>>>   1- La omisión de muchas ASN que no hicieron los deberes.
>>>   2- Acciones hipócritas de empresas que crearon registros proxy.
>>>   2.1- Ser agravado por quienes mintieron descaradamente el AS de origen
>>> en los Objetos de ROUTE[6].
>>>   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.
>>>
>>> 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(
>>> bgp.net.br) 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
>>> NIC.BR.
>>>
>>> "aaaa, pero el RPSL/IRR no tiene firmas criptográficas"
>>> Esto se habría manejado fácilmente con la adición de una capa X.509 en
>>> la IRR.
>>> 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).
>>>
>>> Sí, sé que suena como un anciano diciendo eso:
>>> "aaa, en mi época era mucho mejor..."
>>> Disculpe por eso...
>>> 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.
>>>
>>> Em qui., 2 de fev. de 2023 às 20:52, Alejandro Acosta <
>>> alejandroacostaalamo en gmail.com> escreveu:
>>>
>>>> FYI, interesante.
>>>>
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: Calgary Internet Exchange (YYCIX) deploys world's first
>>>> ASPA-filtering Route Servers
>>>> Date: Thu, 2 Feb 2023 18:57:09 +0000
>>>> From: Job Snijders <job en sobornost.net> <job en sobornost.net>
>>>> To: nanog en nanog.org
>>>>
>>>> CALGARY, CA-AB, Feb. 2, 2023 - The Calgary Internet Exchange (YYCIX) is
>>>> thrilled to announce the deployment of the world's first ASPA-filtering
>>>> Route Servers on a public peering fabric. The YYCIX Route Servers drop
>>>> ASPA-invalid BGP routes in order to protect multilateral peers.
>>>>
>>>> ASPA (Autonomous System Provider Authorization) is a free RPKI-based
>>>> technology for detection and mitigation of BGP route leaks. ASPA enables
>>>> holders of Autonomous System identifiers to securely authorize one or
>>>> more other Autonomous Systems as their upstream providers, in turn
>>>> enabling Relying Parties (ISPs and IXPs) to use this cryptographically
>>>> verifiable information to automatically stop improbable BGP paths from
>>>> spreading through the global Internet routing system.
>>>>
>>>> ASPA complements other routing safety & security mechanisms: RPKI-ROV
>>>> helps guard against fat-finger keyboard input errors, BGPsec helps
>>>> establish strong assurances about BGP message authenticity & integrity,
>>>> and finally ASPA helps stop route leaks. The key to worry-free routing
>>>> operations will be to use all three in tandem.
>>>>
>>>> The ASPA specification is in active development as a freely accessible
>>>> open standard through the collaborative Internet Engineering Task Force
>>>> (IETF) process. YYCIX volunteers took on a leading role as early
>>>> adopters (or 'lighthouse customer') to foster an environment in which
>>>> real-world feedback can be contributed to the OpenBGPD developers and
>>>> ASPA specification authors in the SIDROPS working group. Our hope is
>>>> that many vendors and operators will embrace ASPA in the years to come.
>>>>
>>>> About YYCIX Internet Exchange Community Ltd
>>>> ===========================================
>>>> YYCIX is incorporated as a volunteer-driven tax-exempt non-profit
>>>> corporation in Canada's third-largest municipality. YYCIX provides
>>>> Alberta residents with direct access to local Internet content and helps
>>>> increase the transfer speed of Internet communications between Alberta
>>>> companies, friends, neighbors and family members. https://www.yycix.ca/
>>>>
>>>> About OpenBGPD & Rpki-client
>>>> ============================
>>>> Rpki-client is an freely usable and secure implementation of the RPKI
>>>> for Relying Parties to facilitate validation of BGP announcements. The
>>>> program queries the global RPKI repository system, verifies all
>>>> cryptographic signatures, and outputs validated data in configuration
>>>> formats suitable for OpenBGPD and StayRTR. https://www.rpki-client.org/
>>>>
>>>> OpenBGPD is a free implementation of the IETF's Border Gateway Protocol
>>>> suitable for ISPs and IXPs. OpenBGPD allows ordinary machines to be used
>>>> as routers or route servers exchanging routes with other systems.
>>>> ASPA-filtering in OpenBGPD was developed with support from the German
>>>> Ministry for Economic Affairs & Climate Action's Sovereign Tech Fund,
>>>> and the Route Server Support Foundation (RSSF - https://www.rssf.nl/)
>>>> https://www.openbgpd.org/
>>>>
>>>> OpenBGPD and rpki-client are part of the OpenBSD Project; and run on a
>>>> wide variety of operating systems such as Debian, Ubuntu, Alpine,
>>>> CentOS, Fedora, FreeBSD, Red Hat, and of course OpenBSD!
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>
>>>
>>>
>>> --
>>> Douglas Fernando Fischer
>>> Engº de Controle e Automação
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> _______________________________________________
> LACNOG mailing list
> LACNOG en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/lacnog
> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20230204/4c574e00/attachment-0001.htm>