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

Vie Feb 3 11:44:24 -03 2023

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!

On Fri, Feb 3, 2023 at 9:42 AM Tomas Lynch <tomas.lynch en gmail.com> wrote:

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