Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

Especificaciones Radius de Infovia

Última Actualización: 3 de Noviembre de 1.998 - Martes

Infovía autentifica a los usuarios utilizando un esquema RADIUS. Lamentablemente la versión RADIUS de Telefónica no es compatible con las especificaciones originales. Ello, aunque, molesto, tiene sentido a la luz de la propia problemática que tiene Infovía.

Los fuentes del RADIUS de Telefónica no son públicos así que quedan dos opciones:

  1. Desensamblar el código objeto. El problema es que el nuevo código penal Español permite esa operación sólo si el objetivo es lograr la interoperatividad con otro módulo propio y si el resultado final de las investigaciones no se hace público.

  2. Estudiar el tráfico entre los CSIV (Centros de Servicio InfoVia) y un RADIUS en funcionamiento. Éste ha sido el camino elegido.


Entorno de trabajo

Para el desarrollo de este texto se ha utilizado el siguiente material:

  • RFC 2138
    Remote Authentication Dial In User Service (RADIUS)
    C. Rigney, A. Rubens, W. Simpson, S. Willens
    Abril 1997

  • RFC 2139
    RADIUS Accounting
    C. Rigney
    Abril 1997

  • Trazas UDP obtenidas con un "sniffer".

  • Bloqueos selectivos de determinados CSIVs, de forma local por supuesto, utilizando un cortafuegos.

  • Un modem y el "acceso telefónico a redes".


Accounting RADIUS

Esta función es la que permite identificar los usuarios conectados y sus características. Se envía un paquete cuando el usuario conecta y se envía otro cuando su conexión se cierra.

El funcionamiento de la versión Infovía es el definido en el RFC. Se utiliza, eso sí, el tipo "proxy", así como las extensiones ASCEND al RADIUS original. Los datos enviados por infovía son:

Start

User-Name
NAS-Identifier
NAS-Port
NAS-Port-Type
Acct-Status-Type
Acct-Delay-Time
Acct-Session-Id
Acct-Authentic: RADIUS
Caller-Id
Client-Port-DNIS
Framed-Protocol
Framed-Address
Proxy-State

 

[1]


[2]


[1]

[3]
[4]

 

Stop

User-Name
NAS-Identifier
NAS-Port
NAS-Port-Type
Acct-Status-Type
Acct-Delay-Time
Acct-Session-Id
Acct-Authentic: RADIUS
Acct-Session-Time
Acct-Input-Octets
Acct-Output-Octets
Acct-Input-Packets
Acct-Output-Packets
Ascend-Disconnect-Cause
Ascend-Connect-Progress
Ascend-Data-Rate
Ascend-PreSession-Time
Ascend-Pre-Input-Octets
Ascend-Pre-Output-Octets
Ascend-Pre-Input-Packets
Ascend-Pre-Output-Packets
Ascend-First-Dest
Caller-Id
Client-Port-DNIS
Framed-Protocol
Framed-Address
Proxy-State

 

[1]


[2]


[1]















[3]
[4]


  1. Cadena terminada en '\0'.
  2. Este valor no se lista en el fichero de detalle,
    e indica si la llamada es RTC o RDSI.
  3. Mide nueve bytes, y contiene el número del
    llamante, completado con '\0' hasta el final.
  4. El número que recibe la llamada,
    sin ningún '\0' final.

En "Proxy-State" los CSIVs transmiten la siguiente secuencia, en 38 bytes: "V1 V2 00 04 00 00 00 00 ID ID ID ID NI NI NI NI CI CI CI CI 04 02 CK CK CK CK CK CK CK CK CK CK CK CK CK CK CK CK"

  • V1, V2
    Versión del CSIV (Centro de Servicio Infovía). Actualmente (17/Ago/98) los servidores de Infovía tienen un número de versión de "02 00".

  • ID
    Identificador de la sesión. Cada sesión son 4 bytes (en formato Hi/Lo), con el mismo valor de "Acct-Session-Id", aunque éste último se represente en ASCII.

  • NI
    NAS Identifier: Identifica el dispositivo al que se está refiriendo. Los NAS (Network Access Server) son los servidores a los que se conectan los usuarios. Este campo tiene el mismo valor que el "NAS-Identifier".

  • CK
    Estos valores parecen aleatorios, y dado que miden 16 bytes es muy posible que se trate de un MAC (Message Autentication Code).

