Summary

  • El borrador de RADEXT propone estandarizar Protocol-Error, el código de paquete RADIUS 52 que la RFC 7930 introdujo de modo experimental. El registro IANA todavía remite a esa RFC.
  • La respuesta debe incluir Error-Cause y Original-Packet-Code. El segundo atributo permite relacionar el diagnóstico con la clase de petición pendiente cuando el mismo Identifier se utiliza en operaciones distintas.
  • Se trata de un error entre saltos vecinos. Con las causas 502 o 505, el proxy debería probar otra conexión o destino, sin volver a usar la conexión que dio el fallo.

El silencio ha sido durante años una respuesta demasiado cómoda en RADIUS. Un servidor puede no contestar porque está saturado, porque no entiende una petición o porque falló otro proxy en la cadena. Al dispositivo de acceso le llega la misma pantalla vacía en los tres casos. Activa su temporizador, prueba de nuevo y quizá cambia de servidor. Si miles de dispositivos hacen lo mismo sobre una ruta averiada, la política local de recuperación puede agravar el atasco.

El código 52 ofrece una frase distinta: recibí la petición, pero no pude procesarla. La revisión de noviembre enumera solicitudes de acceso, contabilidad, cambio de autorización y desconexión. Una contabilidad que no se pudo registrar merece un diagnóstico de procesamiento; una aceptación daría una constancia falsa. Un problema técnico durante la autenticación tampoco debería convertirse por comodidad en un juicio sobre la persona que intenta entrar. La RFC 7930 había definido el paquete como experimento en 2016. RADEXT ahora intenta escribir la conducta de clientes y servidores con más precisión.

El paquete lleva causa e identidad de la operación. Error-Cause indica el tipo de fallo. Original-Packet-Code conserva el código de la solicitud que lo provocó. El Identifier de RADIUS puede coincidir en solicitudes de clases diferentes, de modo que el número por sí solo puede señalar el expediente equivocado. La respuesta copia ese Identifier y el cliente debe descartar una respuesta cuyo código original no corresponda a ninguna petición pendiente. Es una regla contra un error administrativo muy técnico: tramitar la avería de contabilidad como si fuera un rechazo de acceso.

Una avería de ruta exige una decisión de ruta

El artículo 4 del borrador declara que Protocol-Error opera salto a salto. El proxy que lo recibe no debe limitarse a reenviar el paquete. Tiene que leer Error-Cause para separar los fallos de la red de proxies de los comunicados por el servidor de origen. El proxy controla la conexión descendente; el equipo de acceso conoce la solicitud que entregó al proxy. La autoridad para reparar cada tramo sigue esa división.

Dos causas están identificadas como fallos de la red de proxies: 502, Request Not Routable (Proxy), y 505, Other Proxy Processing Error. El proxy debería intentar otra conexión al mismo destino o dirigirse a otro. El texto prohíbe enviar el nuevo intento por la conexión recién fallida. Esa prohibición impide que un automatismo insistente se venda como tolerancia a fallos mientras produce tráfico inútil. El borrador deja fuera la estrategia completa de conmutación: cada operador tendrá que fijar límites de tiempo, rutas alternativas y presupuesto de intentos.

Las demás causas deberían leerse como procedentes del servidor de origen. En ese caso, el proxy envía a su propio cliente un nuevo Protocol-Error que conserva la causa. El mensaje hacia arriba tiene ahora un emisor concreto y un paso de interpretación. Una traza útil enlaza la petición inicial, el resultado descendente, la decisión del proxy y la respuesta final al dispositivo de acceso. Un diagnóstico de procesamiento no documenta por sí solo una autenticación aprobada ni un asiento contable guardado.

El proyecto conserva apartados TBD sobre migración, negociación y elección de respuestas. Tampoco publica una traza de despliegue que atraviese dos proxies. Una prueba controlada debería guardar el tipo e Identifier originales, la causa recibida, la conexión descartada, la ruta elegida y el resultado visto por el equipo de acceso. Así se sabrá qué parte de la promesa funciona fuera del texto.

Borrador RADEXT · Ficha Datatracker · RFC 7930 · Registro IANA