Resumen

  • RFC 3539 exige que agentes y servidores AAA acepten la posibilidad de duplicados en cualquier conexión. El reenvío por una ruta alternativa puede llegar antes que la solicitud original, sin demostrar que ésta haya desaparecido.
  • Cuando la autenticación depende de estado previo, el primer procesamiento puede dar Accept y el duplicado Reject. La identidad de extremo a extremo permite reconocer una sola intención, pero hacen falta reglas separadas para reutilizar la decisión, elegir una respuesta, aplicarla en el NAS y demostrar el resultado.

La alta disponibilidad promete que una avería no detendrá el servicio. El precio técnico suele aparecer en otra parte: el trabajo que parecía trasladarse en realidad se copia. Mientras el cliente decide que un peer ya no sirve, el mensaje anterior puede seguir en una cola, un proxy, un socket o un servidor remoto.

RFC 3539, Authentication, Authorization and Accounting (AAA) Transport Profile, fue publicada en junio de 2003 como Proposed Standard. Su valor para una revisión directiva no está en una receta de producto, sino en una advertencia precisa: la recuperación de transporte puede abrir un segundo lugar donde se decide la misma transacción.

El documento no prueba que un operador concreto haya sufrido respuestas opuestas. Delimita qué evidencia falta cuando un informe afirma que el failover “funcionó”.

Una ruta nueva no clausura la anterior

Un cliente AAA puede mantener enlaces con varios agentes o servidores y tratarlos como primario y secundario o utilizarlos para balanceo. Si cambia de ruta antes de que expire el tiempo necesario para garantizar que los paquetes antiguos salieron de la red, la copia alternativa puede adelantarse al original.

Por eso RFC 3539 exige prepararse para duplicados y asumir que aparecerán por cualquier conexión. La conexión describe un tramo. La transacción describe la intención. Romper el tramo no cancela automáticamente la intención que ya lo atravesó.

Esta separación impide usar tres atajos. “La conexión se cerró” no prueba que el servidor no procesó. “La secundaria contestó” no prueba que la primaria no contestará después. “Las respuestas llegaron por sockets distintos” no prueba que correspondan a solicitudes de negocio diferentes.

El expediente debe conservar la identidad lógica, el resumen criptográfico del contenido, la conexión inicial, el destino alternativo y los tiempos de ambos envíos. Sin ese conjunto, un gráfico de disponibilidad sólo muestra movimiento de tráfico; no muestra cuántas veces se permitió decidir.

El watchdog tiene una jurisdicción deliberadamente estrecha

La vigilancia de RFC 3539 opera en la capa de aplicación y sirve para descubrir antes fallos del transporte o de la función del peer. No vigila todo el servicio de identidad. Está diseñada para el vecino inmediato y debe permanecer aislada de problemas en proxies o servidores posteriores. Tampoco es un heartbeat de clúster.

Cualquier respuesta AAA procedente del peer cuenta como señal de vida. La falta de respuesta a una solicitud normal no basta para declararlo caído: quizá el peer esté esperando a un servidor posterior. El algoritmo espera el fallo de la sonda específica antes de iniciar la transición correspondiente.

Esta regla protege contra oscilaciones masivas, pero reduce el significado de un indicador verde. Prueba que una aplicación vecina pudo responder. No prueba que el dominio de origen responda, que dos réplicas compartan estado, que el usuario esté autorizado ni que el NAS permita tráfico.

La temporización muestra el intercambio de riesgos. El perfil ofrece treinta segundos como valor inicial sin jitter y admite bajar hasta seis segundos, sin incluir el jitter. También advierte que un intervalo corto aumenta la probabilidad de duplicados y de failover o failback espurios. Recuperarse antes de una caída auténtica implica tolerar menos demora antes de copiar trabajo que aún puede estar vivo.

No existe un ajuste que elimine ambos riesgos. La organización debe elegir, medir y registrar el intercambio.

La cola pendiente es una vista local, no un oráculo remoto