El servidor RADIUS devuelve exactamente la misma secuencia "Proxy-State", pero cambiando el "V1 V2" inicial por su versión de software local.


Autentificación RADIUS

Esta función es la que permite verificar las conexiones de los usuarios, así como configurar cosas como su tiempo máximo de inactividad, su tiempo máximo de conexión, etc.

Los datos intercambiados entre Infovía y nuestro servidor RADIUS son:

CSIV -> RADIUS

 

RADIUS -> CSIV

User-Name
User-Password
NAS-Identifier
NAS-Port
NAS-Port-Type
Service-Type: Framed
Framed-Protocol: PPP
State
Caller-Id
Client-Port-DNIS
Acct-Session-Id
Proxy-State
[1]



[2]


[5]
[3]
[4]
[1]
  Service-Type: Framed
Framed-Protocol
Framed-IP-Address
Framed-IP-Netmask
Ascend-Metric
Framed-Routing
Framed-Compression
Ascend-Idle-Limit
Ascend-Maximum-Time
User-Name
Proxy-State









[6]

  1. Cadena terminada en '\0'.
  2. Este valor no se lista en el fichero de detalle,
    e indica si la llamada es RTC o RDSI.
  3. Mide nueve bytes, y contiene el número del
    llamante, completado con '\0' hasta el final.
  4. El número que recibe la llamada,
    sin ningún '\0' final.
  5. No contiene ningún valor. Lo cual, en principio,
    viola las normas del protocolo RADIUS.
  6. Cadena sin el '\0' final.

En "Proxy-State" los CSIVs transmiten la siguiente secuencia, en 38 bytes: "V1 V2 00 04 00 00 00 00 ID ID ID ID NI NI NI NI CI CI CI CI 04 01 CK CK CK CK CK CK CK CK CK CK CK CK CK CK CK CK"

  • V1, V2
    Versión del CSIV (Centro de Servicio Infovía). Actualmente (17/Ago/98) los servidores de Infovía tienen un número de versión de "02 00".

  • ID
    Identificador de la sesión. Cada sesión son 4 bytes (en formato Hi/Lo), con el mismo valor de "Acct-Session-Id", aunque éste último se represente en ASCII.

  • NI
    NAS Identifier: Identifica el dispositivo al que se está refiriendo. Los NAS (Network Access Server) son los servidores a los que se conectan los usuarios. Este campo tiene el mismo valor que el "NAS-Identifier".

  • CK
    Estos valores parecen aleatorios, y dado que miden 16 bytes es muy posible que se trate de un MAC (Message Autentication Code).

El servidor RADIUS devuelve exactamente la misma secuencia "Proxy-State", pero cambiando el "V1 V2" inicial por su versión de software local.

La verificación de usuarios se realiza exactamente igual a las normas RADIUS estándar. Existe, no obstante, una desviación importante respecto a las normas: La sincronización.

Cada CSIV envía a nuestro servidor RADIUS un paquete tipo autentificación de usuario, con fines de sincronización. Esos paquetes se mandan, aproximadamente, cada 90 segundos, y son claramente reconocibles observando parte de su contenido:

          48: 69ab 3536 3738 3930 3132 3334 3536 1234    i.567890123456.4
          64: 4643 3a20 4d65 6e73 616a 6520 5349 4e43    FC: Mensaje SINC
          80: 524f 4e49 534d 4f20 6465 2049 6e66 6f76    RONISMO de Infov
          96: 6961 2d54 656c 6566 6f6e 6963 6120 492b    ia-Telefonica I+
         112: 442e 0130 5573 7561 7269 6f20 6669 6374    D..0Usuario fict
         128: 6963 696f 2070 6172 6120 7369 6e63 726f    icio para sincro
         144: 6e69 736d 6f20 636f 6e20 496e 666f 7669    nismo con Infovi
         160: 612e 0506 ffff ffff 0203 0021 1202 0000    a..........!....

