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
Accounting, 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 roamming 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.

Índice
1 Historia de Diameter
2 Mejora respecto de RADIUS
3 Servicios AAA
3.1 Autenticación
3.2 Autorización
3.3 Contabilidad
4 Aplicación
5 Seguridad en Diameter
6 Formato del mensaje
6.1 Cabeceras Diameter
6.2 Cabeceras AVPs
7 Sesiones Diameter
7.1 Conexiones vs Sesiones
8 Flujo de mensajes Diameter
9 Nodos Diameter
9.1 Relay
9.2 Proxy
9.3 ReDirect
9.4 Traslation
10 RFCs
11 Referencias
Historia de Diameter
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

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
Autenticación
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
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
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

Aplicaciones en protocolo Diameter

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.
Tanto el HSS y la SLF se comunican usando el protocolo Diameter.
Para cada aplicación que use los servicios de DIAMETER se genera el protocolo
adaptado a la misma.

Seguridad en Diameter
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

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
Cabecera Diameter
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
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.

Cabecera 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
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
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

Flujo mensajes Diameter

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
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:

Agente Relay/Proxy

Agente ReDirect

Agente Traslation
Relay
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
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
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
Es el encargado de la compatibilidad, realiza la traducción entre DIAMETER y otros
protocolos AAA, como por ejemplo la compatibilidad con RADIUS.

RFCs
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 3588 Diameter Base Protocol. September 2003 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 4005 Diameter Network Access Server 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
1234567

Control de autoridades
Proyectos WikimediaWd Datos: Q1208648IdentificadoresGND: 7625755-1
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.