stringtranslate.com

Diámetro (protocolo)

Diameter es un protocolo de autenticación, autorización y contabilidad (AAA) para redes informáticas. Evolucionó a partir del protocolo anterior RADIUS . Pertenece a los protocolos de capa de aplicación en el conjunto de protocolos de Internet .

Las aplicaciones de diámetro amplían el protocolo base agregando nuevos comandos y/o atributos, como los que se utilizan con el Protocolo de autenticación extensible (EAP).

Comparación con RADIUS

El nombre es un juego de palabras, derivado del protocolo RADIUS , que es el predecesor (un diámetro es el doble del radio). Diameter no es directamente compatible con versiones anteriores , pero proporciona una ruta de actualización para RADIUS. Las principales características proporcionadas por Diameter pero que faltan en RADIUS son:

Además: al igual que RADIUS, está pensado para funcionar tanto en situaciones AAA locales como de roaming. Utiliza TCP o SCTP, a diferencia de RADIUS, que utiliza UDP. A diferencia de RADIUS, no incluye cifrado, pero puede protegerse mediante seguridad a nivel de transporte (IPSEC o TLS). El tamaño base del identificador AV es de 32 bits, a diferencia de RADIUS, que utiliza 8 bits como tamaño base del identificador AV. Al igual que RADIUS, admite modos sin estado y con estado. Al igual que RADIUS, admite el reconocimiento de la capa de aplicación y define la conmutación por error. Diameter se utiliza para muchas interfaces diferentes definidas por los estándares 3GPP, y cada interfaz normalmente define nuevos comandos y atributos.

Aplicaciones

Una aplicación Diameter no es una aplicación de software , sino un protocolo basado en el protocolo base Diameter definido en RFC 6733 (que deja obsoleto RFC 3588) y RFC 7075. Cada aplicación se define mediante un identificador de aplicación y puede agregar nuevos códigos de comando y/o nuevos AVP obligatorios ( par atributo-valor ). Agregar un nuevo AVP opcional no requiere una nueva aplicación.

Ejemplos de aplicaciones de diámetro:

Tanto el HSS como el SLF se comunican mediante el protocolo Diameter.

(Arquitectura de arranque genérica): Función de servidor de arranque

Historia

El protocolo Diameter fue desarrollado inicialmente por Pat R. Calhoun, Glen Zorn y Ping Pan en 1998 para proporcionar un marco de autenticación, autorización y contabilidad ( AAA ) que pudiera superar las limitaciones de RADIUS. RADIUS tenía problemas de confiabilidad, escalabilidad, seguridad y flexibilidad. RADIUS no puede manejar de manera efectiva el acceso remoto, la movilidad de IP y el control de políticas. El protocolo Diameter define un protocolo de políticas utilizado por los clientes para realizar políticas, AAA y control de recursos. Esto permite que un solo servidor maneje políticas para muchos servicios. [1]

Al igual que RADIUS, Diameter proporciona funcionalidad AAA, pero utiliza TCP y SCTP en lugar de UDP , delegando así la detección y el manejo de problemas de comunicación a esos protocolos. El protocolo Diameter se ha mejorado aún más con el desarrollo del Subsistema Multimedia IP (IMS) del Proyecto de Asociación de Tercera Generación (3GPP). Las interfaces S6a, S6b, Gx, Gy, Sy, Rx, Cx, Dh, Dx, Rf, Ro, Sh y Zh son compatibles con las aplicaciones Diameter. [2] Mediante el uso de extensiones, el protocolo fue diseñado para ser extensible para soportar proxies, intermediarios, seguridad fuerte, IP móvil, servidores de acceso a red (NASREQ), contabilidad y gestión de recursos.

Descripción del protocolo

El protocolo base de Diameter está definido por RFC 6733 (Obsoletos: RFC 3588 y RFC 5719) y define los requisitos mínimos para un protocolo AAA . Las aplicaciones Diameter pueden extender el protocolo base agregando nuevos comandos, atributos o ambos. La seguridad de Diameter es proporcionada por IPsec o TLS . La IANA ha asignado el puerto TCP y SCTP número 3868 a Diameter, como se indica en la sección 11.4 de RFC 6733.

