1. Introduzione

1. Introduzione

I protocolli di autenticazione, autorizzazione e accounting (AAA) come TACACS [RFC1492] e RADIUS [RFC2865] sono stati inizialmente distribuiti per fornire accesso PPP dial-up [RFC1661] e accesso al server terminale. Nel tempo, il supporto AAA è stato necessario su molte nuove tecnologie di accesso, la scala e la complessità delle reti AAA sono cresciute e AAA è stato utilizzato anche per nuove applicazioni (come voice over IP). Ciò ha portato a nuove richieste sui protocolli AAA.

I requisiti di accesso alla rete per i protocolli AAA sono riassunti in Aboba, et al. [RFC2989]. Questi includono:

Failover

[RFC2865] non definisce meccanismi di failover e, di conseguenza, il comportamento di failover differisce tra le implementazioni. Per fornire un comportamento di failover ben definito, Diameter supporta riconoscimenti a livello di applicazione e definisce algoritmi di failover e la macchina a stati associata.

Sicurezza a livello di trasmissione

RADIUS [RFC2865] definisce uno schema di autenticazione e integrità a livello di applicazione che è richiesto solo per l'uso con pacchetti di risposta. Mentre [RFC2869] definisce un meccanismo aggiuntivo di autenticazione e integrità, l'uso è richiesto solo durante le sessioni EAP (Extensible Authentication Protocol) [RFC3748]. Sebbene sia supportato il mascheramento degli attributi, [RFC2865] non fornisce supporto per la riservatezza per pacchetto. Nell'accounting, [RFC2866] presume che la protezione replay sia fornita dal server di fatturazione backend piuttosto che all'interno del protocollo stesso.

Mentre [RFC3162] definisce l'uso di IPsec con RADIUS, il supporto per IPsec non è richiesto. Per fornire supporto universale per la sicurezza a livello di trasmissione e abilitare distribuzioni AAA intra-dominio e inter-dominio, Diameter fornisce supporto per TLS/TCP e DTLS/SCTP. La sicurezza è discussa nella Sezione 13.

Trasporto affidabile

RADIUS funziona su UDP e non definisce il comportamento di ritrasmissione; di conseguenza, l'affidabilità varia tra le implementazioni. Come descritto in [RFC2975], questo è un problema importante nell'accounting, dove la perdita di pacchetti può tradursi direttamente in perdita di entrate. Per fornire un comportamento di trasporto ben definito, Diameter funziona su meccanismi di trasporto affidabili (TCP, Stream Control Transmission Protocol (SCTP)) come definito in [RFC3539].

Supporto agli agenti

RADIUS non fornisce supporto esplicito per gli agenti, inclusi proxy, redirect e relay. Poiché il comportamento previsto non è definito, varia tra le implementazioni. Diameter definisce esplicitamente il comportamento degli agenti; questo è descritto nella Sezione 2.8.

Messaggi avviati dal server

Mentre i messaggi avviati dal server sono definiti in RADIUS [RFC5176], il supporto è facoltativo. Ciò rende difficile implementare funzionalità come la disconnessione non sollecitata o la ri-autenticazione/ri-autorizzazione su richiesta in una distribuzione eterogenea. Per affrontare questo problema, il supporto per i messaggi avviati dal server è obbligatorio in Diameter.

Supporto alla transizione

Sebbene Diameter non condivida un'unità di dati di protocollo (PDU) comune con RADIUS, sono stati compiuti notevoli sforzi per consentire la compatibilità all'indietro con RADIUS in modo che i due protocolli possano essere distribuiti nella stessa rete. Inizialmente, si prevede che Diameter verrà distribuito all'interno di nuovi dispositivi di rete, nonché all'interno di gateway che consentono la comunicazione tra dispositivi RADIUS legacy e agenti Diameter. Questa capacità consente di aggiungere il supporto Diameter alle reti legacy, mediante l'aggiunta di un gateway o server che parla sia RADIUS che Diameter.