Analizando estos paquetes nos encontramos:

  • Tipo de paquete: Petición de autentificación.

  • La longitud es bastante más elevada de lo normal. Puede depender del paquete, pero siempre me salen 835 Bytes.

  • El autentificador es la cadena hexadecimal "0000 69ab 3536 3738 3930 3132 3334 3536".

  • Primer atributo: 18 (Reply-Message). Su contenido es "FC: Mensaje SINCRONISMO de Infovia-Telefonica I+D.". Según el protocolo RADIUS, este texto es puramente informativo.

  • Segundo atributo: 1 (Usuario). Su contenido es "Usuario ficticio para sincronismo con Infovia.".

  • Tercer atributo: 5 (NAS-Port). Su contenido son 16 bits a uno, "ff ff".

  • Cuarto atributo: 2 (User-Passwd). Consta de un único carácter: un byte Null (cero).

  • A continuación sigue una serie de secuencias con atributos 33 (Proxy-State), cada una de ellas midiendo 16 o más bytes.

Nuestro servidor RADIUS devuelve un paquete de protocolo 3 (Acceso denegado), y su atributo 33 (Proxy-State) será el mismo que el enviado en último lugar (sólo se devuelve éste) en el paquete anterior, cambiando los cuatro primeros bytes de "V1 V2 00 00" a "V1' V2' 00 02".

El formato de cada una de las secuencias "Proxy-State" es "V1 V2 00 00 00 00 00 00 NI NI NI NI NU FF 00 00 [(ID ID ID ID)...]". Si todas esas secuencias no caben en un único paquete, se distribuyen en varios, enviándose de forma alternativa cada 90 segundos (cada 90 segundos se transmite un paquete). El significado es:

  • V1, V2
    Versión de software RADIUS de los CSIV's.

  • V1', V2'
    Versión de software RADIUS de nuestro servidor local.

  • NI
    NAS Identifier: Identifica el dispositivo al que se está refiriendo. Los NAS (Network Access Server) son los servidores a los que se conectan los usuarios. Cada "Proxy-State" se refiere a un NAS.

  • NU
    Número de sesiones activas en ese NAS. Puede ser cero.

  • ID
    Identificación de las sesiones activas en ese NAS. Cada sesión son 4 bytes (en formato Hi/Lo), que se corresponde con los valores almacenados en el fichero de detalle RADIUS bajo el nombre de "Acct-Session-Id".


Casuística Infovía

Estudiando la documentación anterior puede verse que la versión RADIUS de Infovía es idéntica a su código base (ASCEND), y que las necesarias diferencias para sostener esta arquitectura de red se han centralizado a través del campo "Proxy-State".

