1. Introduction

1. Introduction

Les protocoles d'authentification, d'autorisation et de comptabilité (AAA) tels que TACACS [RFC1492] et RADIUS [RFC2865] ont été initialement déployés pour fournir un accès PPP par ligne commutée [RFC1661] et un accès au serveur de terminaux. Au fil du temps, le support AAA était nécessaire sur de nombreuses nouvelles technologies d'accès, l'échelle et la complexité des réseaux AAA ont augmenté, et AAA a également été utilisé pour de nouvelles applications (telles que la voix sur IP). Cela a conduit à de nouvelles exigences pour les protocoles AAA.

Les exigences d'accès réseau pour les protocoles AAA sont résumées dans Aboba, et al. [RFC2989]. Celles-ci comprennent :

Basculement

[RFC2865] ne définit pas de mécanismes de basculement et, par conséquent, le comportement de basculement diffère entre les implémentations. Afin de fournir un comportement de basculement bien défini, Diameter prend en charge les accusés de réception de la couche application et définit les algorithmes de basculement et la machine à états associée.

Sécurité au niveau de la transmission

RADIUS [RFC2865] définit un schéma d'authentification et d'intégrité de la couche application qui n'est requis que pour les paquets de réponse. Bien que [RFC2869] définisse un mécanisme supplémentaire d'authentification et d'intégrité, son utilisation n'est requise que pendant les sessions EAP (Extensible Authentication Protocol) [RFC3748]. Bien que le masquage d'attributs soit pris en charge, [RFC2865] ne fournit pas de support pour la confidentialité par paquet. En comptabilité, [RFC2866] suppose que la protection contre la relecture est fournie par le serveur de facturation backend plutôt que dans le protocole lui-même.

Bien que [RFC3162] définisse l'utilisation d'IPsec avec RADIUS, le support d'IPsec n'est pas requis. Afin de fournir un support universel pour la sécurité au niveau de la transmission et de permettre les déploiements AAA intra et inter-domaines, Diameter fournit un support pour TLS/TCP et DTLS/SCTP. La sécurité est discutée dans la Section 13.

Transport fiable

RADIUS fonctionne sur UDP et ne définit pas le comportement de retransmission ; par conséquent, la fiabilité varie entre les implémentations. Comme décrit dans [RFC2975], il s'agit d'un problème majeur en comptabilité, où la perte de paquets peut se traduire directement en perte de revenus. Afin de fournir un comportement de transport bien défini, Diameter fonctionne sur des mécanismes de transport fiables (TCP, Stream Control Transmission Protocol (SCTP)) comme défini dans [RFC3539].

Support des agents

RADIUS ne fournit pas de support explicite pour les agents, y compris les proxys, les redirections et les relais. Étant donné que le comportement attendu n'est pas défini, il varie entre les implémentations. Diameter définit explicitement le comportement des agents ; ceci est décrit dans la Section 2.8.

Messages initiés par le serveur

Bien que les messages initiés par le serveur soient définis dans RADIUS [RFC5176], leur support est facultatif. Cela rend difficile l'implémentation de fonctionnalités telles que la déconnexion non sollicitée ou la ré-authentification/ré-autorisation à la demande dans un déploiement hétérogène. Pour résoudre ce problème, le support des messages initiés par le serveur est obligatoire dans Diameter.

Support de transition

Bien que Diameter ne partage pas d'unité de données de protocole (PDU) commune avec RADIUS, des efforts considérables ont été déployés pour permettre la rétrocompatibilité avec RADIUS afin que les deux protocoles puissent être déployés dans le même réseau. Initialement, on s'attend à ce que Diameter soit déployé dans de nouveaux périphériques réseau, ainsi que dans des passerelles permettant la communication entre les périphériques RADIUS hérités et les agents Diameter. Cette capacité permet d'ajouter le support Diameter aux réseaux hérités, par l'ajout d'une passerelle ou d'un serveur parlant à la fois RADIUS et Diameter.