El cliente o agente mantiene una cola de solicitudes pendientes por peer. Cuando llega una respuesta correlacionada, retira la entrada. Cuando comienza el failover, envía las entradas restantes a un agente alternativo si está disponible.

“Pendiente” significa que este nodo aún no vio la respuesta que cierra su registro. No significa que nadie haya ejecutado la operación. Una solicitud puede haber llegado al servidor; su respuesta puede estar retrasada. Puede haber creado estado en un sistema que la cola local no observa.

El recibo de repetición necesita, por tanto, más detalle que retry=true: snapshot exacto de la cola, peer sospechoso, peer alternativo, causa, intervalo del watchdog, identidad y hash de la solicitud, marca de retransmisión y relojes. Debe quedar claro si se enviaron los mismos bytes o si un componente reconstruyó el mensaje.

RFC 6733 conserva esta arquitectura para Diameter. Reenvía las solicitudes pendientes con la marca de retransmisión, avisa que puede haber varias solicitudes o respuestas idénticas y utiliza End-to-End Identifier junto con Origin-Host para detectar duplicados. Hop-by-Hop Identifier sirve para emparejar solicitud y respuesta en el tramo adyacente.

Un identificador local retira una entrada local. Una identidad de extremo a extremo reúne copias vistas a través de distintos agentes. Ninguna de las dos es una garantía de ejecución única.

Detectar el duplicado sólo abre la decisión difícil

Cuando un servidor reconoce que ya vio la identidad, aún debe decidir qué hacer. Puede recuperar una respuesta durable, esperar al dueño de esa respuesta, repetir el resultado ya comprometido, rechazar la repetición o volver a evaluar.

RFC 6733 orienta a que una solicitud duplicada provoque la misma respuesta, salvo los detalles hop-by-hop. Es una barrera contra la segunda evaluación. Sin embargo, la regla necesita memoria durable y una clave que siga viva durante toda la ventana de repetición. Si la primera decisión no se registró, expiró o está aislada en otra réplica, la clave común no crea el dato ausente.

Tampoco revierte un efecto. Si el NAS ya abrió acceso, reconocer después el duplicado no cierra automáticamente la sesión. Si un cargo se comprometió, la clasificación no lo compensa. Identificación, supresión, reconciliación y compensación son verbos distintos.

Un registro completo anota el servidor, su versión de estado, la restricción evaluada, la búsqueda en la tabla de duplicados, la decisión anterior encontrada o no encontrada, el resultado emitido y el punto de commit.

La carrera Accept/Reject convierte latencia en política

El ejemplo central de RFC 3539 utiliza una restricción de uso simultáneo. Una primera autenticación llega cuando el usuario no está marcado como conectado y obtiene Accept. La copia llega a otro servidor cuando el estado ya indica una sesión, y obtiene Reject. El cliente puede recibir ambas respuestas; el resultado dependerá de cuál llegue primero.

No hace falta atribuir mala fe. Cada servidor puede haber observado una instantánea válida y haber aplicado correctamente su regla. El defecto de control aparece porque una sola intención produjo dos evaluaciones no idempotentes.

Si el cliente conserva únicamente la respuesta aplicada, desaparece la evidencia de la carrera. Un analista verá una autorización normal o un rechazo normal, no una topología que permitió los dos. Deben guardarse ambas respuestas, sus servidores, estados, horarios y correlación.

Además, “primera” debe definirse. Puede ser la primera recibida por el proceso, la primera validada, la primera comprometida, la primera entregada al NAS o la primera aplicada. Esas fronteras pueden ordenar los eventos de manera diferente.

Cuando la llegada decide sin una norma explícita, cambiar la ubicación del secundario o la latencia del proxy modifica en la práctica la autorización. Una intervención de resiliencia se convierte en cambio de política sin revisión de política.

La respuesta elegida todavía debe convertirse en servicio

Accept no es acceso. El cliente debe correlacionarlo y validarlo. El NAS debe instalar los atributos o el perfil correspondientes. La sesión debe comenzar y el plano de datos debe funcionar. Reject tampoco demuestra denegación total si otro Accept ya fue aplicado.

