Este proceso se lleva a cabo a travs de la presentacin de credenciales por parte de la entidad que se est autenticando.

La autenticacin y la autorizacin son procesos diferentes: en la autenticacin se verifica la identidad del usuario, de terminal, de la red o del mensaje. En la autorizacin, proceso posterior a la autenticacin, se permite el acceso a ciertos servicios con una determinada QoS. Por ejemplo, si un usuario compra slo el servicio de navegacin WEB, al ingresar a la red se autentica, pero no ser autorizado al uso de servicios con QoS garantizada, por ejemplo para VoIP.

Por lo general se piensa en el accounting como la facturacin, pero el accounting cubre otras actividades tal como las mencionadas.

SCTP incluye los mecanismos para evitar congestin, inundacin y es resistente a ataques enmascarados. La motivacin para el desarrollo de SCTP fue una serie de inconvenientes presentes en TCP. Por ejemplo: TCP entrega sus mensajes en un orden estricto y esto puede cuasar retardos. Hay aplicaciones en las cuales no se requiere ningn orden en la entrega de mensajes. TCP es vulnerable a los ataques del tipo denial-ofservice, tal como el ataque SYN.

El hecho de que en el documento base slo se especifique el soporte para Accounting, se explica debido a que se espera que todas las aplicaciones de Diameter incluyan dicha funcin. Debido a su caracterstica peer-to-peer, todos los nodos que implementan Diameter pueden ser clientes, servidores o gentes Diameter. Una sesin de comunicacin de Diameter consiste de un intercambio de comandos y de APVs (Attribute Value Pair) entre entidades Diameter. Algunos de los datos llevados por los comandos son usados directamente por Diameter y otros son entregados a aplicaciones particulares que usan Diamaeter.

Ref. 8, pp. 191. Las aplicaciones son desarrolladas como extensiones, as que se van diseando a medida que se necesiten.

El RFC 3539 establece los requisitos y recomendaciones para los protocolos de transporte para protocolos AAA. En el RFC 3588 se establecen los formatos para los mensajes de transporte, reporte de errores, accounting y servicios de seguridad que deben ser soportados por todas las aplicaciones de DIAMETER. Cada aplicacin que usa DIAMETER es descrita en un RFC.

Se recomienda que en lo posible se usen los AVPs definidos, sin embargo, cuando sea necesario incorporar nuevos valores en la tuple, se debe hacer una solicitud al IANA con una explicacin de los nuevos valores del AVP. Las consideraciones al respecto se explican en el RFC 3588. Un procedimiento similar debe seguirse para la creacin de nuevos AVPs. NEGOCIACIN DE LAS CAPACIDADES Se refiere a que los clientes y los servidores puedan ponerse de acuerdo sobre las capacidades que son comunes a ambos, de esta manera se sabe de antemano los servicios que cada entidad puede manejar; esto garantiza el xito de las sesiones de comunicacin.

Cuando una falla de transporte es detectada, es necesario que todos los mensajes pendientes sean redireccionados a un agente alterno, si es posible, a este proceso se le denomina failover

El cliente tpico de Diameter es un NAS que necesita llevar a cabo los procesos de AAA para una cierta tecnologa de acceso. El NAS necesita autenticar los terminales conectados a una red antes de darle acceso a recursos de la misma. Por ejemplo en una red celular, la BS necesita autenticar al mvil; en ese caso la BS tiene un NAS que corre Diameter y usa sus servicios para autenticar al equipo mvil. As el NAS es el cliente Diameter.

Como las estaciones Relay no hacen ningn procesamiento a nivel de aplicaciones, prestan sus servicios de retransmisin a todas las aplicaciones Diameter. La decisin de enrutamiento se realiza usando listas de los realms y peers conocidos almacenados en una tabla denominada Realm Routing Table. Varias NAS puede conectarse a un Relay, y de esta forma se pueden crear nuevas NAS sin necesidad de conocer el resto de la red. De igual forma el Relay facilita la configuracin del servidor Diameter, ya este ltimo no necesita ser modificado al agregar, modificar o eliminar algn NAS.

