2. Aperçu du protocole

Le protocole Diameter de base se préoccupe de l'établissement des connexions avec les pairs, de la négociation des capacités, de la manière dont les messages sont envoyés et routés via les pairs, et de la manière dont les connexions sont finalement rompues. Le protocole de base définit également certaines règles qui s'appliquent à tous les échanges de messages entre les nœuds Diameter.

La communication entre les pairs Diameter commence par un pair envoyant un message à un autre pair Diameter. L'ensemble des AVP inclus dans le message est déterminé par une application Diameter particulière. Un AVP qui est inclus pour référencer la session d'un utilisateur est le Session-Id.

La demande initiale d'authentification et/ou d'autorisation d'un utilisateur inclurait l'AVP Session-Id. Le Session-Id est ensuite utilisé dans tous les messages suivants pour identifier la session de l'utilisateur (voir la section 8 pour plus d'informations). La partie communicante peut accepter la demande ou la rejeter en retournant un message de réponse avec l'AVP Result-Code défini pour indiquer qu'une erreur s'est produite. Le comportement spécifique du serveur ou du client Diameter recevant une demande dépend de l'application Diameter employée.

L'état de session (associé à un Session-Id) DOIT être libéré lors de la réception du Session-Termination-Request, du Session-Termination-Answer, de l'expiration du temps de service autorisé dans l'AVP Session-Timeout, et selon les règles établies dans une application Diameter particulière.

Le protocole Diameter de base peut être utilisé seul pour les applications de comptabilité. Pour l'authentification et l'autorisation, il est toujours étendu pour une application particulière.

Les clients Diameter DOIVENT prendre en charge le protocole de base, qui inclut la comptabilité. De plus, ils DOIVENT prendre en charge entièrement chaque application Diameter nécessaire pour implémenter le service du client, par exemple, Network Access Server Requirements (NASREQ) [RFC2881] et/ou Mobile IPv4. Un client Diameter DOIT être appelé "Client Diameter X" où X est l'application qu'il prend en charge et non un "Client Diameter".

Les serveurs Diameter DOIVENT prendre en charge le protocole de base, qui inclut la comptabilité. De plus, ils DOIVENT prendre en charge entièrement chaque application Diameter nécessaire pour implémenter le service prévu, par exemple, NASREQ et/ou Mobile IPv4. Un serveur Diameter DOIT être appelé "Serveur Diameter X" où X est l'application qu'il prend en charge, et non un "Serveur Diameter".

Les relais et agents de redirection Diameter sont transparents pour les applications Diameter, mais ils DOIVENT prendre en charge le protocole de base Diameter, qui inclut la comptabilité, et toutes les applications Diameter.

Les proxies Diameter DOIVENT prendre en charge le protocole de base, qui inclut la comptabilité. De plus, ils DOIVENT prendre en charge entièrement chaque application Diameter nécessaire pour implémenter les services proxifiés, par exemple, NASREQ et/ou Mobile IPv4. Un proxy Diameter DOIT être appelé "Proxy Diameter X" où X est l'application qu'il prend en charge, et non un "Proxy Diameter".

2.1. Transport

Le profil de transport Diameter est défini dans [RFC3539].

Le protocole Diameter de base s'exécute sur le port 3868 pour TCP [RFC0793] et SCTP [RFC4960]. Pour TLS [RFC5246] et Datagram Transport Layer Security (DTLS) [RFC6347], un nœud Diameter qui initie une connexion avant tout échange de messages DOIT s'exécuter sur le port 5658. On suppose que TLS s'exécute sur TCP lorsqu'il est utilisé, et que DTLS s'exécute sur SCTP lorsqu'il est utilisé.

Si le pair Diameter ne prend pas en charge la réception de connexions TLS/TCP et DTLS/SCTP sur le port 5658 (c'est-à-dire que le pair ne se conforme qu'à RFC 3588), l'initiateur PEUT revenir à l'utilisation de TCP ou SCTP sur le port 3868. Notez que ce schéma n'est conservé qu'à des fins de rétrocompatibilité et qu'il existe des vulnérabilités de sécurité inhérentes lorsque les messages CER/CEA initiaux sont envoyés non protégés (voir la section 5.6).

Les clients Diameter DOIVENT prendre en charge TCP ou SCTP ; les agents et serveurs DEVRAIENT prendre en charge les deux.

