Resumen

  • draft-ietf-ippm-ioam-data-integrity-20 define una cadena AES-GMAC que un Validador de confianza reconstruye para detectar alteraciones en los campos inmutables incluidos.
  • El resultado válido no demuestra que llegaron todas las opciones previstas, que un nodo dijo la verdad sobre sí mismo, que la exportación conservó los datos, que no hubo demora o que todo el tráfico estuvo cubierto.
  • La automatización necesita un recibo con conjunto esperado y observado, estado antirrepetición, procedencia del Validador, custodia de exportación, cobertura y verificación independiente del servicio.

El cálculo termina con una igualdad. El ICV reconstruido coincide con el recibido. El algoritmo ha cumplido su función; el error empieza cuando la interfaz traduce esa igualdad por «trayecto verificado».

La revisión 20, fechada el 19 de julio de 2026, es un Internet-Draft del grupo IPPM que se encuentra en la cola del RFC Editor. Aún espera al primer editor y la ficha de IANA señala que la versión modificada requiere revisión. No es una prueba de despliegue, interoperabilidad ni operación correcta.

El método crea variantes protegidas de las opciones de traza preasignada e incremental, Proof of Transit y extremo a extremo. Cada participante que actualiza la cadena tiene una clave. El nonce reúne ID de clave, ID del nodo encapsulador y contador. Los nodos incorporan sus campos inmutables al ICV anterior; el Validador reproduce la secuencia con las claves asociadas a los identificadores presentes.

La relación entre identificadores y claves queda fuera del documento. Ese registro local decide a quién atribuye el Validador cada contribución. La criptografía no crea la identidad administrativa sobre la que opera.

Autenticidad de origen no equivale a verdad de medición

Un nodo comprometido puede falsificar o descartar paquetes. No puede hacerse pasar por otro nodo ni modificar silenciosamente la contribución protegida de otro, si la configuración es correcta. Sin embargo, puede afirmar bajo su propia clave que su cola medía un valor inventado.

El ICV prueba que la declaración atribuida no cambió. No prueba que el sensor, el software o el operador fueran honestos. Para evaluar credibilidad hacen falta procedencia del binario, configuración, calibración, contadores independientes y coherencia con otros observadores.

Esta separación evita que «firmado por el nodo» se convierta en «cierto en el mundo». La primera es una propiedad de la evidencia; la segunda, una conclusión que necesita más evidencia.

El Validador concentra autoridad

El borrador define al Validador como entidad de confianza con acceso a las claves y autoridad final sobre el resultado. También admite que un Validador comprometido puede modificar los campos o emitir un resultado incorrecto, y que el mecanismo no puede impedirlo.

Por eso el Validador debe aparecer en el recibo. Identidad de despliegue, versión de software, hash de configuración, época de claves, mapa ID-clave y política de decisión son parte del resultado. Sin ellos, no existe una verificación reproducible: solo la palabra del mismo guardián.

Cuando el Validador también elige la cobertura y activa una corrección automática, se borran tres funciones distintas. Una acción de alto impacto exige otro plano de observación o una autoridad separada.

El ICV no puede proteger lo que fue retirado

Un atacante puede eliminar el encabezado completo de una opción IOAM. El método no mitiga esa supresión; la protección debe proporcionarla el protocolo encapsulador. También es posible cambiar una opción protegida por su equivalente sin protección si el Validador desconoce qué espacios de nombres y opciones deberían estar presentes.

La validación debe comenzar con un inventario esperado: Namespace-ID, tipo de opción, encapsulador y conjunto de participantes. Después se compara con lo observado. Solo entonces tiene sentido comprobar la cadena.

Una opción ausente no es válida. Tampoco es inválida. Puede no haberse insertado, haber quedado fuera de la muestra, haber sido retirada o haberse perdido durante la exportación. Un sistema serio conserva esos estados en vez de convertir el silencio en éxito.

La cobertura es un denominador independiente

Las opciones protegidas y ordinarias pueden coexistir. Un espacio de nombres puede estar protegido y otro no. Para evitar sobrecarga, el operador puede aplicar el mecanismo a una fracción del tráfico.

Contar resultados válidos no revela qué fracción de los paquetes elegibles recibió protección. La cobertura debe indicar flujos, clases, espacios de nombres, intervalos y cambios de política. Una muestra válida no hereda autoridad sobre la población que no fue observada.

Los campos mutables tampoco entran en la integridad. El recibo tiene que listar campos y máscaras protegidos. «IOAM íntegro» es una frase demasiado amplia para una protección selectiva.

El perímetro termina antes de la analítica

El plano de gestión y la integridad de los datos exportados quedan fuera del alcance. Se espera que otros protocolos los protejan. Direct Export no lleva IOAM-Data-Fields y no puede usar este método.

Entre la validación en el paquete y el gráfico final hay decapsulación, serialización, transporte, almacenamiento y agregación. Cada paso puede alterar el significado. Deben conservarse los bytes originales, el recibo y los hashes de transformación. Si la custodia se rompe, el resultado posterior es integridad de exportación no demostrada.

Un paquete auténtico puede ser inoportuno

El borrador tampoco mitiga la demora selectiva. Un atacante puede retrasar precisamente los paquetes con IOAM y crear una ilusión de congestión. El ICV sigue siendo correcto porque el contenido no cambió.

La frescura necesita hora de captura, hora de validación, presupuesto de edad, calidad del reloj y corroboración de demora y pérdida. La protección antirrepetición impide reutilizar un nonce, pero no convierte un paquete único en oportuno.

Tras un reinicio sin estado persistido, la clave anterior no puede reutilizarse; debe rotarse. La ventana antirrepetición determina cuánto reordenamiento legítimo se tolera. Estos son estados operativos concretos, no detalles invisibles detrás de la palabra válido.

Un recibo para decisiones, no para iconos

Registrar dominio, Namespace-ID, opción, método, máscara, paquete, selección, participantes y opciones esperados/observados. Añadir nonce, identificadores públicos, época de clave, versión del mapa, decisión antirrepetición y procedencia del Validador. Encadenar la exportación y el almacenamiento mediante hashes.

Finalmente, adjuntar demora, pérdida, corroboración de ruta, estado de servicio, decisión ejecutada, autoridad, reversión y resultado. Usar estados delimitados: válido para conjunto declarado, opción esperada ausente, identidad desconocida, Validador no verificado, cobertura parcial, exportación no probada y resultado pendiente.