Formato de paquete

El paquete consta de un encabezado Diameter y una cantidad variable de pares atributo-valor, o AVP, para encapsular información relevante al mensaje Diameter.

Versión

Este campo indica la versión del protocolo base Diameter. A partir de 2014, el único valor admitido es 1. [3]

Longitud del mensaje

El campo Longitud del mensaje indica la longitud del mensaje Diameter en bytes, incluidos los campos de encabezado y los AVP rellenos.

Banderas de comando

El bit " R " (solicitud): si está activado, el mensaje es una solicitud. Si no está activado, el mensaje es una respuesta.

El bit " P " (Proxiable): si está configurado, el mensaje PUEDE ser enviado a través de proxy, retransmitido o redirigido. Si está desactivado, el mensaje DEBE procesarse localmente.

El bit " E " (error): si se configura, el mensaje contiene un error de protocolo y no se ajustará al CCF descrito para este comando. Los mensajes con el bit "E" configurado se conocen comúnmente como mensajes de error. Este bit NO DEBE configurarse en los mensajes de solicitud.

El bit " T " (mensaje potencialmente retransmitido): este indicador se activa después de un procedimiento de conmutación por error de enlace para facilitar la eliminación de solicitudes duplicadas. Se activa cuando se reenvían solicitudes que aún no se han reconocido como indicación de un posible duplicado debido a una falla de enlace.

Comandos

A cada par de comandos de solicitud/respuesta se le asigna un código de comando. El bit "R" en el campo Indicadores de comando del encabezado identifica si se trata de una solicitud o de una respuesta.

Los valores 0-255 están reservados para la compatibilidad con versiones anteriores de RADIUS. Los valores 256-16777213 son para comandos estándar permanentes asignados por IANA . Los valores 16777214 y 16777215 (hexadecimales 0xFFFFFE y 0xFFFFFF) están reservados para fines experimentales y de prueba.

Se utiliza un código de comando para determinar la acción que se debe tomar para un mensaje en particular. Algunos comandos Diameter comunes definidos en el protocolo (base y aplicaciones) son:

ID de la aplicación

El identificador de aplicación se utiliza para identificar a qué aplicación Diameter corresponde el mensaje. La aplicación puede ser una aplicación de autenticación, una aplicación de contabilidad o una aplicación específica del proveedor.

Los agentes de Diameter que se ajustan a una determinada extensión Diameter publicitan su soporte incluyendo un valor específico en el atributo Auth-Application-Id del comando Capabilities-Exchange-Request (CER) y Capabilities-Exchange-Answer (CEA).

El valor del campo Application-ID en el encabezado es el mismo que el de cualquier AVP Application-Id relevante incluido en el mensaje. Por ejemplo, el valor del Application-ID y del atributo Auth-Application-Id en el comando Credit-Control-Request (CCR) y Credit-Control-Answer (CCA) para la aplicación de control de crédito Diameter es 4. [4]

Identificador Hop-by-Hop

El identificador salto a salto es un campo entero de 32 bits sin signo (en orden de bytes de red) que se utiliza para hacer coincidir las solicitudes con sus respuestas, ya que el mismo valor de la solicitud se utiliza en la respuesta.

El protocolo Diameter requiere que los agentes de retransmisión y proxy mantengan el estado de la transacción, que se utiliza para fines de conmutación por error. El estado de la transacción implica que al reenviar una solicitud, se guarda su identificador de salto a salto; el campo se reemplaza con un identificador único local, que se restaura a su valor original cuando se recibe la respuesta correspondiente. El estado de la solicitud se libera al recibir la respuesta. El agente Diameter ignora las respuestas recibidas que no coinciden con un identificador de salto a salto conocido.

En el caso de redireccionar agentes, el identificador salto a salto se mantiene en el encabezado mientras el agente Diameter responde con un mensaje de respuesta.

Identificador de extremo a extremo

El identificador de extremo a extremo es un campo entero de 32 bits sin signo (en orden de bytes de red) que se utiliza para detectar mensajes duplicados junto con la combinación del AVP de origen-host.