Oltre a soddisfare i requisiti di cui sopra, Diameter fornisce anche supporto per quanto segue:

Negoziazione delle capacità

RADIUS non supporta messaggi di errore, negoziazione delle capacità o un flag obbligatorio/non obbligatorio per gli attributi. Poiché i client e i server RADIUS non sono a conoscenza delle capacità reciproche, potrebbero non essere in grado di negoziare con successo un servizio reciprocamente accettabile o, in alcuni casi, essere persino consapevoli di quale servizio è stato implementato. Diameter include supporto per la gestione degli errori (Sezione 7), negoziazione delle capacità (Sezione 5.3) e coppie attributo-valore (AVP) obbligatorie/non obbligatorie (Sezione 4.1).

Scoperta e configurazione dei peer

Le implementazioni RADIUS richiedono tipicamente che il nome o l'indirizzo dei server o dei client sia configurato manualmente, insieme ai segreti condivisi corrispondenti. Ciò comporta un grande onere amministrativo e crea la tentazione di riutilizzare il segreto condiviso RADIUS, che può risultare in gravi vulnerabilità di sicurezza se il Request Authenticator non è globalmente e temporalmente unico come richiesto in [RFC2865]. Tramite DNS, Diameter consente la scoperta dinamica dei peer (vedere Sezione 5.2). La derivazione di chiavi di sessione dinamiche è abilitata tramite sicurezza a livello di trasmissione.

Nel tempo, le capacità dei dispositivi Network Access Server (NAS) sono aumentate sostanzialmente. Di conseguenza, sebbene Diameter sia un protocollo notevolmente più sofisticato di RADIUS, rimane fattibile implementarlo all'interno di dispositivi embedded.

1.1. Protocollo Diameter

Il protocollo base Diameter fornisce le seguenti funzionalità:

• Capacità di scambiare messaggi e consegnare AVP
• Negoziazione delle capacità
• Notifica di errore
• Estensibilità, richiesta in [RFC2989], attraverso l'aggiunta di nuove applicazioni, comandi e AVP
• Servizi di base necessari per le applicazioni, come la gestione delle sessioni utente o l'accounting

Tutti i dati consegnati dal protocollo sono sotto forma di AVP. Alcuni di questi valori AVP sono utilizzati dal protocollo Diameter stesso, mentre altri consegnano dati associati a particolari applicazioni che impiegano Diameter. Gli AVP possono essere aggiunti arbitrariamente ai messaggi Diameter, l'unica restrizione è che la specifica Command Code Format (CCF) (Sezione 3.2) sia soddisfatta. Gli AVP sono utilizzati dal protocollo base Diameter per supportare le seguenti caratteristiche richieste:

• Trasporto di informazioni di autenticazione dell'utente, allo scopo di consentire al server Diameter di autenticare l'utente
• Trasporto di informazioni di autorizzazione specifiche del servizio, tra client e server, consentendo ai peer di decidere se la richiesta di accesso di un utente debba essere concessa
• Scambio di informazioni sull'utilizzo delle risorse, che possono essere utilizzate per scopi di accounting, pianificazione della capacità, ecc.
• Routing, relay, proxying e reindirizzamento di messaggi Diameter attraverso una gerarchia di server

Il protocollo base Diameter soddisfa i requisiti minimi per un protocollo AAA, come specificato da [RFC2989]. Il protocollo base può essere utilizzato da solo solo per scopi di accounting, oppure può essere utilizzato con un'applicazione Diameter, come Mobile IPv4 [RFC4004], o accesso alla rete [RFC4005]. È anche possibile estendere il protocollo base per l'uso in nuove applicazioni, tramite l'aggiunta di nuovi comandi o AVP. L'obiettivo iniziale di Diameter era le applicazioni di accesso alla rete e accounting. Un protocollo AAA veramente generico utilizzato da molte applicazioni potrebbe fornire funzionalità non fornite da Diameter. Pertanto, è imperativo che i progettisti di nuove applicazioni comprendano i loro requisiti prima di utilizzare Diameter. Vedere la Sezione 1.3.4 per ulteriori informazioni sulle applicazioni Diameter.