En plus de répondre aux exigences ci-dessus, Diameter fournit également un support pour ce qui suit :

Négociation de capacités

RADIUS ne prend pas en charge les messages d'erreur, la négociation de capacités ou un indicateur obligatoire/non obligatoire pour les attributs. Étant donné que les clients et serveurs RADIUS ne sont pas conscients des capacités de l'autre, ils peuvent ne pas être en mesure de négocier avec succès un service mutuellement acceptable ou, dans certains cas, même être conscients du service qui a été implémenté. Diameter inclut le support de la gestion des erreurs (Section 7), de la négociation de capacités (Section 5.3) et des paires attribut-valeur (AVP) obligatoires/non obligatoires (Section 4.1).

Découverte et configuration des pairs

Les implémentations RADIUS nécessitent généralement que le nom ou l'adresse des serveurs ou clients soit configuré manuellement, ainsi que les secrets partagés correspondants. Cela entraîne une charge administrative importante et crée la tentation de réutiliser le secret partagé RADIUS, ce qui peut entraîner des vulnérabilités de sécurité majeures si l'authentificateur de requête n'est pas globalement et temporellement unique comme requis dans [RFC2865]. Via DNS, Diameter permet la découverte dynamique des pairs (voir Section 5.2). La dérivation de clés de session dynamiques est activée via la sécurité au niveau de la transmission.

Au fil du temps, les capacités des périphériques Network Access Server (NAS) ont considérablement augmenté. Par conséquent, bien que Diameter soit un protocole considérablement plus sophistiqué que RADIUS, il reste faisable de l'implémenter dans des appareils embarqués.

1.1. Protocole Diameter

Le protocole de base Diameter fournit les fonctionnalités suivantes :

• Capacité d'échanger des messages et de livrer des AVP
• Négociation de capacités
• Notification d'erreur
• Extensibilité, requise dans [RFC2989], par l'ajout de nouvelles applications, commandes et AVP
• Services de base nécessaires aux applications, tels que la gestion des sessions utilisateur ou la comptabilité

Toutes les données livrées par le protocole sont sous forme d'AVP. Certaines de ces valeurs AVP sont utilisées par le protocole Diameter lui-même, tandis que d'autres livrent des données associées à des applications particulières qui emploient Diameter. Les AVP peuvent être ajoutés arbitrairement aux messages Diameter, la seule restriction étant que la spécification Command Code Format (CCF) (Section 3.2) soit satisfaite. Les AVP sont utilisés par le protocole de base Diameter pour prendre en charge les fonctionnalités requises suivantes :

• Transport des informations d'authentification de l'utilisateur, dans le but de permettre au serveur Diameter d'authentifier l'utilisateur
• Transport des informations d'autorisation spécifiques au service, entre le client et les serveurs, permettant aux pairs de décider si la demande d'accès d'un utilisateur doit être accordée
• Échange d'informations sur l'utilisation des ressources, qui peuvent être utilisées à des fins de comptabilité, de planification de capacité, etc.
• Routage, relais, proxy et redirection des messages Diameter à travers une hiérarchie de serveurs

Le protocole de base Diameter satisfait les exigences minimales pour un protocole AAA, tel que spécifié par [RFC2989]. Le protocole de base peut être utilisé seul à des fins de comptabilité uniquement, ou il peut être utilisé avec une application Diameter, telle que Mobile IPv4 [RFC4004], ou l'accès réseau [RFC4005]. Il est également possible d'étendre le protocole de base pour une utilisation dans de nouvelles applications, via l'ajout de nouvelles commandes ou AVP. L'objectif initial de Diameter était les applications d'accès réseau et de comptabilité. Un protocole AAA véritablement générique utilisé par de nombreuses applications pourrait fournir des fonctionnalités non fournies par Diameter. Par conséquent, il est impératif que les concepteurs de nouvelles applications comprennent leurs exigences avant d'utiliser Diameter. Voir la Section 1.3.4 pour plus d'informations sur les applications Diameter.

