Resumen

  • La revisión 07 del Internet-Draft individual draft-howard-virp se presentó el 6 de septiembre de 2026 y está fechada el día 7. No es un estándar, un documento adoptado por un grupo de trabajo ni una posición avalada por el IETF.
  • El nuevo perfil External Authorization Binding limita la identidad permanente de la puerta a operaciones de observación y obliga a que un servicio fuera de su control autorice cada escritura.
  • VIRP propone cotejar la intención y el resultado declarados por la puerta con la decisión del servicio externo y la contabilidad generada por el dispositivo. Las discrepancias conservan estados propios en vez de convertirse automáticamente en éxito o rechazo.
  • El autor afirma que la política estática por orden y la conciliación con la contabilidad se implementaron y ejercitaron en Cisco IOS e IOS-XE. Esa afirmación no equivale a una reproducción independiente ni a adopción general.
  • La pieza decisiva sigue pendiente: los permisos ligados a una aprobación, con caducidad y consumo único, no están implementados; tampoco se encadenan todavía las decisiones externas de autorización.

La autoridad no puede residir en el mismo lugar que su filtro

El historial de Datatracker registra la carga y aceptación de la revisión 07 el 6 de septiembre. El texto fechado el día 7 añade un perfil pensado para responder a una pregunta operativa: si la puerta que recibe órdenes de un agente autónomo queda comprometida, ¿conserva también la credencial capaz de modificar la red?

External Authorization Binding responde que no debería conservarla. La identidad estable de la puerta permite observación. El propio dispositivo consulta un servicio de autorización distinto para cada orden que excede esa clase. Una credencial de escritura no puede estar guardada en la puerta de modo que resulte útil sin una decisión separada por acción y emitida por otro actor.

Esta diferencia es estructural. Un clasificador dentro de una puerta que también guarda el secreto privilegiado pierde su fuerza cuando esa puerta cae. Si el equipo aplica una decisión recibida de un servicio independiente, comprometer la puerta ya no basta para convertir su propia clasificación en autoridad. Las solicitudes de autorización y la contabilidad deben circular por una vía que la puerta no pueda suprimir o falsificar por sí sola.

Las piezas son conocidas. RFC 8907 define la autorización TACACS+ por orden y la contabilidad; las identidades administrativas de solo lectura son práctica habitual. La contribución que VIRP se atribuye es combinarlas alrededor de un solicitante automatizado y unir el relato de la puerta con evidencias que no nacen en ella.

La condición institucional sigue siendo limitada. La página de Datatracker identifica el texto como Internet-Draft individual, sin flujo RFC ni AD responsable. Advierte expresamente que cualquiera puede presentar un borrador, que este no cuenta con el respaldo del IETF y que no posee rango formal en su proceso. El encabezado no debe convertirse en mandato.

Cuatro registros que no comparten la misma custodia

El modelo distingue gate_intent/1, emitido antes de contactar al equipo, y gate_execution/1, emitido después para declarar qué ocurrió. Ambos están marcados como implementados. También lo está device_accounting/1, el evento que origina el dispositivo y que recibe un colector accesible con independencia de la puerta.

La cuarta pieza, authorization_decision/1, contiene el permiso o rechazo del servicio externo, la identidad, el objetivo, la orden canónica o su huella y el momento de la decisión. Su forma está especificada, pero el código de referencia no la emite aún como entrada de la cadena. El dato permanece en el registro local del servicio y puede adjuntarse como artefacto de otra procedencia.

Por eso existen dos rechazos diferentes. El clasificador de VIRP puede negarse antes de enviar una orden, generando un registro propio encadenado. El servicio externo puede rechazar una orden que sí salió de la puerta, pero su decisión conserva por ahora otra cadena de custodia. Mezclarlos borraría qué autoridad actuó.