Un nœud Diameter PEUT initier des connexions à partir d'un port source autre que celui qu'il déclare accepter les connexions entrantes, et il DOIT toujours être prêt à recevoir des connexions sur le port 3868 pour TCP ou SCTP et le port 5658 pour les connexions TLS/TCP et DTLS/SCTP. Lorsque la découverte de pairs basée sur DNS (section 5.2) est utilisée, les numéros de port reçus des enregistrements SRV ont la priorité sur les ports par défaut (3868 et 5658).

Une instance donnée de la machine d'état de pair Diameter NE DOIT PAS utiliser plus d'une connexion de transport pour communiquer avec un pair donné, sauf si plusieurs instances existent sur le pair, auquel cas une connexion séparée par processus est autorisée.

Lorsqu'aucune connexion de transport n'existe avec un pair, une tentative de connexion DEVRAIT être effectuée périodiquement. Ce comportement est géré via le temporisateur Tc (voir la section 12 pour plus de détails), dont la valeur recommandée est de 30 secondes. Il existe certaines exceptions à cette règle, par exemple lorsqu'un pair a terminé la connexion de transport en indiquant qu'il ne souhaite pas communiquer.

Lors de la connexion à un pair et lorsque zéro ou plusieurs transports sont spécifiés, TLS DEVRAIT être essayé en premier, suivi de DTLS, puis de TCP, et enfin de SCTP. Voir la section 5.2 pour plus d'informations sur la découverte de pairs.

Les implémentations Diameter DEVRAIENT être capables d'interpréter les messages ICMP de port inaccessible du protocole comme des indications explicites que le serveur n'est pas accessible, sous réserve de la politique de sécurité concernant la confiance dans de tels messages. Des conseils supplémentaires concernant le traitement des erreurs ICMP peuvent être trouvés dans [RFC5927] et [RFC5461]. Les implémentations Diameter DEVRAIENT également être capables d'interpréter une réinitialisation du transport et des tentatives de connexion expirées. Si Diameter reçoit des données de la couche inférieure qui ne peuvent pas être analysées ou identifiées comme une erreur Diameter faite par le pair, le flux est compromis et ne peut pas être récupéré. La connexion de transport DOIT être fermée à l'aide d'un appel RESET (envoyer un bit TCP RST) ou d'un message SCTP ABORT (la fermeture gracieuse est compromise).

2.1.1. Directives SCTP

Les messages Diameter DEVRAIENT être mappés dans les flux SCTP d'une manière qui évite le blocage de tête de ligne (HOL). Parmi les différentes façons d'effectuer le mappage qui répondent à cette exigence, il est RECOMMANDÉ qu'un nœud Diameter envoie chaque message Diameter (demande ou réponse) sur le flux zéro avec l'indicateur non ordonné défini. Cependant, les nœuds Diameter PEUVENT sélectionner et mettre en œuvre d'autres alternatives de conception pour éviter le blocage HOL, telles que l'utilisation de plusieurs flux avec l'indicateur non ordonné effacé (comme indiqué à l'origine dans RFC 3588). Du côté récepteur, une entité Diameter DOIT être prête à recevoir des messages Diameter sur n'importe quel flux, et elle est libre de renvoyer des réponses sur un flux différent. De cette façon, les deux côtés gèrent les flux disponibles dans la direction d'envoi, indépendamment des flux choisis par l'autre côté pour envoyer un message Diameter particulier. Ces messages peuvent être hors ordre et appartenir à différentes sessions Diameter.

La livraison hors ordre a des préoccupations particulières lors de l'établissement et de la terminaison d'une connexion. Lorsqu'une connexion est établie, le côté répondeur envoie un message CEA et passe à l'état R-Open comme spécifié dans la section 5.6. Si un message d'application est envoyé peu après le CEA et livré hors ordre, le côté initiateur, toujours dans l'état Wait-I-CEA, rejettera le message d'application et fermera la connexion. Afin d'éviter cette condition de course, le côté récepteur NE DEVRAIT PAS utiliser les méthodes de livraison hors ordre jusqu'à ce que le premier message ait été reçu de l'initiateur, prouvant qu'il est passé à l'état I-Open. Pour déclencher un tel message, le côté récepteur pourrait envoyer un DWR immédiatement après l'envoi d'un CEA. Lors de la réception du DWA correspondant, le côté récepteur devrait commencer à utiliser les méthodes de livraison hors ordre pour contrer le blocage HOL.