Los cambios son necesarios para permitir la coordinación y el sincronismo entre los NAS de Infovía y nuestro servidor RADIUS, que es quien gestiona las direcciones IP. Existen varias posibilidades:

  • Funcionamiento normal

    Los NAS y el servidor RADIUS están perfectamente sincronizados.

  • Pérdida de comunicación con un CSIV

    En este caso los usuarios nuevos serían rechazados (no pueden autentificar). El servidor RADIUS no tiene constancia de los usuarios que han colgado, por lo que no puede liberar sus IPs ni sus sesiones. Por tanto si el CSIV se cae y su tráfico es desviado a través de otro, cualquier usuario que estuviese conectado ya a través de él se verá imposibilitado de conectar por agotamiento de sesiones (tiene sesiones activas).

    Esta situación no puede corregirse hasta que se restablezca la comunicación con el CSIV, ya que en ese momento el CSIV envía al servidor RADIUS el estado de sesiones de sus NAS, y las sesiones que ya no existan sencillamente se liberan. Una solución manual es cerrar "a mano" la conexión del usuario con problemas, mediante la utilidad correspondiente.

    La versión 3.x del servidor RADIUS de infovía libera todas las conexiones dependientes de un CSIV con elque se ha perdido la comunicación. Ello soluciona el problema.

  • Parada controlada del servidor RADIUS

    El servidor RADIUS vuelca su estado en disco y termina. La situación es similar a la anterior. Los usuarios nuevos son rechazados (no existe servidor que los autentifique), y los usuarios que cuelgan quedan en estado inconsistente.

    En cuanto se ejecute de nuevo el servidor, leerá su estado y, como en el caso anterior, empezará a cerrar las sesiones inexistentes (usuarios que han colgado) a medida que le vayan llegando los sincronismos de los CSIVs.

    Un riesgo muy a tener en cuenta es la posibilidad de que el servidor RADIUS muera por cualquier razón, y al reiniciarlo cargue un estado antiguo y anticuado. Las sesiones que ya no existan (si el estado es antiguo, la mayoría), se liberan gracias a los sincronismos. El problema está con las sesiones activas que no existan en el estado recuperado ya que, entre otras cosas, puede reasignarse su IP a otros usuarios.

    En principio el problema es "solucionable" mediante chequeos de consistencia, en los que el servidor RADIUS observa los sincronismos de los CSIVs. Si no aparecen sesiones presentes en su estado, las dá de baja; si aparecen sesiones no presentes en su estado, solicita al NAS que corte la llamada :). Las peticiones de autentificación que vayan entrando mientras el servidor se sincroniza son rechazadas.

    La parada controlada del servidor es una opción interesante para, por ejemplo, poder reiniciar la máquina sin necesidad de desconectar a todos los usuarios.

  • Reinicio de un CSIV

    En este caso es similar al del corte en la comunicación. Al arrancar, el CSIV liberará todas las conexiones. El servidor RADIUS detectará este hecho al seguir las sincronizaciones.

  • Reinicio del servidor RADIUS

    Como en el caso de parada controlada, pero sin disponer de estado. En el proceso de sincronizarse con los CSIVs, el servidor procederá al corte sistemático de las conexiones en curso.

Una de las funcionalidades incluídas en las herramientas del servidor RADIUS es la de "desconectar usuario". Dicha orden envía al CSIV correspondiente un paquete RADIUS de rechazo de conexión, como si la autentificación hubiese fallado. No obstante en dicho paquete no se indica -de forma estándar- qué conexión se debe cerrar. Esa información se incluye en el campo "Proxy-State", a modo de sincronismo y con la misma sintaxis ya vista, indicando únicamente las sesiones que quedan en el NAS correspondiente a la sesión que queremos cortar. Obviamente entre ellas no se encuentra "la víctima".

Si no podemos comunicarnos con el CSIV en cuestión no podemos liberar la sesión de este modo; debemos combinar esa función con la de "reutilizar IP".

Todos estos problemas, no contemplados en la especificación RADIUS original son debidos al empleo de este sistema en un entorno de gran demanda de recursos. Telefónica no se puede permitir, por ejemplo, el repetir los paquetes RADIUS de forma indefinida hasta que el proveedor se dá por enterado, que es lo que se especifica en la norma. En ese sentido Telefónica no ha tenido elección.


Información adicional

Algunos enlaces que pueden resultar de interés:


Historia

  • 18/Ago/98: Completados los paquetes de autentificación y el campo de identificación de llamada RDSI. Añadida la casuística Infovía.

  • 17/Ago/98: Identificados los campos de versión RADIUS Infovía.

  • 14/Ago/98: Desensamblado de los paquetes RADIUS Infovía, indicando los valores típicos enviados.

  • 20/Nov/97: Primera versión de este documento.



Python Zope ©1997-98 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS