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

[Douglas Fischer]

¡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!

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


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

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.


> 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?
¿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?


>
>
> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20230203/a9a984ce/attachment-0001.htm>