Resumen

  • RFC 5191 permite que, tras una autenticación y autorización correctas, el PaC tenga que reconfigurar su dirección IP antes de disponer de una dirección válida para enviar datos a través del Enforcement Point.
  • La dirección usada en el control, la decisión de autorización, la proyección al EP, la asociación de protección y el tráfico observado son pruebas distintas. Sustituirlas por una sola marca «conectado» borra el punto exacto de fallo.

El incidente comenzó con una pregunta equivocada: ¿cómo podía estar desconectado un cliente que acababa de autenticarse? La respuesta estaba en el propio protocolo. El cliente había demostrado una identidad y obtenido autorización. Todavía no había demostrado que su configuración de red posterior fuese utilizable.

PANA transporta EAP sobre IP entre el PANA Client y el PANA Authentication Agent. El PAA comunica el resultado de autenticación y autorización, y la sesión pasa a la fase de acceso cuando ambas terminan con éxito. Pero RFC 5191 contempla un paso adicional: la dirección usada durante PANA puede no servir para el tráfico de datos. El PAA puede activar el bit IP Reconfiguration y exigir una nueva configuración.

El método concreto de reconfiguración está fuera del RFC. Esa frontera impide que el último mensaje PANA sea también un recibo de DHCP, vecindad, ruta, filtro y entrega. Cada uno vive en otro mecanismo y tiene su propia autoridad.

La dirección del control no es necesariamente la dirección del servicio

Durante el arranque, el PaC necesita conectividad suficiente para localizar o alcanzar al PAA y ejecutar PANA. Esa conectividad previa puede permitir PANA y otros tipos de tráfico excepcionados por el EP, sin ser todavía la conectividad autorizada para el servicio ordinario.

Cuando la fase final indica reconfiguración, el registro debe conservar la dirección anterior. No conviene sobrescribirla con la nueva porque la dirección anterior explica qué mensajes pertenecían al intercambio de control y por qué una captura posterior no los encuentra bajo el nuevo tuple.

La cronología mínima incluye interfaz, dirección y puerto del PaC usados en PANA, PAA alcanzado, resultado de autorización, bit de reconfiguración, mecanismo que entregó la nueva dirección, vigencia del lease, resolución de vecino, ruta instalada, actualización de la política del EP y primer paquete permitido.

Un sistema que sólo guarda «IP actual» convierte una transición legítima en una aparente contradicción. También puede asociar los contadores del EP con el identificador equivocado y atribuir el tráfico de un lease posterior a una sesión anterior.

EAP Success no decide el acceso

La separación no empieza en el direccionamiento. RFC 5191 describe expresamente el caso en que EAP produce Success y, aun así, la autorización de acceso es rechazada por AAA o por el PAA. El último PANA-Auth lleva PANA_AUTHORIZATION_REJECTED y la sesión se termina.

La identidad y el permiso responden preguntas diferentes. Una credencial válida puede identificar a un principal que no tiene derecho al servicio solicitado, cuyo periodo de autorización terminó o cuya política impide el acceso en esa interfaz. El MSK puede existir y proteger el intercambio final sin cambiar ese resultado.

Por eso el evento EAP debe guardar método, peer, resultado y material exportado, mientras que el evento de autorización guarda decisión, fuente, servicio, duración y razón. Mezclarlos hace que una investigación de política termine innecesariamente en el sistema de credenciales.

Una marca de éxito sin nombre del emisor no es una prueba operacional. Es una palabra que ha perdido su alcance.

Complete cierra PANA, no todas las dependencias

El intercambio final marcado Complete establece la conclusión del protocolo entre PaC y PAA. Si la autorización es positiva, transporta una duración de sesión. Con una EAP que genere claves, el Key-Id y AUTH protegen la señalización.

El PAA, sin embargo, puede estar separado del Enforcement Point. El EP es quien aplica filtros por paquete. RFC 5191 declara fuera de su alcance el protocolo PAA–EP y la creación de filtros. También exige que la comunicación de provisión entre ambos esté protegida contra falsificación, modificación y replay.

Esa exigencia define una obligación de seguridad, no una confirmación de instalación. Para probar el efecto se necesita la lista de EP objetivo, una versión de política, el vínculo con PaC e interfaz, acuse de cada nodo y una lectura del filtro instalado. Si algunos nodos no responden, la situación es parcial aunque PANA haya finalizado sin error.

El panel debe mostrar esa parcialidad. «Autorización positiva; política instalada en dos de tres EP; dirección nueva aún sin vecino» permite actuar. «Online» no.

La asociación PANA protege otra cosa

La PANA Security Association nace cuando EAP produce un MSK. Su clave protege mensajes PANA mediante AUTH: cabecera, contenido y EAP transportado. Eso autentica la conversación de control entre PaC y PAA y limita inyección, cambio y replay.

El tráfico de usuario no queda automáticamente cifrado por esa SA. RFC 5191 trata aparte la protección por paquete. Puede derivarse material para una asociación segura de capa de enlace o IPsec, pero su creación y uso están fuera del documento.