La conciliación usa una clave formada por dispositivo, identidad del principal y huella exacta de la orden canónica, más una ventana temporal declarada. Sin reloj fiable, el resultado debe ser UNRESOLVED. Cuando las pruebas aptas coinciden, queda MATCHED; una ejecución afirmada solo por la puerta es GATE-ONLY; una acción contabilizada solo por el equipo es DEVICE-ONLY; y DENIED exige una decisión externa, no el simple silencio de la contabilidad.

El valor del esquema está en aceptar que la incertidumbre es un estado. Para gobernar cambios automáticos en producción, una coincidencia aproximada no puede heredar el significado de una coincidencia probada.

«Contabilizado» no significa siempre «ejecutado»

RFC 8907 explica que la contabilidad registra lo que un usuario hace o ha hecho. En administración de dispositivos, sin embargo, ordena emitir un inicio de contabilidad por cada orden introducida, con independencia de cómo se autorizó. Algunos equipos pueden registrar la entrada antes de saber si la orden fue aceptada o ejecutada.

La revisión exige que cada despliegue declare la semántica por familia de dispositivos: orden introducida, autorizada, ejecutada o evento de significado desconocido. Solo una fuente cuyo significado esté probado como ejecución puede sostener un veredicto de ejecución.

El texto relata un resultado más estrecho en pruebas sobre Cisco IOS e IOS-XE: allí el evento observado correspondía a una orden ejecutada y un rechazo no producía contabilidad. También prohíbe generalizar ese comportamiento. El repositorio VIRP es una fuente primaria del propio autor; permite estudiar su implementación declarada, no certificarla de forma independiente.

La ruta AAA forma parte de la independencia. La revisión remite a RFC 9887 para proteger TACACS+ con TLS 1.3 cuando ambos extremos lo admitan. Separar cajas no sirve si la puerta puede interceptar o modificar el canal que transporta la autorización y el registro contable.

El permiso fugaz está bien definido, pero no existe aún

La especificación futura es concreta. Un emisor distinto de la puerta comprobaría la firma Ed25519 de un aprobador inscrito y su vínculo con una orden exacta, un dispositivo y una caducidad. Para una sola ejecución habría un identificador único. El emisor tendría que guardar de forma duradera el consumo antes de liberar la autoridad y rechazar usos posteriores. Una fecha de expiración no impide que una aprobación se reproduzca varias veces dentro de la misma ventana.

También hay que unir la orden aprobada con la invocación real. Si un controlador transforma la forma canónica, debe demostrar la correspondencia con los bytes enviados al equipo. Una regla textual debe quedar anclada en ambos extremos para evitar que una orden más larga o compuesta coincida por prefijo. La caducidad efectiva incluye la latencia con la que el servicio aplica la revocación; un mensaje de recarga correcta no demuestra por sí mismo que el permiso ya desapareció.

VIRP 07 dice con claridad que este camino no está implementado. El estado descrito hoy es una política estática con identidad de lectura, identidad de operador y denegación del resto. Esa separación reduce riesgo, pero no crea todavía una capacidad efímera derivada de una aprobación concreta.

La firma Ed25519 añadida a las entradas y cabeceras de cadena tampoco debe inflarse. Es opcional, está desactivada por defecto y acompaña al HMAC obligatorio. Facilita una verificación pública adicional donde se activa, sin probar que la observación refleja la verdad del dispositivo.

Un recibo de custodia para cada escritura

La evaluación operativa necesita un recibo que identifique la identidad estable de solo lectura, el servicio de autorización independiente, la huella de la orden y del objetivo, la aprobación, el permiso único, su consumo y la caducidad efectiva. Debe mostrar qué invocación recibió finalmente el dispositivo.

Después debe unir intención de la puerta, ejecución declarada, decisión externa y contabilidad. La ventana temporal, la salud de los relojes y la semántica contable del equipo acompañan cualquier clasificación. UNRESOLVED no es un fallo de presentación, sino una protección contra conclusiones inventadas.

Este recibo es una propuesta de Daniel Kade, no una obligación de VIRP, RFC 8907, RFC 9887 ni del IETF. Sirve para impedir que una sola interfaz tome prestada la autoridad del servidor y el valor probatorio del equipo.

Fuentes