Une autre condition de course peut se produire lorsque les messages DPR et DPA sont utilisés. DPR et DPA sont tous deux de petite taille ; ainsi, ils peuvent être livrés au pair plus rapidement que les messages d'application lorsqu'un mécanisme de livraison hors ordre est utilisé. Par conséquent, il est possible qu'un échange DPR/DPA se termine alors que des messages d'application sont toujours en transit, entraînant une perte de ces messages. Une implémentation pourrait atténuer cette condition de course, par exemple, en utilisant des temporisateurs et en attendant une courte période pour que les messages de niveau application en attente arrivent avant de procéder à la déconnexion de la connexion de transport. Finalement, les messages perdus sont gérés par le mécanisme de retransmission décrit dans la section 5.5.4.

Un agent Diameter DEVRAIT utiliser des identifiants de protocole de charge utile dédiés (PPID) pour les morceaux SCTP DATA en texte clair et cryptés au lieu d'utiliser uniquement l'identifiant de protocole de charge utile non spécifié (valeur 0). À cette fin, deux valeurs PPID sont allouées : la valeur PPID 46 est pour les messages Diameter dans les morceaux SCTP DATA en texte clair, et la valeur PPID 47 est pour les messages Diameter dans les morceaux DTLS/SCTP DATA protégés.

2.2. Sécurisation des messages Diameter

Les connexions entre les pairs Diameter DEVRAIENT être protégées par TLS/TCP et DTLS/SCTP. Toutes les implémentations du protocole de base Diameter DOIVENT prendre en charge l'utilisation de TLS/TCP et DTLS/SCTP. Si désiré, des mécanismes de sécurité alternatifs indépendants de Diameter, tels qu'IPsec [RFC4301], peuvent être déployés pour sécuriser les connexions entre pairs. Le protocole Diameter NE DOIT PAS être utilisé sans l'un de TLS, DTLS ou IPsec.

2.3. Conformité des applications Diameter

Les identifiants d'application sont annoncés pendant la phase d'échange de capacités (voir la section 5.3). Annoncer la prise en charge d'une application implique que l'expéditeur prend en charge les fonctionnalités spécifiées dans la spécification d'application Diameter respective.

Les implémentations PEUVENT ajouter des AVP optionnels arbitraires avec le bit M effacé (y compris les AVP spécifiques au fournisseur) à une commande définie dans une application, mais seulement si la spécification de syntaxe CCF de la commande le permet. Veuillez vous référer à la section 11.1.1 pour plus de détails.

2.4. Identifiants d'application

Chaque application Diameter DOIT avoir un identifiant d'application attribué par l'IANA. Le protocole de base ne nécessite pas d'identifiant d'application car sa prise en charge est obligatoire. Lors de l'échange de capacités, les nœuds Diameter informent leurs pairs des applications prises en charge localement. De plus, tous les messages Diameter contiennent un identifiant d'application, qui est utilisé dans le processus de transfert de messages.

Les valeurs d'identifiant d'application suivantes sont définies :

Diameter common message       0
Diameter base accounting      3
Relay                         0xffffffff

Les relais et agents de redirection DOIVENT annoncer l'identifiant d'application de relais, tandis que tous les autres nœuds Diameter DOIVENT annoncer les applications prises en charge localement. Le destinataire d'un message d'échange de capacités annonçant le service de relais DOIT supposer que l'expéditeur prend en charge toutes les applications actuelles et futures.

Les relais et agents proxy Diameter sont responsables de trouver un serveur en amont qui prend en charge l'application d'un message particulier. Si aucun ne peut être trouvé, un message d'erreur est renvoyé avec l'AVP Result-Code défini sur DIAMETER_UNABLE_TO_DELIVER.

2.5. Connexions vs Sessions

Cette section tente de fournir au lecteur une compréhension de la différence entre "connexion" et "session", qui sont des termes utilisés de manière extensive dans ce document.

Une connexion fait référence à une connexion au niveau du transport entre deux pairs qui est utilisée pour envoyer et recevoir des messages Diameter. Une session est un concept logique au niveau de la couche application qui existe entre le client Diameter et le serveur Diameter ; elle est identifiée via l'AVP Session-Id.

          +--------+          +-------+          +--------+
          | Client |          | Relay |          | Server |
          +--------+          +-------+          +--------+
                   <---------->       <---------->
                connexion pair A   connexion pair B

                   <----------------------------->
                         Session utilisateur x

             Figure 1 : Connexions et sessions Diameter

Dans l'exemple fourni dans la figure 1, la connexion pair A est établie entre le client et le relais. La connexion pair B est établie entre le relais et le serveur. La session utilisateur X s'étend du client via le relais au serveur. Chaque "utilisateur" d'un service provoque l'envoi d'une demande d'authentification, avec un identifiant de session unique. Une fois accepté par le serveur, le client et le serveur sont tous deux conscients de la session.