Aqu se muestra un request desde el NAS para el usuario bob@destino.net. El mensaje es retransmitido por el NAS al DRL, el cual no tiene en su tabla de ruta Diameter ninguna entrada para destino.net. Para esta situacin DRL tiene una direccin por defecto que es la del DRD; a su turno el DRD le enva de regreso al DRL una notificacin de redirect y la direccin del servidor para destino.net, de esta forma el DRL hace el request directamente al servidor HSM que le ha sido indicado.

IKEv2 (RFC 5996) tiene como propsito negociar, crear y borrar Security Associations. IKE normalmente usa el puerto 500 Segurity Association: Es un trmino genrico para referirse a un conjunto de variables que definen las caractersticas y protecciones de IPsec aplicadas a una conexin

IPsec es opcional en IPv4 y obligatorio en IPv6. IPsec es una serie de protocolos con el objetivo de prestar servicios de seguridad a los paquetes que llegan a la capa IP provenientes de la capa de transporte SCTP.

En el caso de IPsec ESP modo Transporte, el proceso se realiza en capa tres, por lo tanto la salida de este protocolo debe ser un paquete IP al cual ESP le ha agregado un encabezado llamado ESP Header y una cola llamada ESP Trailer, y lego un campo opcional ESP ICV tal como se muestra. Visto desde afuera esto es un paquete IP especial, con su encabezado IP y un payload; pero en el campo Protocol (IPv4) o Next Header (IPv6) se coloca 50 con esto se indica que lo que sigue despus del encabezado IP es un encabezado IPsec ESP. El campo ICV (Integrated Check Value) es opcional.

En este modo el ESP Header se coloca entre el IP Header y el paquete de la capa de transporte, despus del ESP Header se ubica el paquete completo de la capa superior, luego est el ESP Trailer y por ltimo el ESP Authentication. Este es el modo que se usa en DIAMETER.

En este modo se conserva el paquete IP original y se encapsula colocndole el encabezado ESP y la cola; adems se coloca un nuevo encabezado IP.

TLS est basado en SSL (Secure Sockets Layer). SSL fue diseado para proteger las comunicaciones va Web y es usado actualmente en la mayora de los navegadores de Internet. TLS es ms genrico que SSL y puede usarse en cualquier tipo de conexin confiable como TCP o SCTP (Stream Control Transmission Protocol), por ejemplo para proteger trfico SIP y por supuesto para aplicaciones en DIAMETER. TLS suministra seguridad a nivel de la capa de transporte y es obligatorio en todos los servidores DIAMETER y opcional en los clientes DIAMETER. CIFRADO DE CLAVE PUBLICA Cada usuario tiene un par de claves, una pblica Pu y una privada Pr. Las claves pblicas son conocidas por todos los usuarios, las privados slo por aquellos a quien le pertenece. Para el cifrado se usa la clave PU y se descifra slo con la clave Pr. Si A desea enviar informacin a B, A cifra con la para y slo quien poses la PrB, es decir el usuario B, podr descifrar. CIFRADO DE CLAVE SIMETRICA Se usa la misma clave para cifrar y para descifrar. Ambos entes se ponen de acuerdo sobre la clave a usar.

En la terminologa de Diameter se usa el trmino mensaje, a pesar de que podra decirse que existen slo dos tipos de mensajes: solicitudes y respuestas. Se prefiere usar el trmino comando, los cuales se distinguen entre s por medio de un command code el cual especifica la funcin que debe realizar el mensaje. A cada comando de REQUEST le corresponde el comando respectivo de ANSWER. La accin a ejecutarse depende del command code y de una serie de atributos incluidos en el mensaje. En total existen 224 command codes, de los cuales del 0 al 255 estn reservados para compatibilidad con RADIUS, y los command codes 16.777.214 y 16.777.215 estn reservados para propsitos de investigacin. El resto es administrado por IANA. A cada pareja de REQUEST/ANSWER le corresponde el mismo Command Code. El Command Code es la accin que se va a ejecutar por ejemplo, Abort-Session-Request abreviado ASR y cuyo Command Code es 274, y el Abort-Session-Answer abreviado ASA tambin tiene un Command Code igual a 274. El Application ID identifica la aplicacin a la cual pertenece dicho mensaje por ejemplo, Application ID=2 para Mobile IP.