La contabilidad añade otra superficie. RFC 3539 menciona Session-Id, Event-Timestamp e identidad del NAS para distinguir registros repetidos. El sistema debe conservar qué copia se descartó, fusionó o aceptó, y cómo esa decisión alcanzó facturación y auditoría.

Así se forma una cadena: creación de intención, liveness del peer inmediato, copia de failover, decisiones de todos los servidores, selección del cliente, aplicación del NAS, estado contable y experiencia observada. Cada dueño firma sólo su tramo.

El responsable de red no puede afirmar que la política fue coherente sólo porque la secundaria respondió. El responsable de identidad no puede afirmar que el usuario obtuvo servicio sólo porque emitió Accept. El responsable del NAS no puede ocultar una respuesta contradictoria porque la configuración final parezca correcta.

No confundir esta frontera con la identidad clásica de RADIUS

RADIUS tiene coordenadas propias: Identifier, Request Authenticator, contexto de transporte y secreto compartido intervienen en el emparejamiento y la retransmisión. Las RFC 2865, 2866 y 5080 delimitan ese mundo.

No son nombres antiguos para End-to-End Identifier, Origin-Host o Hop-by-Hop Identifier. La cuestión de RFC 3539 es el duplicado que cruza conexiones y agentes y llega a decisiones dependientes del estado. Mantener separados los modelos evita fabricar compatibilidades históricas y permite exigir la evidencia adecuada a cada protocolo.

La regla común es más abstracta: conservar identidad suficiente para que una copia siga siendo la misma intención y conservar decisión suficiente para que esa intención no obtenga dos efectos.

Cómo auditar el failover sin convertirlo en leyenda

Primero, fijar la solicitud: origen, identidad de extremo a extremo, contenido, usuario o sesión, aplicación y momento. Segundo, fijar el peer: conexión, última respuesta válida, ciclo de watchdog, temporizador, jitter y motivo exacto de la sospecha.

Tercero, congelar el snapshot de la cola antes de repetir y registrar cada destino alternativo. Cuarto, recoger la decisión de cada servidor con su estado, búsqueda de duplicado y commit. Quinto, guardar todas las respuestas en el cliente y la regla de elección.

Sexto, confirmar la acción del NAS. Séptimo, reconciliar Session-Id, Event-Timestamp e identidad del NAS en contabilidad. Octavo, observar acceso o denegación.

El informe puede afirmar entonces algo limitado: «el peer inmediato falló a esta sonda; estas identidades pendientes se reenviaron; estos servidores respondieron; esta regla resolvió la contradicción; el NAS aplicó este resultado; la sesión observada fue ésta». La ausencia de una pieza debe quedar declarada.

Límite de la evidencia

Este Artículo no identifica operador, proveedor, dominio AAA, despliegue RADIUS o Diameter, cuenta, inicio de sesión, NAS, incidente, caída, ataque, cobro duplicado ni usuario. No declara una tasa de adopción, una configuración vigente ni una frecuencia medida de respuestas opuestas.

RFC 3539 se trata como Proposed Standard de junio de 2003. RFC 3588 es contexto histórico y fue sustituida por RFC 6733. Esta última mantiene el algoritmo de fallo y la identidad de duplicados, pero no demuestra implementación en un sistema nombrado. RFC 8174 limita la lectura normativa y RFC 6298 aporta contexto de retransmisión, no evidencia AAA.

Los ensayos de Lu Heng sobre primacía del código operativo y especificación inicial mínima son lentes editoriales declaradas. Ayudan a separar texto, implementación, decisión local y resultado. No demuestran la intención de los autores de RFC 3539 ni un hecho operativo.

La conclusión acotada es que el failover puede copiar una solicitud AAA antes de que el original desaparezca. La identidad muestra que son una sola intención; sólo una disposición idempotente, una selección gobernada, una ejecución verificada y un resultado observado pueden demostrar un solo efecto.

Fuentes