Il est important de noter qu'il n'y a pas de relation entre une connexion et une session, et que les messages Diameter pour plusieurs sessions sont tous multiplexés via une seule connexion. Notez également que les messages Diameter relatifs à la session, à la fois spécifiques à l'application et ceux définis dans ce document tels que ASR/ASA, RAR/RAA et STR/STA, DOIVENT porter l'identifiant d'application de l'application. Les messages Diameter relatifs à l'établissement et à la maintenance de la connexion pair tels que CER/CEA, DWR/DWA et DPR/DPA DOIVENT porter un identifiant d'application de zéro (0).

2.6. Table des pairs

La table des pairs Diameter est utilisée dans le transfert de messages et est référencée par la table de routage. Une entrée de table de pairs contient les champs suivants :

Identité d'hôte

Suivant les conventions décrites pour le format de données AVP dérivé de DiameterIdentity dans la section 4.3.1, ce champ contient le contenu de l'AVP Origin-Host (section 6.3) trouvé dans le message CER ou CEA.

StatusT

Il s'agit de l'état de l'entrée de pair, et il DOIT correspondre à l'une des valeurs listées dans la section 5.6.

Statique ou dynamique

Spécifie si une entrée de pair a été configurée de manière statique ou découverte de manière dynamique.

Temps d'expiration

Spécifie le moment auquel les entrées de table de pairs découvertes dynamiquement doivent être soit rafraîchies, soit expirées. Si des certificats de clé publique sont utilisés pour la sécurité Diameter (par exemple, avec TLS), cette valeur NE DOIT PAS être supérieure aux temps d'expiration dans les certificats pertinents.

TLS/TCP et DTLS/SCTP activés

Spécifie si TLS/TCP et DTLS/SCTP doivent être utilisés lors de la communication avec le pair.

Informations de sécurité supplémentaires, si nécessaire (par exemple, clés, certificats).

2.7. Table de routage

Toutes les recherches de routage basées sur le domaine sont effectuées par rapport à ce qui est communément appelé la table de routage (voir la section 12). Chaque entrée de table de routage contient les champs suivants :

Nom du domaine

Il s'agit du champ qui DOIT être utilisé comme clé primaire dans les recherches de table de routage. Notez que certaines implémentations effectuent leurs recherches en fonction de la correspondance la plus longue à partir de la droite sur le domaine plutôt que d'exiger une correspondance exacte.

Identifiant d'application

Une application est identifiée par un identifiant d'application. Une entrée de route peut avoir une destination différente en fonction de l'identifiant d'application dans l'en-tête du message. Ce champ DOIT être utilisé comme champ de clé secondaire dans les recherches de table de routage.

Action locale

Le champ Action locale est utilisé pour identifier comment un message doit être traité. Les actions suivantes sont prises en charge :

LOCAL - Messages Diameter qui peuvent être satisfaits localement et n'ont pas besoin d'être routés vers une autre entité Diameter.
RELAY - Tous les messages Diameter qui entrent dans cette catégorie DOIVENT être routés vers une entité Diameter de prochain saut indiquée par l'identifiant décrit ci-dessous. Le routage se fait sans modifier aucun AVP non routant. Voir la section 6.1.9 pour les directives de relais.
PROXY - Tous les messages Diameter qui entrent dans cette catégorie DOIVENT être routés vers une entité Diameter suivante indiquée par l'identifiant décrit ci-dessous. Le serveur local PEUT appliquer ses politiques locales au message en incluant de nouveaux AVP au message avant le routage. Voir la section 6.1.9 pour les directives de proxy.
REDIRECT - Les messages Diameter qui entrent dans cette catégorie DOIVENT avoir l'identité du ou des serveurs Diameter principaux ajoutée et renvoyée à l'expéditeur du message. Voir la section 6.1.8 pour les directives de redirection.

Identifiant du serveur

L'identité d'un ou plusieurs serveurs auxquels le message doit être routé. Cette identité DOIT également être présente dans le champ Identité d'hôte de la table des pairs (section 2.6). Lorsque l'action locale est définie sur RELAY ou PROXY, ce champ contient l'identité du ou des serveurs auxquels le message DOIT être routé. Lorsque le champ Action locale est défini sur REDIRECT, ce champ contient l'identité d'un ou plusieurs serveurs vers lesquels le message DOIT être redirigé.

Statique ou dynamique

Spécifie si une entrée de route a été configurée de manière statique ou découverte de manière dynamique.

Temps d'expiration

Spécifie le moment auquel une entrée de table de route découverte dynamiquement expire. Si des certificats de clé publique sont utilisés pour la sécurité Diameter (par exemple, avec TLS), cette valeur NE DOIT PAS être supérieure au temps d'expiration dans les certificats pertinents.

