Diameter

Principes de fonctionnement

Diameter Base

Diameter est composé d'un protocole de Base auquel une extension dite "Application" doit être ajoutée.

Diameter Base fournit des mécanismes pour :

• Un transport fiable


• Le traitement d'erreurs


• L'accounting


• La négociation des capabilities

Diameter Base ne fournit pas les messages nécessaire à l'authentification et l'autorisation. Ils sont propres à chaque application.

Diameter Applications

Une application Diameter n'a rien à voir avec le sens "logiciel" du terme. Il s'agit d'un protocole reposant sur Diameter Base. Une application définit un ensemble de commandes (requêtes et réponses) et de paires Attribut-Valeur (AVP) pour permettre l'authentification et l'autorisation dans un contexte donné. Les applications sont décrites dans des RFC et des spécifications 3GPP. Ci-dessous, quelques applications standardisées par l'IETF :

• RFC 4004 Diameter Mobile IPv4 Application (rfc4004)


• Diameter Network Access Server Application(rfc4005)


• Diameter Extensible Authentication Protocol (EAP) Application (rfc6733)


• Diameter Session Initiation Protocol (SIP) Application (rfc4740)

Format des messages

Le format d'un message Diameter est le suivant :


© http://www.ibm.com/developerworks/library/wi-diameter/index.html

Explication des champs :


Length :
Contient la taille du message (entete + payload)


Flags :
Les flags sont :

    'R'
   Permet d'indiquer si le message est une requête ou une réponse.

    'P'
   Permet d'indiquer si le message peut être transféré ou non.

    'E'
   Permet d'indiquer si le message contient une erreur (valable uniquement pour les réponses).

    'T'
   Permet d'indiquer si le message est un message retransmis.


Command Code :
Code pour identifier chaque type de requête de manière unique. La réponse à la requête possède le même code. Cependant, son bit 'R' permet de la différencer de la requête.


Application-ID :
Chaque Application Diameter possède un identifiant unique. Ce champ permet donc d'identifier l'application concernée par le message. S'il s'agit d'un message défini dans Diameter Base alors cet ID est '0'.


Hop-by-Hop identifier :
Une architecture Diameter peut être composée d'un client, d'un serveur et de plusieurs noeuds Diameter intermédiaires (cf. Diameter Agents). Chaque message possède donc un identifiant de saut-par-saut, autrement dit, modifié par chaque noeud traversé par le message.


End-to-End identifier :
Identifiant de bout en bout d'un message. La réponse à une requête possède le même identifiant que cette requête. Ainsi, un client peut détecter la réponse à une requête qu'il a émis.


La payload est constituée d'un ensemble de paires attributs-valeur (AVP). .

Agents Diameter

Une architecture Diameter est composée de différents noeuds dits "Diameter agents". Chaque agent a un rôle bien défini dans les spécifications du protocole. Tous les agents peuvent initiés des requêtes. Dans ce sens, ils forment un réseau de peer-to-peer. Les quatres types d'agents existants sont :

• L'agent relais


• L'agent Proxy


• L'agent de redirection


• L'agent de translation

L'agent Proxy


© http://www.ibm.com/developerworks/library/wi-diameter/index.html

Le rôle de cet agent est de router les messages vers la bonne destination en fonction des informations contenues dans celui-ci telles que l'id de l'application ou l'AVP "Destination-Realm". Typiquement, le Proxy est placé entre le client Diameter et plusieurs serveurs de différentes applications. Ainsi, en fonction de l'application cible d'une requête émise par le client, le proxy pourra transmettre celle-ci vers le bon serveur. On évite ainsi de configurer le client pour qu'il prenne en compte chaque serveur. De plus, le proxy peut modifier les messages en ajoutant des AVPs. Dans ce cadre, il peut par exemple modifier le contrôle d'accès à certaines ressources pour un domaine donné.

L'agent Relais

Le rôle d'un relais est le même qu'un proxy à la différence qu'il ne peut pas modifier les messages.

L'agent de redirection


© http://www.ibm.com/developerworks/library/wi-diameter/index.html

L'agent de redirection centralise les informations de routages. Il peut être interrogé par n'importe quel noeud ne sachant pas où transmettre un message. L'agent de redirection répond alors avec les informations de redirection. L'utilisation de cet agent permet d'alléger les configurations locales aux noeuds qui n'ont plus besoin de conserver les informations de routage localement.

L'agent de translation


© http://www.ibm.com/developerworks/library/wi-diameter/index.html

L'agent de translation permet l'interopérabilité de Diameter avec d'autres protocoles AAA. Prenons l'exemple de RADIUS. L'agent de translation change les messages RADIUS en leur equivalent Diameter (s'il existe). L'intérêt peut être d'assurer une migration en douceur vers Diameter, en conservant des clients et serveurs RADIUS pendant la phase de transition.

Découverte dynamique des peers

La découverte dynamique des voisins permet à un client Diameter de découvrir le premier saut avec lequel communiquer et à un agent de découvrir le prochain agent auquel transférer un message donné. Elle peut se faire via les protocoles SERVLOC ou DNS.

Chaque noeud Diameter maintient deux tables : une table des peers et une table de routage. La première contient l'ensembles des voisins et fournit diverses informations sur ceux-ci. En particulier, le status de la communication. En effet, Diameter offre la possibilité d'établir des sessions entre deux noeuds. Dans ce cadre, la table des peers indique l'état de la connexion avec les voisins.

Ci-dessous, une architecture Diameter constituée de différents agents avec la table des peers du noeud client A :

Table des peers du noeud A

Identité du noeud	Status	decouverte statique ou dynamique	Temps avant expiration (en secondes)	TLS activé
NoeudB.domaine1.com	Idle	Dynamique	600	FAUX
Nœud_E.domaine1.com	Open	Statique	-	FAUX
Nœud_I.domaine1.com	Pending	Statique	-	FAUX
Nœud_F.domaine2.com	Open	Statique	-	VRAI

Les information contenues dans la table des peers pour un voisin donné sont : son nom, le status de la connexion avec celui ci (Open si une session est en cours, Pending si elle est en cours d'établissement ou Idle si aucune session n'est établie), la façon dont il a été découvert (configuré statiquement ou découvert dynamiquement), un timestamp dans le cas d'une session dynamique (temps avant expiration de l'entrée) et la possibilité ou non de chiffrer les échanges avec ce voisin via TLS.

Quant à la table de routage, elle permet de savoir où router un message pour qu'il soit traité par un serveur ad-hoc. Autrement dit, un serveur traitant l'application concernée par le message.

Gestion des erreurs

Diameter implémente nativement des mécanismes de gestion d'erreurs. Ainsi, si deux noeuds adjacents ne communiquent pas pendant un certain temps, ils initient périodiquement des requêtes/réponses "watchdog" pour s'assurer de la bonne connectivité. Cela permet de détecter d'éventuelles ruptures de lien. Typiquement, si un noeud envoie une requête watchdog à un voisin sans obtenir de réponse, il retransmet ce message à un noeud alternatif dans la mesure du possible. Le schéma ci-dessous illustre ce scénario :

On voit ici l'un des intérêts des identifiants de message hope-by-hope. En effet, le mécanisme de failover ne nécessite pas la retransmission du message par le client mais uniquement depuis le noeud ayant détecté la rupture de connectivité.