Qualsiasi nodo può avviare una richiesta. In questo senso, Diameter è un protocollo peer-to-peer. In questo documento, un client Diameter è un dispositivo al margine della rete che esegue il controllo degli accessi, come un Network Access Server (NAS) o un Foreign Agent (FA). Un client Diameter genera messaggi Diameter per richiedere servizi di autenticazione, autorizzazione e accounting per l'utente. Un agente Diameter è un nodo che non fornisce servizi locali di autenticazione o autorizzazione dell'utente; gli agenti includono proxy, redirect e agenti relay. Un server Diameter esegue l'autenticazione e/o l'autorizzazione dell'utente. Un nodo Diameter può agire come agente per determinate richieste mentre agisce come server per altre.

Il protocollo Diameter supporta anche messaggi avviati dal server, come una richiesta di interrompere il servizio a un particolare utente.

1.1.1. Descrizione del set di documenti

La specifica Diameter consiste in una versione aggiornata della specifica del protocollo base (questo documento) e del Profilo di Trasporto [RFC3539]. Questo documento rende obsoleti sia RFC 3588 che RFC 5719. Un riepilogo degli aggiornamenti del protocollo base inclusi in questo documento può essere trovato nella Sezione 1.1.3.

Questo documento definisce la specifica del protocollo base per AAA, che include il supporto per l'accounting. Ci sono anche una miriade di documenti applicativi che descrivono applicazioni che utilizzano questa specifica base per autenticazione, autorizzazione e accounting. Questi documenti applicativi specificano come utilizzare il protocollo Diameter nel contesto della loro applicazione.

Il documento del Profilo di Trasporto [RFC3539] discute problemi di livello di trasporto che si verificano con i protocolli AAA e raccomandazioni su come superare questi problemi. Questo documento definisce anche l'algoritmo di failover Diameter e la macchina a stati.

"Chiarimenti sul routing delle richieste Diameter basate sul nome utente e sul realm" [RFC5729] definisce un comportamento specifico su come instradare le richieste in base al contenuto dell'AVP User-Name (coppia attributo-valore).

1.1.2. Convenzioni utilizzate in questo documento

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119].

1.1.3. Modifiche rispetto a RFC 3588

Questo documento rende obsoleto RFC 3588 ma è completamente compatibile all'indietro con quel documento. Le modifiche introdotte in questo documento si concentrano sulla risoluzione di problemi emersi durante l'implementazione di Diameter (RFC 3588). Di seguito viene fornita una panoramica di alcune delle principali modifiche.

• Deprecato l'uso dell'AVP Inband-Security per la negoziazione di Transport Layer Security (TLS) [RFC5246]. È stato generalmente considerato che il bootstrap di TLS tramite AVP Inband-Security crea determinati rischi per la sicurezza perché non protegge completamente le informazioni trasportate nel CER/CEA (Capabilities-Exchange-Request/Capabilities-Exchange-Answer). Questa versione di Diameter adotta l'approccio comune di definire una porta protetta ben nota che i peer dovrebbero utilizzare quando comunicano tramite TLS/TCP e DTLS/SCTP. Questo nuovo approccio aumenta la negoziazione della sicurezza in banda esistente, ma non la sostituisce completamente. Il vecchio metodo è mantenuto per ragioni di compatibilità all'indietro.

• Deprecato lo scambio di messaggi CER/CEA nello stato aperto. Questa funzionalità era implicita nella tabella della macchina a stati dei peer di RFC 3588, ma non era chiaramente definita altrove in quel documento. Man mano che il lavoro su questo documento progrediva, è diventato chiaro che la molteplicità di significato e uso degli AVP Application-Id nei messaggi CER/CEA (e i messaggi stessi) è vista come un abuso delle regole di estensibilità di Diameter e quindi ha richiesto una semplificazione. Lo scambio di capacità nello stato aperto è stato reintrodotto in una specifica separata [RFC6737], che definisce chiaramente nuovi comandi per questa funzionalità.