Il est important de noter que les agents Diameter DOIVENT prendre en charge au moins l'un des modes de fonctionnement LOCAL, RELAY, PROXY ou REDIRECT. Les agents n'ont pas besoin de prendre en charge tous les modes de fonctionnement pour se conformer à la spécification du protocole, mais ils DOIVENT suivre les directives de conformité du protocole de la section 2. Les agents de relais et les proxies NE DOIVENT PAS réorganiser les AVP.

La table de routage PEUT inclure une entrée par défaut qui DOIT être utilisée pour toutes les demandes ne correspondant à aucune des autres entrées. La table de routage PEUT être constituée uniquement d'une telle entrée.

Lorsqu'une demande est routée, le serveur cible DOIT avoir annoncé l'identifiant d'application (voir la section 2.4) pour le message donné ou s'être annoncé comme agent de relais ou proxy. Sinon, une erreur est renvoyée avec l'AVP Result-Code défini sur DIAMETER_UNABLE_TO_DELIVER.

2.8. Rôle des agents Diameter

En plus des clients et serveurs, le protocole Diameter introduit des agents de relais, proxy, redirection et traduction, chacun étant défini dans la section 1.2. Les agents Diameter sont utiles pour plusieurs raisons :

Ils peuvent distribuer l'administration des systèmes à un groupement configurable, y compris la maintenance des associations de sécurité.
Ils peuvent être utilisés pour la concentration des demandes provenant d'un certain nombre d'ensembles d'équipements NAS colocalisés ou distribués vers un ensemble de groupes d'utilisateurs similaires.
Ils peuvent effectuer un traitement à valeur ajoutée sur les demandes ou les réponses.
Ils peuvent être utilisés pour l'équilibrage de charge.
Un réseau complexe aura plusieurs sources d'authentification, ils peuvent trier les demandes et les transférer vers la cible correcte.

Le protocole Diameter exige que les agents maintiennent l'état de transaction, qui est utilisé à des fins de basculement. L'état de transaction implique que lors du transfert d'une demande, son identifiant Hop-by-Hop est enregistré ; le champ est remplacé par un identifiant localement unique, qui est restauré à sa valeur d'origine lorsque la réponse correspondante est reçue. L'état de la demande est libéré lors de la réception de la réponse. Un agent sans état est celui qui ne maintient que l'état de transaction.

L'AVP Proxy-Info permet aux agents sans état d'ajouter un état local à une demande Diameter, avec la garantie que le même état sera présent dans la réponse. Cependant, les procédures de basculement du protocole exigent que les agents maintiennent une copie des demandes en attente.

Un agent avec état est celui qui maintient les informations d'état de session en gardant trace de toutes les sessions actives autorisées. Chaque session autorisée est liée à un service particulier, et son état est considéré comme actif jusqu'à ce que l'agent soit informé du contraire ou que la session expire. Chaque session autorisée a une expiration, qui est communiquée par les serveurs Diameter via l'AVP Session-Timeout.

Le maintien de l'état de session peut être utile dans certaines applications, telles que :

Traduction de protocole (par exemple, RADIUS <-> Diameter)
Limitation des ressources autorisées à un utilisateur particulier
Audit par utilisateur ou par transaction

Un agent Diameter PEUT agir de manière avec état pour certaines demandes et être sans état pour d'autres. Une implémentation Diameter PEUT agir comme un type d'agent pour certaines demandes et comme un autre type d'agent pour d'autres.

2.8.1. Agents de relais

Les agents de relais sont des agents Diameter qui acceptent les demandes et routent les messages vers d'autres nœuds Diameter en fonction des informations trouvées dans les messages (par exemple, la valeur de l'AVP Destination-Realm section 6.6). Cette décision de routage est effectuée à l'aide d'une liste de domaines pris en charge et de pairs connus. C'est ce qu'on appelle la table de routage, comme défini plus en détail dans la section 2.7.

Les relais peuvent, par exemple, être utilisés pour agréger les demandes provenant de plusieurs serveurs d'accès réseau (NAS) dans une zone géographique commune (Point de présence, POP). L'utilisation de relais est avantageuse car elle élimine le besoin pour les NAS d'être configurés avec les informations de sécurité nécessaires qu'ils auraient autrement besoin pour communiquer avec les serveurs Diameter dans d'autres domaines. De même, cela réduit la charge de configuration sur les serveurs Diameter qui serait autrement nécessaire lorsque des NAS sont ajoutés, modifiés ou supprimés.