Resumen

  • draft-ietf-spring-srv6-security-16 define el dominio de confianza como una construcción lógica y operativa donde se cumple el supuesto de filtrado en la frontera, no como un lugar físico.
  • El texto contempla varias instancias SR bajo una sola entidad administrativa que siguen siendo distintas. Propietario, edificio o marca común no constituyen una autorización.
  • La frontera puede fallar abierta si una regla se modifica mal o el equipo no tiene capacidad suficiente. Mirar únicamente la presencia de SRH tampoco identifica todo el tráfico relevante.
  • Un manifiesto de frontera y recibo de ejecución debe unir membresía, rangos, claves, reglas previstas e instaladas, capacidad y pruebas. Es una propuesta editorial, no una exigencia del IETF.

El día en que «propio» sustituyó a «autorizado»

Una integración empresarial produce un vocabulario nuevo. Los enlaces entre dos redes dejan de llamarse externos y pasan a ser internos. Los equipos reciben un nombre común. El centro de costes se unifica. Nada de eso obliga a que una fuente admitida en el primer dominio pueda imponer instrucciones de encaminamiento en el segundo.

Antes de la operación corporativa, cada instancia SRv6 podía tener su propio plan de SID, sus controladores, su material criptográfico y sus límites de entrada y salida. Si esas propiedades no cambian de forma comprobable, retirar el control intermedio no simplifica una frontera ya inexistente: amplía la autoridad de una red sobre otra.

La revisión 16 de Segment Routing IPv6 Security Considerations ofrece una definición precisa. Llama dominio de confianza al dominio SR en el que está vigente el supuesto de filtrado de RFC 8402. Aclara que es una construcción lógica y operativa, no una frontera física. Incluso un servidor conectado a la misma red queda fuera hasta que se incorpore explícitamente a sus controles.

La frase decisiva llega después: puede haber varias instancias SR bajo una misma entidad administrativa y, aun así, ser distintas lógica u operacionalmente. Para el modelo de amenazas del documento, un origen situado en otro dominio de confianza se considera externo. El nombre del dueño no borra esa separación.

Una consulta abierta no es un certificado

El IESG anunció el Last Call de la revisión 16 el 3 de septiembre de 2026 y fijó el 17 de septiembre como fecha límite para comentarios. Al corte de esta investigación, el 9 de septiembre, Datatracker mostraba un Internet-Draft activo del grupo SPRING, con intención Informational. No había fecha de telechat y el estado del grupo indicaba que hacía falta una revisión por una cuestión surgida en el Last Call del grupo de trabajo.

Es un estado de deliberación, no un resultado anticipado. La revisión 16 no es un RFC ni una certificación de despliegue. Tampoco define un protocolo o una extensión de seguridad nuevos. Su valor aquí consiste en hacer visible el supuesto que una operación real debe sostener.

RFC 8402 dispone que Segment Routing funciona por defecto dentro de un dominio de confianza y que el tráfico debe filtrarse en sus límites. Además presupone que el nodo que inserta una lista de segmentos o un SRH tiene permiso para hacerlo. Si la membresía se expande por conveniencia administrativa, también se expande esa capacidad. Por eso la decisión necesita evidencia propia.

Declarar, instalar y demostrar son actos distintos

El borrador reconoce que aplicar una frontera fiable puede ser difícil. Todos los bordes deben conservar reglas correctas. Un cambio erróneo puede generar fugas de entrada o salida. Y la plataforma puede carecer del espacio, la complejidad de coincidencia o el soporte de protocolo necesarios para ejecutar la política.

Así aparece el modo de fallo abierto. Un ataque que el análisis consideraba viable solo para alguien ya dentro puede quedar al alcance de un origen externo cuando uno de los dispositivos deja de imponer la regla que definía el dominio.

Conviene separar tres planos de evidencia. La membresía declarada enumera nodos, fuentes, controladores y funciones autorizadas. La política prevista describe bordes, rangos y excepciones. La ejecución observada muestra qué reglas están instaladas, cuánta capacidad queda y cómo respondieron las pruebas.

Un repositorio de configuración no basta. Puede probar que se aprobó una intención, pero no que todos los equipos la aceptaron, que el contador corresponde a la regla actual o que el comportamiento sobrevivió a una actualización. Un mensaje de éxito tampoco revela necesariamente una tabla agotada o una función degradada.