• Semplificati i requisiti di sicurezza. L'uso di un trasporto protetto per lo scambio di messaggi Diameter rimane obbligatorio. Tuttavia, TLS/TCP e DTLS/SCTP sono diventati i metodi principali per proteggere Diameter con IPsec come alternativa secondaria. Vedere la Sezione 13 per i dettagli. Anche il supporto per il framework di sicurezza End-to-End (E2E-Sequence AVP e bit 'P' nell'intestazione AVP) è stato deprecato.

• Modificata l'estensibilità di Diameter. Ciò include correzioni alla descrizione dell'estensibilità di Diameter (Sezione 1.3 e altre) per aiutare meglio i progettisti di applicazioni Diameter; inoltre, la nuova specifica rilassa la politica rispetto all'allocazione di codici di comando per usi specifici del fornitore.

• Chiarito l'uso dell'ID applicazione. Chiarire l'uso corretto delle informazioni sull'ID applicazione, che possono essere trovate in più posizioni all'interno di un messaggio Diameter. Ciò include la correlazione degli ID applicazione trovati nelle intestazioni dei messaggi e negli AVP. Queste modifiche specificano anche chiaramente il valore dell'ID applicazione appropriato da utilizzare per specifici messaggi del protocollo base (ASR/ASA, STR/STA) e chiariscono il contenuto e l'uso di Vendor-Specific-Application-Id.

• Chiarite le correzioni di routing. Questo documento specifica più chiaramente quali informazioni (AVP e ID applicazione) possono essere utilizzate per prendere decisioni di routing generali. È stata anche aggiunta una regola per la prioritizzazione dei criteri di routing di reindirizzamento quando vengono trovate più voci di percorso tramite reindirizzamenti (vedere Sezione 6.13).

• Semplificata la scoperta dei peer Diameter. Il processo di scoperta Diameter ora supporta solo schemi di scoperta ampiamente utilizzati; il resto è stato deprecato (vedere Sezione 5.2 per i dettagli).

Ci sono molte altre correzioni varie che sono state introdotte in questo documento che potrebbero non essere considerate significative, ma hanno comunque valore. Gli esempi sono la rimozione di tipi obsoleti, correzioni alla macchina a stati, chiarimento del processo di elezione, validazione dei messaggi, correzioni ai valori AVP Failed-AVP e Result-Code, ecc. Tutti gli errata depositati contro RFC 3588 prima della pubblicazione di questo documento sono stati affrontati. Un elenco completo delle modifiche non è mostrato qui per ragioni pratiche.

1.2. Terminologia

AAA

Autenticazione, autorizzazione e accounting.

ABNF

Forma di Backus-Naur aumentata [RFC5234]. Un metalinguaggio con la propria sintassi e regole formali. Si basa sulla forma di Backus-Naur ed è utilizzato per definire scambi di messaggi in un protocollo di comunicazione bidirezionale.

Accounting

L'atto di raccogliere informazioni sull'utilizzo delle risorse allo scopo di pianificazione della capacità, audit, fatturazione o allocazione dei costi.

Record di accounting (Accounting Record)

Un record di accounting rappresenta un riepilogo del consumo di risorse di un utente durante l'intera sessione. I server di accounting che creano il record di accounting possono farlo elaborando eventi di accounting intermedi o eventi di accounting da diversi dispositivi che servono lo stesso utente.

Autenticazione (Authentication)

L'atto di verificare l'identità di un'entità (soggetto).

Autorizzazione (Authorization)

L'atto di determinare se a un'entità richiedente (soggetto) sarà consentito l'accesso a una risorsa (oggetto).

Coppia attributo-valore (Attribute-Value Pair, AVP)