Al crear una solicitud, el identificador de extremo a extremo se establece en un valor único local. Los agentes Diameter de ningún tipo no modifican el identificador de extremo a extremo y en la respuesta se utiliza el mismo valor de la solicitud correspondiente.

Pares atributo-valor (AVP)

Para simplificar, el bit " V " del indicador AVP significa específico del proveedor ; el bit " M " significa obligatorio ; el bit " P " significa protegido .

El bit " V ", conocido como bit específico del proveedor, indica si el campo opcional Vendor-ID está presente en el encabezado AVP. Cuando se configura, el código AVP pertenece al espacio de dirección del código del proveedor específico.

El bit " M ", conocido como bit obligatorio, indica si se requiere compatibilidad con el AVP. Si un cliente, servidor, proxy o agente de traducción de Diameter recibe un AVP con el bit " M " establecido y el AVP o su valor no se reconocen, el mensaje debe rechazarse. Los agentes de redireccionamiento y retransmisión de Diameter no deben rechazar mensajes con AVP no reconocidos.

El bit " P " indica la necesidad de cifrado para la seguridad de extremo a extremo.

Máquinas de estados

La RFC 3588 define una máquina de estados central para mantener conexiones entre pares y procesar mensajes. Esto forma parte de la funcionalidad básica del protocolo y todas las pilas deberían admitirla y, como tal, abstraerse de las operaciones relacionadas con la conectividad.

Además, las máquinas de estados específicas de la aplicación se pueden introducir más adelante o en una capa de abstracción superior. La RFC 3588 define una máquina de estados de autorización y una máquina de estados de contabilidad.

Flujos de mensajes

La comunicación entre dos pares de diámetro comienza con el establecimiento de una conexión de transporte ( TCP o SCTP ). A continuación, el iniciador envía una solicitud de intercambio de capacidades (CER) al otro par, que responde con una respuesta de intercambio de capacidades (CEA). Para los pares que cumplen con RFC3588, se puede negociar opcionalmente TLS (seguridad de la capa de transporte). Para los pares que cumplen con RFC6733, la negociación de TLS puede realizarse opcionalmente antes de la CER/CEA.

La conexión estará entonces lista para intercambiar mensajes de aplicación.

Si no se han intercambiado mensajes durante algún tiempo, cualquiera de las partes puede enviar una solicitud de vigilancia del dispositivo (DWR) y el otro par debe responder con una respuesta de vigilancia del dispositivo.

Cualquiera de las partes puede finalizar la comunicación enviando una solicitud de desconexión de par (DPR), a la que el otro par debe responder con una respuesta de desconexión de par. Después de eso, se puede desconectar la conexión de transporte.

RFC (Requerimientos de comentarios)

El protocolo Diameter está definido actualmente en las siguientes RFC de IETF : Las RFC obsoletas se indican con texto tachado .

Véase también

Referencias

  1. ^ Pat R. Calhoun, Glen Zorn y Ping Pan (febrero de 2001). "DIAMETER Framework Document". Ietf Datatracker . IETF . Consultado el 30 de abril de 2009 .{{cite news}}: CS1 maint: varios nombres: lista de autores ( enlace )
  2. ^ Naman Mehta (20 de marzo de 2009). "Introducción al protocolo Diameter - ¿Qué es el protocolo Diameter?". Sun Microsystems . Archivado desde el original el 4 de julio de 2011. Consultado el 30 de abril de 2009 .
  3. ^ Arkko, J.; Loughney, J. (2012). Fajardo, V; Zorn, G (eds.). "RFC 6733 - Diameter Base Protocol". Propuesta de estándar . Standards Track. doi : 10.17487/RFC6733 . ISSN  2070-1721 . Consultado el 12 de octubre de 2014 .
  4. ^ Hakala, H.; Mattila, L.; Stura, M.; Loughney, J. (2005). "RFC 4006 - Aplicación de control de crédito de diámetro". Propuesta de estándar . Standards Track. doi : 10.17487/RFC4006 .

Enlaces externos