Diameter (protocolo)
Diameter es un protocolo de red, diseñado para suministrar un marco de trabajo que ofrezca servicios AAA (en inglés: "Authentication, Authorization, Accounting") para aplicaciones que involucran acceso a redes o aplicaciones IP Móvil. Diameter es un protocolo cuyo desarrollo se ha basado en el protocolo RADIUS, esta estandarizado de acuerdo con el RFC 6733 “Diameter Base Protocol”(Obsoleto: RFC 3588). En dicho RFC, se establecen las bases de Diameter y sólo se especifica el soporte para el protocolo AAA, aunque el concepto básico de Diameter es permitir que pueda ser extendido para proporcionar servicios de Authentication y Authorization. Tratando dichos servicios como aplicaciones para Diameter descritas en documentos separados. El concepto de aplicaciones para Diameter está definido en el RFC 6733 (Obsoleto: RFC 3588) como servicios, protocolos y procedimientos que usan las facilidades suministradas por los servidores y Proxis Diameter y por el protocolo en sí. Todas estas aplicaciones deben soportar las funcionalidades definidas en el documento base RFC 6733(Obsoleto: RFC 3588). Diameter está diseñado para trabajar tanto de una manera local como en un estado de alerta, sondeo y captura, que en inglés se le denomina roaming de AAA, que permite ofrecer servicios sumamente móviles, dinámicos, flexibles y versátiles. Es un protocolo peer-to-peer en el sentido que cada nodo puede iniciar una solicitud o request. Debido a esta característica peer-to-peer todos los nodos que implementan Diameter pueden ser clientes, servidores o agentes Diameter.[1][2][3][4][5][6][7]
Historia de Diameter[editar]
Al terminar el protocolo RADIUS en el primer semestre de 2000, surgió un nuevo grupo de trabajo del IETF denominado AAA y decidió dar inicio al desarrollo de un nuevo protocolo que fuese el sucesor de RADIUS. Se evaluaron varios protocolos y finalmente se optó por evolucionar el protocolo DIAMETER, así que dedicaron su esfuerzo en mejorarlo y estandarizarlo ante el IETF. Inicialmente diseñado como una mejora del protocolo RADIUS la meta era maximizar la compatibilidad y facilitar la migración desde RADIUS. El origen de su nombre, no es un acrónimo, sino un juego de palabras y de lógica ingeniosa que representa al diámetro como el doble del radio, aunque sin embargo este protocolo es mucho más que eso y numerosos autores citan DIAMETER como el futuro de los protocolos AAA.
Mejora respecto de RADIUS[editar]
Las principales diferencias de DIAMETER si lo comparamos con su antecesor RADIUS son:
- Usa protocolos de transportes fiables (TCP o SCTP, no UDP).
- Usa seguridad a nivel de transporte (IPSEC o TLS).
- Tiene compatibilidad transicional con RADIUS.
- Tiene un espacio de direcciones mayor para AVPs (Attribute Value Pairs, pares atributo-valor) e identificadores (32 bits en lugar de 8).
- Es un protocolo peer-to-peer en lugar de cliente-servidor: admite mensajes iniciados por el servidor.
- Pueden usarse modelos con y sin estado.
- Tiene descubrimiento dinámico de peers (usando DNS, SRV y NAPTR).
- Tiene negociación de capacidades.
- Admite ACKs en el nivel de aplicación, definiendo métodos de fallo y máquinas de estado (RFC 3539).
- Tiene notificación de errores.
- Tiene mejor compatibilidad con roaming.
- Es más fácil de extender, pudiendo definirse nuevos comandos y atributos.
- Incluye una implementación básica de sesiones y control de usuarios.
Servicios AAA[editar]
Autenticación[editar]
La autenticación es el proceso gracias al cual podemos verificar la identidad de quien envía información y también de quien la recibe. Para lograr la autenticación y averiguar que alguien es quien dice ser, se utilizan las identidades que los usuarios presentan a la red a través de credenciales. Existen autenticación de usuario, autenticación de equipo, autenticación de Mensaje, autenticación unilateral, autenticación mutua, autenticación server…
Autorización[editar]
La autorización es el proceso posterior a la autenticación. Es el proceso mediante el cual se le asigna ciertos privilegios al poseedor de un credencial particular. Los privilegios se asocian al perfil del usuario del terminal. Los privilegios pueden ser permitir el acceso a una serie de recursos, como bases de datos, archivos, acceso a periféricos, tiempo de uso de un procesador, ejecución de ciertas instrucciones etc.
Contabilidad[editar]
Es el proceso de recolección de información sobre el uso de recursos con el fin de realizar otras funciones como planificación de capacidad, auditorías, facturación y asignación de costos. La auditoría consiste en el chequeo periódico para determinar la firmeza de la información y de las políticas de gestión, en especial sobre la seguridad. La asignación de costos trata sobre la estructura de costos para cada uno de los servicios de los usuarios. El registro contable representa un resumen sobre el consumo de recursos de un usuario y es generado por el Accounting Server. La seguridad CMS (Content Management System), puede aplicarse a los mensajes de accounting para otorgarle a los datos una fuerte autenticación e integridad de información. El protocolo define algunos AVP que deben estar presentes en los mensajes de petición para accounting en la sesión de un usuario. Adicionalmente, para las aplicaciones que requieren de múltiples sesiones de accounting, ha sido definido un AVP Accounting-Sub-Session-Id.
Aplicación[editar]
Una aplicación Diameter no es una aplicación de software, si no un protocolo basado en el protocolo base de DIAMETER definido en RFC 6733 (Obsoleto: RFC 3588).Cada aplicación está definido por un identificador de la aplicación y puede añadir nuevos códigos de comando y / o nuevos AVPs obligatorios (Atributo-Valor par). La adición de un nuevo AVP opcional no requiere una nueva aplicación. Como las aplicaciones son desarrolladas como extensiones, se van diseñando a medida que se necesiten. Ejemplos de las aplicaciones Diámetro:
- Aplicaciones móviles IPv4 (MobileIP, RFC 4004).
- Aplicación de servidor de acceso a red (NASREQ, RFC 4005).
- Aplicación de protocolo extensible de autenticación (EAP) (RFC 4072).
- Aplicación de control de crédito (DCCA, RFC 4006).
- Aplicación de protocolo de inicio de sesión (SIP) (RFC 4740).
- Diversas aplicaciones en el 3GPP Subsistema Multimedia IP.
Para cada aplicación que use los servicios de DIAMETER se genera el protocolo adaptado a la misma.
Seguridad en Diameter[editar]
DIAMETER se apoya en IPsec o TLS para ofrecer seguridad. Estos protocolos son aceptables en ambientes donde todos los nodos son confiables.
Todas las implementaciones de DIAMETER deben soportar IPsec ESP en modo Transporte e IKE para autenticación, negociación de Asociaciones de Seguridad, gestión de claves. Es obligatorio para todos los servidores y agentes Diameter que soporten IPsec y TLS, sin embargo los clientes solo están obligados a soportar IPsec, mientras que TLS es opcional.
Formato del mensaje[editar]
Un mensaje del protocolo DIAMETER está formado por una cabecera o header que tiene un tamaño de 20 octetos y por una cantidad variable de AVPs.
Cabeceras Diameter[editar]
| Bit | 0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | version | Longitud mensaje | ||||||||||||||||||||||||||||||
| 32 | R |
P |
E |
T |
Código de comando | |||||||||||||||||||||||||||
| 64 | Aplicación ID | |||||||||||||||||||||||||||||||
| 96 | Hop-by-Hop ID | |||||||||||||||||||||||||||||||
| 128 | End-to-End ID | |||||||||||||||||||||||||||||||
| 160 ... |
AVPs ... | |||||||||||||||||||||||||||||||
Versión: El campo versión indica la versión del Protocolo Diameter, desde 2014 solo admite el valor 1. Longitud del Mensaje: El tamaño de este campo es de 3 octetos. Indica la longitud del mensaje incluyendo el header y los AVPs acopladas. Comando de flags: Campo de 1 octeto. Los flags que aparecen en este comando son:
- R (Request): Si su valor es 1 indica que se trata de un mensaje de solicitud (Request), si por el contrario su valor es 0, se trata de un mensaje de respuesta (Answer).
- P (Proxiable): Si está activo, el mensaje puede ser proxy, retransmitido o redirigido. Si está desactivado, el mensaje debe ser procesado localmente.
- E (Error): Utilizamos este flag para indicar que el mensaje contiene un error de protocolo. Catalogamos este tipo de mensaje como mensajes de error. Este bit no debe ser fijado en los mensajes Request.
- T (Retransmisión): Este flag se utiliza después de un error en el proceso de conmutación de enlace, para ayudar a eliminar solicitudes duplicadas. Se establece cuando volver a enviar peticiones.
- Código de Comandos: Campo de tamaño 3 octetos. Indica la acción que una aplicación Diameter debe tomar al recibir el mensaje. Este espacio de direcciones es manejado por el IANA.Todas las abreviaciones terminan en R (Request) o en A (Answer). Además todos los mensajes Request tienen el flag R puesto a “1”.Los comandos 0-255 están reservados para compatibilidad con RADIUS. Los valores 256-16777213 son para los comandos permanentes. Los valores 16777214 y 16777215 (hex 0xfffffe y 0xFFFFFF) se reservan para fines de experimentación y ensayo.
| Nombre Comando | Abbr. | Código | Aplicación |
|---|---|---|---|
| AA-Request | AAR | 265 | Diameter base |
| AA-Answer | AAA | 265 | Diameter base |
| Diameter-EAP-Request | DER | 268 | Diameter base |
| Diameter-EAP-Answer | DEA | 268 | Diameter base |
| Abort-Session-Request | ASR | 274 | Diameter base |
| Abort-Session-Answer | ASA | 274 | Diameter base |
| Accounting-Request | ACR | 271 | Diameter base |
| Accounting-Answer | ACA | 271 | Diameter base |
| Credit-Control-Request | CCR | 272 | Diameter base |
| Credit-Control-Answer | CCA | 272 | Diameter base |
| Capabilities-Exchange-Request | CER | 257 | Diameter base |
| Capabilities-Exchange-Answer | CEA | 257 | Diameter base |
| Device-Watchdog-Request | DWR | 280 | Diameter base |
| Device-Watchdog-Answer | DWA | 280 | Diameter base |
| Disconnect-Peer-Request | DPR | 282 | Diameter base |
| Disconnect-Peer-Answer | DPA | 282 | Diameter base |
| Re-Auth-Request | RAR | 258 | Diameter base |
| Re-Auth-Answer | RAA | 258 | Diameter base |
| Session-Termination-Request | STR | 275 | Diameter base |
| Session-Termination-Answer | STA | 275 | Diameter base |
| User-Authorization-Request | UAR | 300 | Diameter base |
| User-Authorization-Answer | UAA | 300 | Diameter base |
| Server-Assignment-Request | SAR | 301 | Diameter base |
| Server-Assignment-Answer | SAA | 301 | Diameter base |
| Location-Info-Request | LIR | 302 | Diameter base |
| Location-Info-Answer | LIA | 302 | Diameter base |
| Multimedia-Auth-Request | MAR | 303 | Diameter base |
| Multimedia-Auth-Answer | MAA | 303 | Diameter base |
| Registration-Termination-Request | RTR | 304 | Diameter base |
| Registration-Termination-Answer | RTA | 304 | Diameter base |
| Push-Profile-Request | PPR | 305 | Diameter base |
| Push-Profile-Answer | PPA | 305 | Diameter base |
| User-Data-Request | UDR | 306 | Diameter base |
| User-Data-Answer | UDA | 306 | Diameter base |
| Profile-Update-Request | PUR | 307 | Diameter base |
| Profile-Update-Answer | PUA | 307 | Diameter base |
| Subscribe-Notifications-Request | SNR | 308 | Diameter base |
| Subscribe-Notifications-Answer | SNA | 308 | Diameter base |
| Push-Notification-Request | PNR | 309 | Diameter base |
| Push-Notification-Answer | PNA | 309 | Diameter base |
| Bootstrapping-Info-Request | BIR | 310 | Diameter base |
| Bootstrapping-Info-Answer | BIA | 310 | Diameter base |
| Message-Process-Request | MPR | 311 | Diameter base |
| Message-Process-Answer | MPA | 311 | Diameter base |
| Update-Location-Request | ULR | 316 | Diameter base |
| Update-Location-Answer | ULA | 316 | Diameter base |
| Authentication-Information-Request | AIR | 318 | Diameter base |
| Authentication-Information-Answer | AIA | 318 | Diameter base |
| Notify-Request | NR | 323 | Diameter base |
| Notify-Answer | NA | 323 | Diameter base |
| Provide-Location-Request | PLR | 8388620 | 3GPP-LCS-SLg (Application-ID 16777255) |
| Provide-Location-Answer | PLA | 8388620 | 3GPP-LCS-SLg (Application-ID 16777255) |
| Routing-Info-Request | RIR | 8388622 | 3GPP-LCS-SLh (Application-ID 16777291) |
| Routing-Info-Answer | RIA | 8388622 | 3GPP-LCS-SLh (Application-ID 16777291) |
- ID de Aplicación: Campo de tamaño 4 octetos. IANA define un identificador para cada aplicación Diameter. El protocolo base no necesita identificador ya que es soportado por todos los nodos. También con este campo se identifica la aplicación a la cual va dirigido el mensaje.
| Application-ID | Abbr. | Full name | Usage |
|---|---|---|---|
| 0 | Base | Diameter Common Messages | Diameter protocol association establishment/teardown/maintenance |
| 16777217 | Sh | 3GPP Sh | VoIP/IMS SIP Application Server to HSS interface |
| 16777251 | S6a/S6d | 3GPP S6a/S6d | LTE Roaming signaling |
| 16777255 | SLg | 3GPP LCS SLg | Location services |
- Hop-by-Hop Identificador: Campo de 4 octetos. Es un identificador que hace que exista coincidencia entre las solicitudes y las respuestas. A medida que el mensaje pasa de un salto a otro se cambia este identificador. En cada respuesta se envía el mismo número que se encontró en este campo en la solicitud que generó dicha respuesta. Las respuestas que no concuerdan con un identificador Hop-by-Hop conocido son ignoradas por el agente Diameter.
- End-to-End Identificador: Es un campo de 4 octetos que identifica los extremos en una comunicación Diameter y permite detectar cuando existen mensajes duplicados.
Cabeceras AVPs[editar]
Un AVP es una forma de representación de datos llamados Atributos. Se usa en los sistemas donde se requiere que las estructuras de datos permitan extensiones sin modificar el código. En DIAMETER todos los mensajes están formados por una cabecera estándar más una serie de cabeceras AVPs. Todos los datos entregados por DIAMETER están en el formato de un AVP, algunos son usados directamente por DIAMETER, mientras que otros son usados por aplicaciones de Diameter. Los AVPs se usan para transportar información de usuario necesaria para la autenticación o para transportar información específica para autorización de un servicio entre cliente y servidor. También se usa para intercambiar información de uso de recursos por parte de los usuarios. Un AVP está formado por una cabecera AVP de 12 octetos, seguido por un campo de datos AVP.
| Bit offset | 0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Código AVP | |||||||||||||||||||||||||||||||
| 32 | V |
M |
P |
Longitud AVP | ||||||||||||||||||||||||||||
| 64 | ID proveedor (opcional) | |||||||||||||||||||||||||||||||
| 96 ... |
Datos ... | |||||||||||||||||||||||||||||||
- Código AVP: Este campo de 4 octetos, identifica al AVP de manera unívoca.
- Longitud AVP: Es un campo de 3 octetos que indica la longitud total del AVP, incluyendo la cabecera más los datos, en octetos.
- Flags: Existen tres flags:
- V: Este flag indica si el vendedor ID viene incorporado o no en la cabecera.
- M: Conocido como bit obligatorio, indica si se requiere apoyo de la AVP. Si un AVP con el "M bit" es recibido por un cliente Diameter, servidor proxy, o el agente de traducción y, o bien la AVP o su valor es reconocido, el mensaje debe ser rechazado.
- P: Indica la necesidad de cifrado de seguridad de extremo a extremo.
Sesiones Diameter[editar]
Según IETF RFC 6733 una sesión Diameter es una consecución de eventos relacionados dedicados a una actividad específica. Todos los paquetes Diameter con el mismo identificador de sesión o Session-Id son considerados parte de la misma sesión. En el contexto de un usuario que marca hacia un servidor de acceso de red o NAS, la sesión se compone de todos los mensajes Diameter intercambiados entre el NAS y el servidor Diameter desde el momento que usuario marca hasta que la conexión se interrumpe. En el contexto del [IMS] (IP Multimedia Subsystem), una sesión Diameter puede estar compuesta de todos los mensajes intercambiados entre el proxy SIP denominado S-CSCF actuando como Diameter Client, y el servidor base de datos de localización de suscripción o HSS actuando como Diameter Server, durante el tiempo en que el usuario se encuentra registrado.
Conexiones vs Sesiones[editar]
Conexión Diameter es un enlace a nivel de transporte entre dos pares, en la cual se envían y se reciben mensajes Diameter.
Sesión Diameter es el concepto que existe a nivel de capa aplicación que se establece una sesión entre un cliente y servidor la cual es identificada mediante el AVP por cada servicio invocado por un usuario.
Flujo de mensajes Diameter[editar]
El protocolo DIAMETER usa los protocolos TCP o SCTP para el transporte por el puerto 3868. El flujo de mensajes en una conexión Diameter empieza con el establecimiento de la conexión. Después el que inicia la conexión envía un mensaje de Solicitud e Intercambio de Capacidades (CER), el receptor de este mensaje responde con un mensaje de respuesta de intercambio de capacidades (CEA), de forma opcional se puede negociarse si se desea TLS. La conexión ya está establecida y lista para el intercambio de mensajes de aplicación. Si durante un intervalo de tiempo, no se intercambian mensajes uno de los dos extremos enviará una solicitud de dispositivo “perro guardián” (DWR) y el otro responderá con una respuesta al dispositivo “perro guardián” (DWA). Cuando uno de los dos extremos desee finalizar la conexión, enviará un mensaje de solicitud de desconexión (DPR). Por último se responde al mensaje (DPR) con un mensaje (DPA) para dar por finalizada la conexión.
Nodos Diameter[editar]
Un nodo es un host que implementa el protocolo DIAMETER. Existen los siguientes tipos:
- Cliente: Está ubicado en el borde de la red de control de acceso. El cliente típico de DIAMETER es un NAS que necesita llevar a cabo los procesos de AAA para una cierta tecnología de acceso. Los NAS precisan autenticar los terminales conectados a la red antes de darles acceso a los recursos de la misma.
- Servidor: El servidor de Diameter maneja solicitudes AAA (autenticación, autorización y contabilidad) en un dominio particular.
- Agentes Diameter: Los agentes Diameter poseen las tablas de enrutamiento Diameter. Los tipos de Agentes existentes en Diameter son:
Relay[editar]
Son los agentes Diameter que aceptan y enrutan los mensajes de otros nodos hacia su destino, en función de la información que contiene el mensaje y las tablas de enrutamiento. No necesitan analizar el contenido del mensaje, solo analizan los necesario para el enrutamiento. Modifican la parte del mensaje relativa al enrutamiento ya que necesita quitar y añadir información, pero no modifica el contenido del mensaje.
Proxy[editar]
Es similar a un Relay con toma de decisiones sobre la base de ciertas políticas de acceso. El Proxy puede hacer un seguimiento del estado de NAS para propósitos de suministros de recursos. Necesita analizar los mensajes que transcurren por él y puede generar mensajes de REJECT en caso de violación de las políticas.
ReDirect[editar]
Actúa como individuo intermediario para la transformación de realms(dominio administrativo) a direcciones de servidores con las tablas de enrutamiento de un grupo determinado. Un DRD (Diameter ReDirect) recibe request y responde con una respuesta especial que contiene la información de enrutamiento que le permite al nodo que le envió la solicitud enviar una nueva solicitud directamente al servidor del destinatario. El DRD no hace relay de solicitudes y se encuentra fuera del camino de enrutamiento.
Traslation[editar]
Es el encargado de la compatibilidad, realiza la traducción entre DIAMETER y otros protocolos AAA, como por ejemplo la compatibilidad con RADIUS.
RFCs[editar]
El protocolo Diameter se define actualmente en las siguientes IETF RFC: (Los RFC obsoletos se indican con tachado de texto.)
| # | Title | Date published | Related article | Obsoleted by | Notes |
|---|---|---|---|---|---|
| RFC 6733 | |||||
| RFC 3589 | Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. | September 2003 | |||
| RFC 4004 | Diameter Mobile IPv4 Application. | August 2005 | |||
| RFC 7155 | |||||
| RFC 4006 | Diameter Credit-Control Application. | August 2005 | Diameter Credit-Control Application | ||
| RFC 4072 | Diameter Extensible Authentication Protocol (EAP) Application. | August 2005 | |||
| RFC 4740 | Diameter Session Initiation Protocol (SIP) Application. M. | November 2006 | |||
| RFC 5224 | Diameter Policy Processing Application. | March 2008 | |||
| RFC 5431 | Diameter ITU-T Rw Policy Enforcement Interface Application. | March 2009 | |||
| RFC 5447 | Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. | February 2009 | |||
| RFC 5516 | Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). | April 2009 | - | ||
| RFC 5624 | Quality of Service Parameters for Usage with Diameter. | August 2009 | |||
| RFC 6733 | Diameter Base Protocol. | October 2012 | |||
| RFC 6737 | The Diameter Capabilities Update Application. | October 2012 | |||
| RFC 7155 | Diameter Network Access Server Application. | April 2014 |
Referencias[editar]
- ↑ Forero Saboya, Néstor Gabriel (13 de diciembre de 2009). «Taxonomía de los servidores AAA». Universidad Libre de Bogotá.
- ↑ Prof. Marcano, Diógenes. «IP Multimedia Subsystem». ATEL ASESORES C.A. Archivado desde el original el 27 de noviembre de 2015. Consultado el 26 de noviembre de 2015.
- ↑ «Protocolos de control de acceso RADIUS.». Revista Telemática.
- ↑ Ing. Mendioroz, Fernando (2014). «Sistemas de Conmutación: Telefónia IP». Popayán.
- ↑ «RFC 6733 Diameter Base Protocol». 12 de octubre de 2014.
- ↑ «DIAMETER Framework Document». Febrero de 2001.
- ↑ «Introduction to Diameter Protocol - What is Diameter Protocol?». Sun Microsystems. 20 de marzo de 2009. Archivado desde el original el 4 de julio de 2011.
Datos: Q1208648