Il protocollo Diameter consiste in un'intestazione seguita da una o più coppie attributo-valore (AVP). Un AVP include un'intestazione ed è utilizzato per incapsulare dati specifici del protocollo (ad esempio, informazioni di routing) nonché informazioni di autenticazione, autorizzazione o accounting.

Formato codice comando (Command Code Format, CCF)

Una forma modificata di ABNF utilizzata per definire i comandi Diameter (vedere Sezione 3.2).

Agente Diameter (Diameter Agent)

Un agente Diameter è un nodo Diameter che fornisce servizi di relay, proxy, redirect o traduzione.

Client Diameter (Diameter Client)

Un client Diameter è un nodo Diameter che supporta applicazioni client Diameter nonché il protocollo base. I client Diameter sono spesso implementati in dispositivi situati al margine di una rete e forniscono servizi di controllo degli accessi per quella rete. Esempi tipici di client Diameter includono il Network Access Server (NAS) e il Mobile IP Foreign Agent (FA).

Nodo Diameter (Diameter Node)

Un nodo Diameter è un processo host che implementa il protocollo Diameter e agisce come client, agente o server.

Peer Diameter (Diameter Peer)

Due nodi Diameter che condividono una connessione di trasporto TCP o SCTP diretta sono chiamati peer Diameter.

Server Diameter (Diameter Server)

Un server Diameter è un nodo Diameter che gestisce richieste di autenticazione, autorizzazione e accounting per un particolare realm. Per sua natura, un server Diameter deve supportare applicazioni server Diameter oltre al protocollo base.

Downstream

Downstream è usato per identificare la direzione di un particolare messaggio Diameter dal server home verso il client Diameter.

Realm home (Home Realm)

Un realm home è il dominio amministrativo con cui l'utente mantiene una relazione di account.

Server home (Home Server)

Un server Diameter che serve il realm home.

Accounting intermedio (Interim Accounting)

Un messaggio di accounting intermedio fornisce un'istantanea dell'utilizzo durante la sessione di un utente. Tipicamente, è implementato per fornire un accounting parziale della sessione di un utente nel caso in cui un riavvio del dispositivo o altro problema di rete impedisca la consegna di un messaggio di riepilogo della sessione o di un record di sessione.

Realm locale (Local Realm)

Un realm locale è il dominio amministrativo che fornisce servizi a un utente. Un dominio amministrativo può agire come realm locale per determinati utenti pur essendo un realm home per altri.

Multi-sessione (Multi-session)

Una multi-sessione rappresenta un collegamento logico di diverse sessioni. Le multi-sessioni sono tracciate utilizzando l'Acct-Multi-Session-Id. Un esempio di multi-sessione sarebbe un bundle PPP multi-link. Ogni gamba del bundle sarebbe una sessione mentre l'intero bundle sarebbe una multi-sessione.

Identificatore di accesso alla rete (Network Access Identifier)

L'identificatore di accesso alla rete, o NAI [RFC4282], è utilizzato nel protocollo Diameter per estrarre l'identità e il realm di un utente. L'identità è utilizzata per identificare l'utente durante l'autenticazione e/o l'autorizzazione mentre il realm è utilizzato per scopi di routing dei messaggi.

Agente proxy o proxy (Proxy Agent or Proxy)

Oltre a inoltrare richieste e risposte, i proxy prendono decisioni politiche relative all'utilizzo delle risorse e al provisioning. Tipicamente, ciò è realizzato tracciando lo stato dei dispositivi NAS. Mentre i proxy di solito non rispondono alle richieste dei client prima di ricevere una risposta dal server, possono originare messaggi di rifiuto nei casi in cui le politiche vengano violate. Di conseguenza, i proxy devono comprendere la semantica dei messaggi che li attraversano e potrebbero non supportare tutte le applicazioni Diameter.

Realm

