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

Sab Feb 4 08:34:57 -03 2023

sed s/TIR/RIR/g

Fui traicionado por la ayuda del traductor. jajaja.

Em sex., 3 de fev. de 2023 às 21:40, Douglas Fischer <
fischerdouglas en gmail.com> escreveu:

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

-- 
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/20230204/3f15f6a0/attachment-0001.htm>