Proxiable: Si el bit P es puesto en 1 significa que el mensaje puede ser tratado por un Proxy, retransmitido o redireccionado. Si el bit est en 0 significa que el mensaje debe ser tratado localmente.

Aqu se muestran los Command Codes definidos en el documento base RFC 3588. En el RFC 3589 el IANA asign al 3GPP los commands codes del 300 al 313 para mensajes Diameter definidos en el Release 5 del 3GPP. Los Command Codes se refieren a las diferentes acciones que se deben tomar en una aplicacin Diameter particular. Todas las abreviaciones todas termina en R (Request) o en A (Answer). Todos los comandos de REQUEST tienen el bit R en el flag del header del mensaje DIAMETER puesto a 1 para indicar que es una solicitud, si no es as es porque el mensaje es un respuesta.

Estos command codes fueron asignados por el IANA para ser usados en los mensajes Diameter definidos por el 3GPP en las especificaciones tcnicas respectivas. El caso arriba mostrado es especificamente para la interface S6a entre en MME y el HSS. El 3GPP tiene asignado un Vendor ID, luego solicita un grupo de Command Code para las aplicaciones mencionadas. Se asignaron para el 3GPP los AVP Code del 1400 al 1491. A continuacin se muestran algunos AVPs.

Un Tuple es una notacin para designar una lista ordenada de elementos; 2Tuple: lista de 2 elementos; n-Tuple: una lista de n elementos. En la notacin la lista se encierra entre <> y los elementos se separan por una coma ,. Ejemplos: una 4-Tuple <1,2,3,4>; una 3-Tuple <6,a,?>. El 3-tuple de Radius, tambin se conoce como TLV, por las iniciales de los atributos. TLV es una notacin muy usada en el estndar IEEE 802.16,

Como vemos los AVPs contienen 5 estructuras de datos correspondiendo al 5tuple o Quntupla. Los cdigos AVP del 1 al 255, con el Vendor ID puesto en cero, estn reservados para garantizar compatibilidad con RADIUS. En total pueden existir cerca de 232 AVPs distintos, una cantidad enorme si la comparamos con los 255 de RADIUS. El vendor ID contiene datos si el bit V, en el campo Flags, est en 1. Es un campo opcional de 4 octetos asignado por el IANA para identificar empresas e instituciones del sector que as lo soliciten, cualquiera de estos entes que deseen definir un AVP especfico deben solicitar al IANA el Vendor-ID y los cdigos de los AVPs, de esta forma se garantiza que no habr colisiones. El IANA asign al 3GPP el Vendor ID 10415. El campo AVP Data puede no contener nada o puede transportar los valores de los atributos del Tuple. Los datos en este campo pueden ser de una longitud 224 octetos.

Aqu se muestran algunos cdigos de AVP y los RFCs correspondientes donde se define el AVP en referencia.

Lista de AVPs definidos en el RC4740 para la aplicacin SIP en Diameter

El 3GPP se ha registrado en el IANA, lo que le ha permitido definir ciertas aplicaciones para la red IMS, las cuales corresponden con las interfaces definidas para IMS, estas interfaces definen un aplicacin usando Diameter y por lo tanto tienen un Application ID asignado por IANA a solicitud del 3GPP. De igual forma, todos los dems identificadores han sido definidos por IETF o por otras instituciones como ITU, 3GPP, 3GPP2, ETSI, WiMAX Forum, etc.

La descripcin de cada una de estas entidades se presenta en ETSI TS 123 002 V8.6.0 (2009-10), seccin 4.a7, pp. 37. En total existen 14 entidades y 29 puntos de referencia propios de IMS. Existen otros puntos de referencia relacionados sobre todo con el proceso de realizar los cargos a un usuario.

Aqu se muestran los Application Indentifier para aplicaciones del 3GPP, en particular las de IMS. los Aplication ID fueron asignados al 3GPP por el IANA