La stringa nel NAI che segue immediatamente il carattere '@'. I nomi di realm NAI devono essere univoci e sono sovrapposti all'amministrazione dello spazio dei nomi DNS. Diameter utilizza il realm, indicato anche vagamente come dominio, per determinare se i messaggi possono essere soddisfatti localmente o se devono essere instradati o reindirizzati. In RADIUS, i nomi di realm non sono necessariamente sovrapposti allo spazio dei nomi DNS ma possono esserne indipendenti.

Accounting in tempo reale (Real-Time Accounting)

L'accounting in tempo reale coinvolge l'elaborazione di informazioni sull'utilizzo delle risorse entro una finestra temporale definita. Tipicamente, i vincoli temporali sono imposti per limitare il rischio finanziario. L'applicazione Diameter Credit-Control [RFC4006] è un esempio di applicazione che definisce funzionalità di accounting in tempo reale.

Agente relay o relay (Relay Agent or Relay)

I relay inoltrano richieste e risposte basandosi su AVP relativi al routing e voci della tabella di routing. Poiché i relay non prendono decisioni politiche, non esaminano né alterano AVP non relativi al routing. Di conseguenza, i relay non originano mai messaggi, non hanno bisogno di comprendere la semantica dei messaggi o degli AVP non relativi al routing, e sono in grado di gestire qualsiasi applicazione o tipo di messaggio Diameter. Poiché i relay prendono decisioni basate su informazioni negli AVP di routing e nelle tabelle di inoltro del realm, non mantengono lo stato sull'utilizzo delle risorse NAS o sulle sessioni in corso.

Agente di reindirizzamento (Redirect Agent)

Piuttosto che inoltrare richieste e risposte tra client e server, gli agenti di reindirizzamento indirizzano i client ai server e consentono loro di comunicare direttamente. Poiché gli agenti di reindirizzamento non si trovano nel percorso di inoltro, non alterano alcun AVP in transito tra client e server. Gli agenti di reindirizzamento non originano messaggi e sono in grado di gestire qualsiasi tipo di messaggio, sebbene possano essere configurati solo per reindirizzare messaggi di determinati tipi, agendo come agenti relay o proxy per altri tipi. Come con gli agenti relay, gli agenti di reindirizzamento non mantengono lo stato rispetto alle sessioni o alle risorse NAS.

Sessione (Session)

Una sessione è una progressione correlata di eventi dedicati a una particolare attività. I documenti applicativi Diameter forniscono linee guida su quando inizia e finisce una sessione. Tutti i pacchetti Diameter con lo stesso Session-Id sono considerati parte della stessa sessione.

Agente con stato (Stateful Agent)

Un agente con stato è uno che mantiene informazioni sullo stato della sessione, tenendo traccia di tutte le sessioni attive autorizzate. Ogni sessione autorizzata è vincolata a un particolare servizio, e il suo stato è considerato attivo fino a quando non viene notificato diversamente o fino alla scadenza.

Sotto-sessione (Sub-session)

Una sotto-sessione rappresenta un servizio distinto (ad esempio, QoS o caratteristiche dei dati) fornito a una determinata sessione. Questi servizi possono verificarsi contemporaneamente (ad esempio, trasferimento simultaneo di voce e dati durante la stessa sessione) o in serie. Questi cambiamenti nelle sessioni sono tracciati con l'Accounting-Sub-Session-Id.

Stato di transazione (Transaction State)

Il protocollo Diameter richiede che gli agenti mantengano lo stato di transazione, che è utilizzato per scopi di failover. Lo stato di transazione implica che al momento dell'inoltro di una richiesta, l'identificatore Hop-by-Hop viene salvato; il campo viene sostituito con un identificatore localmente univoco, che viene ripristinato al suo valore originale quando viene ricevuta la risposta corrispondente. Lo stato della richiesta viene rilasciato al ricevimento della risposta. Un agente senza stato è uno che mantiene solo lo stato di transazione.

Agente di traduzione (Translation Agent)

Un agente di traduzione (TLA nella Figura 4) è un nodo Diameter con stato che esegue la traduzione del protocollo tra Diameter e un altro protocollo AAA, come RADIUS.

Upstream