Una auditoría debe preguntar por dos objetos. Para PANA SA: Session ID, Key-Id, lifetime, verificación AUTH y mensajes cubiertos. Para la SA de datos: endpoints, selectores, algoritmo, instalación, counters, replay window y expiración. La relación de derivación no vuelve idénticos a ambos objetos.

Si la política no exige cifrado adicional porque la capa inferior ya protege el tráfico, el registro debe decirlo. La ausencia de una SA secundaria sin una decisión explícita no demuestra ni seguridad ni incumplimiento.

Descubrir un PAA no lo autentica

RFC 5192 define opciones DHCP para aprender direcciones de PAA. RFC 6345 añade un elemento relay. Estas piezas responden dónde enviar el protocolo. No convierten una dirección descubierta en autoridad confiable antes del intercambio de autenticación.

Conviene guardar servidor DHCP, opción recibida, lease, interfaz y relay, y después enlazar esa procedencia con la sesión PANA validada. Un PAA mal descubierto, un relay inaccesible, un rechazo de autenticación y una regla EP ausente pueden producir la misma pantalla de usuario, pero exigen propietarios y remedios diferentes.

El descubrimiento crea un candidato. La autenticación crea evidencia sobre el peer. La autorización concede o niega un servicio. El EP ejecuta. La entrega se observa después.

Liveness no es paso de datos

En la fase de acceso, PANA permite mensajes Notification con bit Ping para comprobar que el peer sigue vivo. Una respuesta válida y reciente demuestra la vida del peer PANA. No consulta el filtro de un EP separado ni ejecuta una transacción de aplicación.

Puede haber ping PANA mientras la dirección autorizada perdió la ruta, la asociación de datos expiró o el EP conserva una versión antigua. También puede fallar un keepalive por congestión mientras el plano de datos aún transporta tráfico. El RFC advierte sobre falsas alarmas cuando la prueba se usa periódicamente sin cuidado.

Toda métrica de liveness debe nombrar su target. «PAA vivo» no se transforma en «servicio de cliente sano» por aparecer en el mismo dashboard.

Lifetime tampoco es disponibilidad

La duración de una sesión PANA está acotada por la duración de la autorización. El PaC puede iniciar una nueva EAP antes del vencimiento para extenderla. La PANA SA sigue el ciclo de la sesión.

Ese reloj controla permiso y estado. No garantiza que el lease IP, el filtro EP, la ruta, el cifrado de datos o la aplicación permanezcan disponibles durante el mismo intervalo. Copiarlo en un compromiso de uptime convierte una política temporal en una medición que nunca se realizó.

Los operadores necesitan relojes separados: autorización, sesión PANA, claves de control, dirección, regla EP, SA de datos y observación del servicio. Una diferencia entre ellos no es ruido. Es la pista que localiza el fallo.

Terminar exige comprobar la retirada

PaC o PAA puede terminar la sesión. La operación pretende eliminar el estado PANA, cerrar accounting y retirar del EP el estado por cliente. Si PAA y EP están separados, la terminación protegida sigue siendo una orden que debe propagarse.

Un allow residual crea exposición; un deny residual impide la siguiente conexión. El recibo debe incluir causa, mensaje autenticado, cierre contable, EP objetivo, acuses de eliminación y lectura posterior de reglas. Borrar el objeto PAA antes de conservar esos vínculos destruye la explicación del residuo.

La misma disciplina debe aplicarse a expiración y fallo de liveness. El motivo de cierre y el efecto sobre enforcement son hechos diferentes.

El recibo completo

Un registro útil sigue el orden de autoridad. Primero identifica PaC, interfaz, fuente de descubrimiento y servicio solicitado. Después conserva mensajes PANA, secuencias, retransmisiones y validación. Adjunta el resultado EAP sin reemplazar la autorización.

Al final de PANA guarda Result-Code, Complete, Key-Id, AUTH y lifetime. Si hay reconfiguración, conserva ambas direcciones y todos los pasos intermedios. Luego registra la provisión hacia cada EP y los filtros leídos. Si se requiere protección por paquete, enlaza su asociación independiente. Finalmente añade captura, receipt remoto y resultado de aplicación.

Esta cadena no degrada un éxito PANA. Lo sitúa en el lugar donde es verdadero. Sólo así un sistema puede distinguir una identidad válida, una política denegada, una dirección todavía inútil, un EP desincronizado y un servicio realmente accesible.

Fuentes

  1. RFC 5191 HTML
  2. RFC 5191 texto
  3. Ficha RFC 5191
  4. Datatracker RFC 5191
  5. Historia RFC 5191
  6. Referencias RFC 5191
  7. Errata RFC 5191
  8. RFC 5192
  9. Ficha RFC 5192
  10. RFC 5193
  11. Ficha RFC 5193
  12. RFC 4058
  13. RFC 4016
  14. RFC 3748
  15. RFC 4137
  16. RFC 5247
  17. RFC 6345
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy