Summary

  • Sebastian Becker dijo en RIPE 92 que el AS-SET usado para filtrar el cono de clientes debe contener el AS del operador y sus redes aguas abajo. Pares y proveedores necesitan conjuntos distintos y etiquetas claras.
  • Su prueba previa compara lo que el cliente prevé anunciar con el filtro generado. El contraste de 100 prefijos declarados frente a 10.000 en la lista es una situación ilustrativa, no un incidente documentado.

Una lista pública puede parecer simple documentación hasta que se convierte en instrucciones para un router. Sebastian Becker, responsable de peering de AS3320 en Deutsche Telekom, dedicó su intervención en RIPE 92 a ese momento. La relación escrita en un AS-SET pasa a determinar los anuncios BGP que otro operador considera aceptables.

Su regla para el cono de clientes es concreta: incluir el AS propio y los AS o conjuntos de los clientes situados aguas abajo. El operador puede documentar pares y proveedores, pero en conjuntos separados. Si mezcla todos los tipos de relación, la expansión recursiva puede autorizar rutas ajenas al acuerdo de tránsito. La base de datos deja de describir un negocio y empieza a influir en el riesgo de fuga de rutas.

También importa de qué base IRR sale cada nombre. Becker advirtió que un AS-SET puede aparecer con la misma denominación en varios registros aunque solo se mantenga uno. Una copia olvidada, importada sin comprobar su origen, conserva relaciones que ya no representan la red. Pide indicar dónde se administra el conjunto y para qué se publica.

Becker planteó un caso para probar el procedimiento: un cliente dice que anunciará 100 prefijos; el filtro expandido alcanza 10.000. Según explicó, su equipo hace una ejecución de prueba antes de habilitar BGP o aceptar el filtro y devuelve la diferencia al cliente. Si se documenta la relación antes de que el cliente empiece a enviar rutas, el filtro puede estar preparado el primer día. La ficha oficial de la charla identifica a Fedor Vompe como coponente; las cifras de ciclos entre AS-SET que aparecen después pertenecen a la parte de Vompe.

Becker ya había anunciado en 2024 que AS3320 planeaba descartar orígenes RPKI inválidos y seguir aceptando los de estado desconocido. Validar el origen y definir el cono del cliente son decisiones distintas. Faltan comparaciones fechadas entre filtros previstos, rutas realmente recibidas y correcciones para saber cuántos errores evita el control previo.

La apuesta no está en escribir un AS-SET elegante. Está en impedir que un registro desordenado se convierta en una regla rápida y demasiado generosa en la red.

Fuentes: transcripción original de RIPE 92 · ficha oficial de la charla · biografía de RIPE NCC · anuncio original de 2024.