Tout nœud peut initier une requête. En ce sens, Diameter est un protocole pair-à-pair. Dans ce document, un client Diameter est un périphérique en périphérie du réseau qui effectue le contrôle d'accès, tel qu'un Network Access Server (NAS) ou un Foreign Agent (FA). Un client Diameter génère des messages Diameter pour demander des services d'authentification, d'autorisation et de comptabilité pour l'utilisateur. Un agent Diameter est un nœud qui ne fournit pas de services locaux d'authentification ou d'autorisation d'utilisateur ; les agents incluent les proxys, les redirections et les agents de relais. Un serveur Diameter effectue l'authentification et/ou l'autorisation de l'utilisateur. Un nœud Diameter peut agir comme un agent pour certaines requêtes tout en agissant comme un serveur pour d'autres.

Le protocole Diameter prend également en charge les messages initiés par le serveur, tels qu'une demande d'arrêt du service à un utilisateur particulier.

1.1.1. Description de l'ensemble de documents

La spécification Diameter se compose d'une version mise à jour de la spécification du protocole de base (ce document) et du profil de transport [RFC3539]. Ce document rend obsolètes RFC 3588 et RFC 5719. Un résumé des mises à jour du protocole de base incluses dans ce document peut être trouvé dans la Section 1.1.3.

Ce document définit la spécification du protocole de base pour AAA, qui inclut le support de la comptabilité. Il existe également une myriade de documents d'application décrivant les applications qui utilisent cette spécification de base pour l'authentification, l'autorisation et la comptabilité. Ces documents d'application spécifient comment utiliser le protocole Diameter dans le contexte de leur application.

Le document de profil de transport [RFC3539] discute des problèmes de couche de transport qui surviennent avec les protocoles AAA et des recommandations sur la façon de surmonter ces problèmes. Ce document définit également l'algorithme de basculement Diameter et la machine à états.

"Clarifications sur le routage des demandes Diameter basées sur le nom d'utilisateur et le domaine" [RFC5729] définit un comportement spécifique sur la façon de router les demandes en fonction du contenu de l'AVP User-Name (paire attribut-valeur).

1.1.2. Conventions utilisées dans ce document

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC2119].

1.1.3. Changements par rapport à RFC 3588

Ce document rend obsolète RFC 3588 mais est entièrement rétrocompatible avec ce document. Les changements introduits dans ce document se concentrent sur la correction des problèmes qui ont fait surface lors de l'implémentation de Diameter (RFC 3588). Un aperçu de certains des principaux changements est donné ci-dessous.

• Dépréciation de l'utilisation de l'AVP Inband-Security pour la négociation de Transport Layer Security (TLS) [RFC5246]. Il a été généralement considéré que l'amorçage de TLS via l'AVP Inband-Security crée certains risques de sécurité car il ne protège pas complètement les informations transportées dans le CER/CEA (Capabilities-Exchange-Request/Capabilities-Exchange-Answer). Cette version de Diameter adopte l'approche commune de définir un port sécurisé bien connu que les pairs devraient utiliser lors de la communication via TLS/TCP et DTLS/SCTP. Cette nouvelle approche augmente la négociation de sécurité en bande existante, mais elle ne la remplace pas complètement. L'ancienne méthode est conservée pour des raisons de rétrocompatibilité.

• Dépréciation de l'échange de messages CER/CEA dans l'état ouvert. Cette fonctionnalité était implicite dans le tableau de la machine à états de pair de RFC 3588, mais elle n'était clairement définie nulle part ailleurs dans ce document. Au fur et à mesure que le travail sur ce document progressait, il est devenu clair que la multiplicité de signification et d'utilisation des AVP Application-Id dans les messages CER/CEA (et les messages eux-mêmes) est considérée comme un abus des règles d'extensibilité de Diameter et a donc nécessité une simplification. L'échange de capacités dans l'état ouvert a été réintroduit dans une spécification séparée [RFC6737], qui définit clairement de nouvelles commandes pour cette fonctionnalité.