Durante una fusión, esas diferencias suelen aumentar. Una red puede reservar rangos reconocibles para sus SID; la otra, repartirlos de forma más compleja. Una encapsula en el ingreso; otra depende de controles diferentes. Una tiene margen en sus ACL o TCAM; otra comparte ese recurso con muchas funciones. La propiedad común no homogeneiza el silicio.

El SRH no es una pulsera de acceso

Filtrar todo paquete que contenga SRH parece una regla clara, pero la revisión 16 explica sus límites. El procesamiento de un SID no siempre necesita SRH. Y un paquete con SRH puede estar simplemente en tránsito, sin dirigirse al dominio. La presencia del encabezado produce falsos negativos y falsos positivos como criterio único.

La relación entre origen, destino y rango es más útil. En un ingreso, el tráfico que llega desde fuera y se dirige a un SID interno debe descartarse. En un nodo SRv6, también debe rechazarse el paquete destinado a un SID local cuando la fuente está fuera del dominio. Si fallan ambos controles, la frontera se abre.

Esa política exige conocer con precisión los rangos de infraestructura. RFC 9602 ofrece un prefijo dedicado para SID SRv6, y el borrador señala que otras elecciones pueden complicar el filtrado y aumentar el riesgo de fuga de rutas o error humano. No dicta un único diseño; obliga a que la regla corresponda al diseño real.

La encapsulación en el ingreso puede añadir una envoltura IPv6 y un SRH originados por un nodo fiable. Con ello, las decisiones internas dejan de depender de campos aportados por una fuente no confiable. Pero no sustituye el filtrado de la frontera. Es una capa complementaria, no una autorización universal.

Una clave compartida puede ocultar una frontera perdida

RFC 8754 define un TLV HMAC opcional. Puede proteger el listado de segmentos y otros campos concretos. La revisión 16 advierte que la gestión manual de claves precompartidas favorece atajos y afirma que no debe usarse la misma clave en dominios de confianza distintos, aunque ambos residan en el mismo nodo.

Ese caso demuestra que ni siquiera el chasis fija el perímetro. Un equipo físico puede ejecutar dos dominios con autoridades diferentes. Compartir la máquina no justifica compartir el secreto.

La verificación criptográfica tampoco agota la decisión. Un nodo legítimo comprometido que posee la clave sigue siendo un atacante interno en el modelo. Un actor interno sin ella puede reproducir un SRH y un HMAC válidos capturados durante la vigencia de la clave. HMAC aporta integridad delimitada; no convierte al tenedor en autoridad para cualquier trayecto.

Si la integración adopta una clave para todo el grupo, el éxito criptográfico puede confundirse con legitimidad. Después será más difícil demostrar dónde terminaba cada autoridad o separar de nuevo los entornos.

Un recibo para la frontera real

La alternativa es mantener un manifiesto de frontera del dominio de confianza y generar un recibo de ejecución en cada cambio. No altera SRv6 ni se presenta como norma del IETF. Organiza la evidencia que ya necesita el operador.

El manifiesto asigna una identidad versionada al dominio. Enumera nodos y funciones admitidos, puntos de ingreso y egreso, rangos de SID y fuentes, autoridades de control, lugares de encapsulación y dominios de claves sin publicar secretos. Cada cruce hacia otro dominio conserva responsable, motivo y caducidad.

El recibo enlaza esa intención con lo observado: reglas que cada equipo declara instaladas, capacidad disponible, contadores, una prueba negativa desde fuera, una prueba permitida desde dentro y excepciones. Un cambio de prefijo, software, hardware, topología, función o clave vuelve obsoleta la prueba anterior.

El resultado no afirma que la red sea invulnerable. Afirma algo auditable: esta versión del dominio se comprobó en estos bordes, con estos rangos y equipos, en este momento, y estas limitaciones siguen abiertas.

The Policy Mirror obliga a localizar dónde se escribe la regla efectiva. Aquí está repartida entre membresía, direccionamiento, filtros, encapsulación y claves. Running-Code Primacy exige que esas piezas ejecuten juntas. Reality, Not Advocacy impide exagerar: el borrador no acusa a ninguna red ni resuelve el interdominio. Sí desmonta la idea de que un dueño común basta para producir confianza común.

Fuentes