Upstream è usato per identificare la direzione di un particolare messaggio Diameter dal client Diameter verso il server home.

Utente (User)

L'entità o dispositivo che richiede o utilizza una risorsa, a supporto del quale un client Diameter ha generato una richiesta.

1.3. Approccio all'estensibilità

Il protocollo Diameter è progettato per essere estensibile, utilizzando diversi meccanismi, tra cui:

• Definizione di nuovi valori AVP
• Creazione di nuovi AVP
• Creazione di nuovi comandi
• Creazione di nuove applicazioni

Dal punto di vista dell'estensibilità, le applicazioni di autenticazione, autorizzazione e accounting Diameter sono trattate allo stesso modo.

Nota: i progettisti di protocolli dovrebbero cercare di riutilizzare le funzionalità esistenti, vale a dire valori AVP, AVP, comandi e applicazioni Diameter. Il riutilizzo semplifica la standardizzazione e l'implementazione. Per evitare potenziali problemi di interoperabilità, è importante assicurarsi che la semantica delle funzionalità riutilizzate sia ben compresa. Dato che Diameter può anche trasportare attributi RADIUS come AVP Diameter, tali considerazioni di riutilizzo si applicano anche agli attributi RADIUS esistenti che possono essere utili in un'applicazione Diameter.

1.3.1. Definizione di nuovi valori AVP

Per allocare un nuovo valore AVP per AVP definiti nel protocollo base Diameter, l'IETF deve approvare un nuovo RFC che descrive il valore AVP. Le considerazioni IANA per questi valori AVP sono discusse nella Sezione 11.3.

L'allocazione dei valori AVP per altri AVP è guidata dalle considerazioni IANA del documento che definisce quegli AVP. Tipicamente, l'allocazione di nuovi valori per un AVP definito in un RFC richiederebbe una revisione IETF [RFC5226], mentre i valori per AVP specifici del fornitore possono essere allocati dal fornitore.

1.3.2. Creazione di nuovi AVP

Un nuovo AVP in fase di definizione DEVE utilizzare uno dei tipi di dati elencati nelle Sezioni 4.2 o 4.3. Se un tipo di dati derivato appropriato è già definito, DOVREBBE essere utilizzato invece di un tipo di dati base per incoraggiare la riutilizzabilità e le buone pratiche di progettazione.

Nel caso in cui sia necessario un raggruppamento logico di AVP e siano possibili più "gruppi" in un determinato comando, si raccomanda di utilizzare un AVP raggruppato (vedere Sezione 4.4).

La creazione di nuovi AVP può avvenire in vari modi. L'approccio raccomandato è definire un nuovo AVP per scopi generali in un RFC Standards Track approvato dall'IETF. Tuttavia, come descritto nella Sezione 11.1.1, esistono altri meccanismi.

1.3.3. Creazione di nuovi comandi

Un nuovo codice comando DEVE essere allocato quando AVP richiesti (quelli indicati come {AVP} nella definizione CCF) vengono aggiunti a, eliminati da o ridefiniti in (ad esempio, cambiando un AVP richiesto in uno opzionale) un comando esistente.

Inoltre, se le caratteristiche di trasporto di un comando vengono modificate (ad esempio, rispetto al numero di round trip richiesti), un nuovo codice comando DEVE essere registrato.

Una modifica al CCF di un comando, come descritto sopra, DEVE risultare nella definizione di un nuovo codice comando. Ciò porta successivamente alla necessità di definire una nuova applicazione Diameter per qualsiasi applicazione che utilizzerà quel nuovo comando.

Le considerazioni IANA per i codici comando sono discusse nella Sezione 3.1.

1.3.4. Creazione di nuove applicazioni Diameter

Le applicazioni Diameter possono definire nuovi codici comando, AVP e semantiche associate. La creazione di nuove applicazioni Diameter richiede tipicamente un RFC Standards Track approvato dall'IETF. Vedere la Sezione 11.2.1 per i dettagli.