• Simplification des exigences de sécurité. L'utilisation d'un transport sécurisé pour l'échange de messages Diameter reste obligatoire. Cependant, TLS/TCP et DTLS/SCTP sont devenus les méthodes principales de sécurisation de Diameter avec IPsec comme alternative secondaire. Voir la Section 13 pour plus de détails. Le support du cadre de sécurité de bout en bout (E2E-Sequence AVP et bit 'P' dans l'en-tête AVP) a également été déprécié.

• Modification de l'extensibilité de Diameter. Cela inclut des correctifs à la description de l'extensibilité de Diameter (Section 1.3 et autres) pour mieux aider les concepteurs d'applications Diameter ; de plus, la nouvelle spécification assouplit la politique concernant l'allocation de codes de commande pour les utilisations spécifiques aux fournisseurs.

• Clarification de l'utilisation de l'ID d'application. Clarifier l'utilisation appropriée des informations d'ID d'application, qui peuvent être trouvées à plusieurs endroits dans un message Diameter. Cela inclut la corrélation des ID d'application trouvés dans les en-têtes de message et les AVP. Ces changements spécifient également clairement la valeur d'ID d'application appropriée à utiliser pour des messages de protocole de base spécifiques (ASR/ASA, STR/STA) ainsi que de clarifier le contenu et l'utilisation de Vendor-Specific-Application-Id.

• Corrections de routage clarifiées. Ce document spécifie plus clairement quelles informations (AVP et ID d'application) peuvent être utilisées pour prendre des décisions de routage générales. Une règle pour la priorisation des critères de routage de redirection lorsque plusieurs entrées de route sont trouvées via des redirections a également été ajoutée (voir Section 6.13).

• Simplification de la découverte des pairs Diameter. Le processus de découverte Diameter ne prend désormais en charge que les schémas de découverte largement utilisés ; le reste a été déprécié (voir Section 5.2 pour plus de détails).

Il existe de nombreuses autres corrections diverses qui ont été introduites dans ce document qui peuvent ne pas être considérées comme significatives, mais elles ont néanmoins de la valeur. Les exemples sont la suppression de types obsolètes, les correctifs à la machine à états, la clarification du processus d'élection, la validation des messages, les correctifs aux valeurs AVP Failed-AVP et Result-Code, etc. Tous les errata déposés contre RFC 3588 avant la publication de ce document ont été traités. Une liste complète des changements n'est pas présentée ici pour des raisons pratiques.

1.2. Terminologie

AAA

Authentification, autorisation et comptabilité.

ABNF

Forme de Backus-Naur augmentée [RFC5234]. Un métalangage avec sa propre syntaxe et règles formelles. Il est basé sur la forme de Backus-Naur et est utilisé pour définir les échanges de messages dans un protocole de communication bidirectionnel.

Comptabilité (Accounting)

L'acte de collecter des informations sur l'utilisation des ressources aux fins de planification de capacité, d'audit, de facturation ou d'allocation de coûts.

Enregistrement de comptabilité (Accounting Record)

Un enregistrement de comptabilité représente un résumé de la consommation de ressources d'un utilisateur sur l'ensemble de la session. Les serveurs de comptabilité créant l'enregistrement de comptabilité peuvent le faire en traitant des événements de comptabilité intermédiaires ou des événements de comptabilité provenant de plusieurs dispositifs desservant le même utilisateur.

Authentification (Authentication)

L'acte de vérifier l'identité d'une entité (sujet).

Autorisation (Authorization)

L'acte de déterminer si une entité demandeuse (sujet) sera autorisée à accéder à une ressource (objet).

Paire attribut-valeur (Attribute-Value Pair, AVP)

Le protocole Diameter se compose d'un en-tête suivi d'une ou plusieurs paires attribut-valeur (AVP). Un AVP comprend un en-tête et est utilisé pour encapsuler des données spécifiques au protocole (par exemple, des informations de routage) ainsi que des informations d'authentification, d'autorisation ou de comptabilité.

Format de code de commande (Command Code Format, CCF)

Une forme modifiée d'ABNF utilisée pour définir les commandes Diameter (voir Section 3.2).

Agent Diameter (Diameter Agent)

Un agent Diameter est un nœud Diameter qui fournit des services de relais, de proxy, de redirection ou de traduction.

Client Diameter (Diameter Client)

Un client Diameter est un nœud Diameter qui prend en charge les applications client Diameter ainsi que le protocole de base. Les clients Diameter sont souvent implémentés dans des dispositifs situés en périphérie d'un réseau et fournissent des services de contrôle d'accès pour ce réseau. Des exemples typiques de clients Diameter incluent le Network Access Server (NAS) et le Mobile IP Foreign Agent (FA).

Nœud Diameter (Diameter Node)

Un nœud Diameter est un processus hôte qui implémente le protocole Diameter et agit en tant que client, agent ou serveur.

Pair Diameter (Diameter Peer)

Deux nœuds Diameter partageant une connexion de transport TCP ou SCTP directe sont appelés pairs Diameter.

Serveur Diameter (Diameter Server)

Un serveur Diameter est un nœud Diameter qui gère les demandes d'authentification, d'autorisation et de comptabilité pour un domaine particulier. De par sa nature même, un serveur Diameter doit prendre en charge les applications serveur Diameter en plus du protocole de base.

Aval (Downstream)

Aval est utilisé pour identifier la direction d'un message Diameter particulier du serveur d'origine vers le client Diameter.

Domaine d'origine (Home Realm)

Un domaine d'origine est le domaine administratif avec lequel l'utilisateur maintient une relation de compte.

Serveur d'origine (Home Server)

Un serveur Diameter qui dessert le domaine d'origine.

Comptabilité intermédiaire (Interim Accounting)

Un message de comptabilité intermédiaire fournit un instantané de l'utilisation pendant la session d'un utilisateur. Typiquement, il est implémenté afin de fournir une comptabilité partielle de la session d'un utilisateur en cas de redémarrage de l'appareil ou d'autre problème réseau empêchant la livraison d'un message de résumé de session ou d'un enregistrement de session.

Domaine local (Local Realm)

Un domaine local est le domaine administratif fournissant des services à un utilisateur. Un domaine administratif peut agir comme un domaine local pour certains utilisateurs tout en étant un domaine d'origine pour d'autres.

Multi-session (Multi-session)

Une multi-session représente une liaison logique de plusieurs sessions. Les multi-sessions sont suivies en utilisant l'Acct-Multi-Session-Id. Un exemple de multi-session serait un bundle PPP multi-lien. Chaque jambe du bundle serait une session tandis que l'ensemble du bundle serait une multi-session.

Identifiant d'accès réseau (Network Access Identifier)

L'identifiant d'accès réseau, ou NAI [RFC4282], est utilisé dans le protocole Diameter pour extraire l'identité et le domaine d'un utilisateur. L'identité est utilisée pour identifier l'utilisateur pendant l'authentification et/ou l'autorisation tandis que le domaine est utilisé à des fins de routage de messages.

Agent proxy ou proxy (Proxy Agent or Proxy)

En plus de transférer les demandes et les réponses, les proxys prennent des décisions politiques relatives à l'utilisation des ressources et au provisionnement. Typiquement, cela est accompli en suivant l'état des dispositifs NAS. Bien que les proxys ne répondent généralement pas aux demandes des clients avant de recevoir une réponse du serveur, ils peuvent émettre des messages de rejet dans les cas où les politiques sont violées. En conséquence, les proxys doivent comprendre la sémantique des messages qui les traversent, et ils peuvent ne pas prendre en charge toutes les applications Diameter.

Domaine (Realm)

La chaîne dans le NAI qui suit immédiatement le caractère '@'. Les noms de domaine NAI doivent être uniques et sont superposés à l'administration de l'espace de noms DNS. Diameter utilise le domaine, également appelé vaguement domaine, pour déterminer si les messages peuvent être satisfaits localement ou s'ils doivent être routés ou redirigés. Dans RADIUS, les noms de domaine ne sont pas nécessairement superposés à l'espace de noms DNS mais peuvent en être indépendants.

Comptabilité en temps réel (Real-Time Accounting)

La comptabilité en temps réel implique le traitement des informations sur l'utilisation des ressources dans une fenêtre de temps définie. Typiquement, des contraintes temporelles sont imposées afin de limiter le risque financier. L'application de contrôle de crédit Diameter [RFC4006] est un exemple d'application qui définit des fonctionnalités de comptabilité en temps réel.

Agent de relais ou relais (Relay Agent or Relay)

Les relais transmettent les demandes et les réponses en fonction des AVP liés au routage et des entrées de table de routage. Étant donné que les relais ne prennent pas de décisions politiques, ils n'examinent ni ne modifient les AVP non liés au routage. En conséquence, les relais ne créent jamais de messages, n'ont pas besoin de comprendre la sémantique des messages ou des AVP non liés au routage, et sont capables de gérer n'importe quelle application ou type de message Diameter. Étant donné que les relais prennent des décisions basées sur les informations dans les AVP de routage et les tables de transfert de domaine, ils ne conservent pas d'état sur l'utilisation des ressources NAS ou les sessions en cours.

Agent de redirection (Redirect Agent)

Plutôt que de transférer les demandes et les réponses entre les clients et les serveurs, les agents de redirection réfèrent les clients aux serveurs et leur permettent de communiquer directement. Étant donné que les agents de redirection ne se trouvent pas dans le chemin de transfert, ils ne modifient aucun AVP transitant entre le client et le serveur. Les agents de redirection ne créent pas de messages et sont capables de gérer n'importe quel type de message, bien qu'ils puissent être configurés uniquement pour rediriger les messages de certains types, tout en agissant comme des agents de relais ou de proxy pour d'autres types. Comme avec les agents de relais, les agents de redirection ne conservent pas d'état par rapport aux sessions ou aux ressources NAS.

Session (Session)

Une session est une progression liée d'événements consacrés à une activité particulière. Les documents d'application Diameter fournissent des directives sur le moment où une session commence et se termine. Tous les paquets Diameter avec le même Session-Id sont considérés comme faisant partie de la même session.

Agent avec état (Stateful Agent)

Un agent avec état est un agent qui maintient des informations d'état de session, en gardant une 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 soit jusqu'à ce qu'il soit notifié autrement, soit jusqu'à expiration.

Sous-session (Sub-session)

Une sous-session représente un service distinct (par exemple, QoS ou caractéristiques de données) fourni à une session donnée. Ces services peuvent se produire simultanément (par exemple, transfert simultané de voix et de données pendant la même session) ou en série. Ces changements dans les sessions sont suivis avec l'Accounting-Sub-Session-Id.

État de transaction (Transaction State)

Le protocole Diameter exige que les agents maintiennent l'état de transaction, qui est utilisé à des fins de basculement. L'état de transaction implique qu'au moment de transférer une demande, l'identificateur Hop-by-Hop est sauvegardé ; le champ est remplacé par un identificateur 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é à la réception de la réponse. Un agent sans état est un agent qui ne maintient que l'état de transaction.

Agent de traduction (Translation Agent)

Un agent de traduction (TLA dans la figure 4) est un nœud Diameter avec état qui effectue la traduction de protocole entre Diameter et un autre protocole AAA, tel que RADIUS.

Amont (Upstream)

Amont est utilisé pour identifier la direction d'un message Diameter particulier du client Diameter vers le serveur d'origine.

Utilisateur (User)

L'entité ou le dispositif demandant ou utilisant une ressource, à l'appui de laquelle un client Diameter a généré une demande.

1.3. Approche de l'extensibilité

Le protocole Diameter est conçu pour être extensible, en utilisant plusieurs mécanismes, notamment :

• Définition de nouvelles valeurs AVP
• Création de nouveaux AVP
• Création de nouvelles commandes
• Création de nouvelles applications

Du point de vue de l'extensibilité, les applications d'authentification, d'autorisation et de comptabilité Diameter sont traitées de la même manière.

Remarque : Les concepteurs de protocoles devraient essayer de réutiliser les fonctionnalités existantes, à savoir les valeurs AVP, les AVP, les commandes et les applications Diameter. La réutilisation simplifie la normalisation et l'implémentation. Pour éviter les problèmes potentiels d'interopérabilité, il est important de s'assurer que la sémantique des fonctionnalités réutilisées est bien comprise. Étant donné que Diameter peut également transporter des attributs RADIUS en tant qu'AVP Diameter, de telles considérations de réutilisation s'appliquent également aux attributs RADIUS existants qui peuvent être utiles dans une application Diameter.

1.3.1. Définition de nouvelles valeurs AVP

Afin d'allouer une nouvelle valeur AVP pour les AVP définis dans le protocole de base Diameter, l'IETF doit approuver un nouveau RFC qui décrit la valeur AVP. Les considérations IANA pour ces valeurs AVP sont discutées dans la Section 11.3.

L'allocation de valeurs AVP pour d'autres AVP est guidée par les considérations IANA du document qui définit ces AVP. Typiquement, l'allocation de nouvelles valeurs pour un AVP défini dans un RFC nécessiterait une revue IETF [RFC5226], tandis que les valeurs pour les AVP spécifiques au fournisseur peuvent être allouées par le fournisseur.

1.3.2. Création de nouveaux AVP

Un nouvel AVP en cours de définition DOIT utiliser l'un des types de données répertoriés dans les Sections 4.2 ou 4.3. Si un type de données dérivé approprié est déjà défini, il DEVRAIT être utilisé à la place d'un type de données de base pour encourager la réutilisabilité et les bonnes pratiques de conception.

Dans le cas où un regroupement logique d'AVP est nécessaire, et que plusieurs "groupes" sont possibles dans une commande donnée, il est recommandé d'utiliser un AVP groupé (voir Section 4.4).

La création de nouveaux AVP peut se faire de diverses manières. L'approche recommandée consiste à définir un nouvel AVP à usage général dans un RFC de piste de normalisation approuvé par l'IETF. Cependant, comme décrit dans la Section 11.1.1, il existe d'autres mécanismes.

1.3.3. Création de nouvelles commandes

Un nouveau code de commande DOIT être alloué lorsque des AVP requis (ceux indiqués comme {AVP} dans la définition CCF) sont ajoutés à, supprimés de ou redéfinis dans (par exemple, en changeant un AVP requis en un AVP optionnel) une commande existante.

De plus, si les caractéristiques de transport d'une commande sont modifiées (par exemple, en ce qui concerne le nombre d'allers-retours requis), un nouveau code de commande DOIT être enregistré.

Un changement au CCF d'une commande, tel que décrit ci-dessus, DOIT entraîner la définition d'un nouveau code de commande. Cela conduit ensuite à la nécessité de définir une nouvelle application Diameter pour toute application qui utilisera cette nouvelle commande.

Les considérations IANA pour les codes de commande sont discutées dans la Section 3.1.

1.3.4. Création de nouvelles applications Diameter

Les applications Diameter peuvent définir de nouveaux codes de commande, AVP et sémantiques associées. La création de nouvelles applications Diameter nécessite généralement un RFC de piste de normalisation approuvé par l'IETF. Voir la Section 11.2.1 pour plus de détails.