2. Panoramica del protocollo

Il protocollo Diameter di base si occupa della creazione di connessioni con i peer, della negoziazione delle capacità, di come i messaggi vengono inviati e instradati attraverso i peer e di come le connessioni vengono infine interrotte. Il protocollo di base definisce anche determinate regole che si applicano a tutti gli scambi di messaggi tra nodi Diameter.

La comunicazione tra peer Diameter inizia con un peer che invia un messaggio a un altro peer Diameter. L'insieme di AVP inclusi nel messaggio è determinato da una particolare applicazione Diameter. Un AVP che viene incluso per fare riferimento alla sessione di un utente è il Session-Id.

La richiesta iniziale di autenticazione e/o autorizzazione di un utente includerebbe l'AVP Session-Id. Il Session-Id viene quindi utilizzato in tutti i messaggi successivi per identificare la sessione dell'utente (vedere la Sezione 8 per ulteriori informazioni). La parte comunicante può accettare la richiesta o rifiutarla restituendo un messaggio di risposta con l'AVP Result-Code impostato per indicare che si è verificato un errore. Il comportamento specifico del server o client Diameter che riceve una richiesta dipende dall'applicazione Diameter impiegata.

Lo stato della sessione (associato a un Session-Id) DEVE essere liberato al ricevimento di Session-Termination-Request, Session-Termination-Answer, scadenza del tempo di servizio autorizzato nell'AVP Session-Timeout e secondo le regole stabilite in una particolare applicazione Diameter.

Il protocollo Diameter di base può essere utilizzato da solo per applicazioni di contabilità. Per l'autenticazione e l'autorizzazione, viene sempre esteso per una particolare applicazione.

I client Diameter DEVONO supportare il protocollo di base, che include la contabilità. Inoltre, DEVONO supportare completamente ogni applicazione Diameter necessaria per implementare il servizio del client, ad esempio Network Access Server Requirements (NASREQ) [RFC2881] e/o Mobile IPv4. Un client Diameter DEVE essere indicato come "Client Diameter X" dove X è l'applicazione che supporta e non un "Client Diameter".

I server Diameter DEVONO supportare il protocollo di base, che include la contabilità. Inoltre, DEVONO supportare completamente ogni applicazione Diameter necessaria per implementare il servizio previsto, ad esempio NASREQ e/o Mobile IPv4. Un server Diameter DEVE essere indicato come "Server Diameter X" dove X è l'applicazione che supporta, e non un "Server Diameter".

I relay e gli agenti di reindirizzamento Diameter sono trasparenti alle applicazioni Diameter, ma DEVONO supportare il protocollo di base Diameter, che include la contabilità, e tutte le applicazioni Diameter.

I proxy Diameter DEVONO supportare il protocollo di base, che include la contabilità. Inoltre, DEVONO supportare completamente ogni applicazione Diameter necessaria per implementare i servizi proxy, ad esempio NASREQ e/o Mobile IPv4. Un proxy Diameter DEVE essere indicato come "Proxy Diameter X" dove X è l'applicazione che supporta, e non un "Proxy Diameter".

2.1. Trasporto

Il profilo di trasporto Diameter è definito in [RFC3539].

Il protocollo Diameter di base viene eseguito sulla porta 3868 sia per TCP [RFC0793] che per SCTP [RFC4960]. Per TLS [RFC5246] e Datagram Transport Layer Security (DTLS) [RFC6347], un nodo Diameter che avvia una connessione prima di qualsiasi scambio di messaggi DEVE essere eseguito sulla porta 5658. Si presume che TLS venga eseguito sopra TCP quando viene utilizzato e che DTLS venga eseguito sopra SCTP quando viene utilizzato.

Se il peer Diameter non supporta la ricezione di connessioni TLS/TCP e DTLS/SCTP sulla porta 5658 (cioè, il peer è conforme solo a RFC 3588), l'iniziatore PUÒ tornare all'utilizzo di TCP o SCTP sulla porta 3868. Si noti che questo schema è mantenuto solo per scopi di retrocompatibilità e che esistono vulnerabilità di sicurezza intrinseche quando i messaggi CER/CEA iniziali vengono inviati non protetti (vedere la Sezione 5.6).

I client Diameter DEVONO supportare TCP o SCTP; gli agenti e i server DOVREBBERO supportare entrambi.

Un nodo Diameter PUÒ avviare connessioni da una porta di origine diversa da quella che dichiara di accettare connessioni in entrata, e DEVE essere sempre pronto a ricevere connessioni sulla porta 3868 per TCP o SCTP e sulla porta 5658 per connessioni TLS/TCP e DTLS/SCTP. Quando viene utilizzata la scoperta dei peer basata su DNS (Sezione 5.2), i numeri di porta ricevuti dai record SRV hanno la precedenza sulle porte predefinite (3868 e 5658).

Una data istanza Diameter della macchina a stati del peer NON DEVE utilizzare più di una connessione di trasporto per comunicare con un dato peer, a meno che non esistano più istanze sul peer, nel qual caso è consentita una connessione separata per processo.

Quando non esiste una connessione di trasporto con un peer, DOVREBBE essere effettuato periodicamente un tentativo di connessione. Questo comportamento è gestito tramite il timer Tc (vedere la Sezione 12 per i dettagli), il cui valore raccomandato è di 30 secondi. Ci sono alcune eccezioni a questa regola, come quando un peer ha terminato la connessione di trasporto dichiarando che non desidera comunicare.

Quando ci si connette a un peer e vengono specificati zero o più trasporti, DOVREBBE essere tentato prima TLS, seguito da DTLS, poi da TCP e infine da SCTP. Vedere la Sezione 5.2 per ulteriori informazioni sulla scoperta dei peer.

Le implementazioni Diameter DOVREBBERO essere in grado di interpretare i messaggi ICMP di porta del protocollo non raggiungibile come indicazioni esplicite che il server non è raggiungibile, soggette alla politica di sicurezza sulla fiducia in tali messaggi. Ulteriori indicazioni relative al trattamento degli errori ICMP possono essere trovate in [RFC5927] e [RFC5461]. Le implementazioni Diameter DOVREBBERO anche essere in grado di interpretare un reset dal trasporto e tentativi di connessione scaduti. Se Diameter riceve dati dal livello inferiore che non possono essere analizzati o identificati come un errore Diameter commesso dal peer, il flusso è compromesso e non può essere ripristinato. La connessione di trasporto DEVE essere chiusa utilizzando una chiamata RESET (inviare un bit TCP RST) o un messaggio SCTP ABORT (la chiusura controllata è compromessa).

2.1.1. Linee guida SCTP

I messaggi Diameter DOVREBBERO essere mappati nei flussi SCTP in modo da evitare il blocco head-of-line (HOL). Tra i diversi modi di eseguire la mappatura che soddisfano questo requisito, si RACCOMANDA che un nodo Diameter invii ogni messaggio Diameter (richiesta o risposta) sul flusso zero con il flag non ordinato impostato. Tuttavia, i nodi Diameter POSSONO selezionare e implementare altre alternative di progettazione per evitare il blocco HOL come l'utilizzo di più flussi con il flag non ordinato cancellato (come originariamente indicato in RFC 3588). Sul lato ricevente, un'entità Diameter DEVE essere pronta a ricevere messaggi Diameter su qualsiasi flusso ed è libera di restituire risposte su un flusso diverso. In questo modo, entrambi i lati gestiscono i flussi disponibili nella direzione di invio, indipendentemente dai flussi scelti dall'altro lato per inviare un particolare messaggio Diameter. Questi messaggi possono essere fuori ordine e appartenere a diverse sessioni Diameter.

La consegna fuori ordine ha preoccupazioni speciali durante la creazione e la terminazione di una connessione. Quando viene stabilita una connessione, il lato rispondente invia un messaggio CEA e passa allo stato R-Open come specificato nella Sezione 5.6. Se un messaggio dell'applicazione viene inviato poco dopo il CEA e consegnato fuori ordine, il lato iniziatore, ancora nello stato Wait-I-CEA, scarterà il messaggio dell'applicazione e chiuderà la connessione. Per evitare questa condizione di gara, il lato ricevente NON DOVREBBE utilizzare metodi di consegna fuori ordine fino a quando il primo messaggio non è stato ricevuto dall'iniziatore, dimostrando che è passato allo stato I-Open. Per attivare un tale messaggio, il lato ricevente potrebbe inviare un DWR immediatamente dopo l'invio di un CEA. Al ricevimento del corrispondente DWA, il lato ricevente dovrebbe iniziare a utilizzare metodi di consegna fuori ordine per contrastare il blocco HOL.

Un'altra condizione di gara può verificarsi quando vengono utilizzati i messaggi DPR e DPA. Sia DPR che DPA sono di piccole dimensioni; quindi, possono essere consegnati al peer più velocemente dei messaggi dell'applicazione quando viene utilizzato un meccanismo di consegna fuori ordine. Pertanto, è possibile che uno scambio DPR/DPA si completi mentre i messaggi dell'applicazione sono ancora in transito, con conseguente perdita di questi messaggi. Un'implementazione potrebbe mitigare questa condizione di gara, ad esempio, utilizzando timer e attendere un breve periodo di tempo per l'arrivo dei messaggi a livello di applicazione in sospeso prima di procedere alla disconnessione della connessione di trasporto. Alla fine, i messaggi persi vengono gestiti dal meccanismo di ritrasmissione descritto nella Sezione 5.5.4.

Un agente Diameter DOVREBBE utilizzare identificatori di protocollo del payload dedicati (PPID) per i chunk SCTP DATA in chiaro e crittografati invece di utilizzare solo l'identificatore di protocollo del payload non specificato (valore 0). A tale scopo, vengono allocati due valori PPID: il valore PPID 46 è per i messaggi Diameter nei chunk SCTP DATA in chiaro e il valore PPID 47 è per i messaggi Diameter nei chunk DTLS/SCTP DATA protetti.

2.2. Protezione dei messaggi Diameter

Le connessioni tra peer Diameter DOVREBBERO essere protette da TLS/TCP e DTLS/SCTP. Tutte le implementazioni del protocollo di base Diameter DEVONO supportare l'uso di TLS/TCP e DTLS/SCTP. Se desiderato, meccanismi di sicurezza alternativi indipendenti da Diameter, come IPsec [RFC4301], possono essere implementati per proteggere le connessioni tra peer. Il protocollo Diameter NON DEVE essere utilizzato senza uno tra TLS, DTLS o IPsec.

2.3. Conformità delle applicazioni Diameter

Gli ID delle applicazioni vengono annunciati durante la fase di scambio delle capacità (vedere la Sezione 5.3). Annunciare il supporto di un'applicazione implica che il mittente supporti le funzionalità specificate nella rispettiva specifica dell'applicazione Diameter.

Le implementazioni POSSONO aggiungere AVP opzionali arbitrari con il bit M cancellato (inclusi AVP specifici del fornitore) a un comando definito in un'applicazione, ma solo se la specifica della sintassi CCF del comando lo consente. Si prega di fare riferimento alla Sezione 11.1.1 per i dettagli.

2.4. Identificatori delle applicazioni

Ogni applicazione Diameter DEVE avere un ID applicazione assegnato da IANA. Il protocollo di base non richiede un ID applicazione poiché il suo supporto è obbligatorio. Durante lo scambio di capacità, i nodi Diameter informano i loro peer delle applicazioni supportate localmente. Inoltre, tutti i messaggi Diameter contengono un ID applicazione, che viene utilizzato nel processo di inoltro dei messaggi.

Sono definiti i seguenti valori di ID applicazione:

Diameter common message       0
Diameter base accounting      3
Relay                         0xffffffff

I relay e gli agenti di reindirizzamento DEVONO annunciare l'ID applicazione Relay, mentre tutti gli altri nodi Diameter DEVONO annunciare le applicazioni supportate localmente. Il destinatario di un messaggio di scambio di capacità che annuncia il servizio relay DEVE presumere che il mittente supporti tutte le applicazioni attuali e future.

I relay e gli agenti proxy Diameter sono responsabili della ricerca di un server upstream che supporti l'applicazione di un particolare messaggio. Se non ne può essere trovato alcuno, viene restituito un messaggio di errore con l'AVP Result-Code impostato su DIAMETER_UNABLE_TO_DELIVER.

2.5. Connessioni vs Sessioni

Questa sezione tenta di fornire al lettore una comprensione della differenza tra "connessione" e "sessione", termini utilizzati ampiamente in questo documento.

Una connessione si riferisce a una connessione a livello di trasporto tra due peer che viene utilizzata per inviare e ricevere messaggi Diameter. Una sessione è un concetto logico a livello dell'applicazione che esiste tra il client Diameter e il server Diameter; viene identificata tramite l'AVP Session-Id.

          +--------+          +-------+          +--------+
          | Client |          | Relay |          | Server |
          +--------+          +-------+          +--------+
                   <---------->       <---------->
                connessione peer A  connessione peer B

                   <----------------------------->
                         Sessione utente x

             Figura 1: Connessioni e sessioni Diameter

Nell'esempio fornito nella Figura 1, la connessione peer A è stabilita tra il client e il relay. La connessione peer B è stabilita tra il relay e il server. La sessione utente X si estende dal client attraverso il relay al server. Ogni "utente" di un servizio causa l'invio di una richiesta di autenticazione, con un identificatore di sessione univoco. Una volta accettato dal server, sia il client che il server sono consapevoli della sessione.

È importante notare che non c'è relazione tra una connessione e una sessione, e che i messaggi Diameter per più sessioni sono tutti multiplexati attraverso una singola connessione. Si noti inoltre che i messaggi Diameter relativi alla sessione, sia specifici dell'applicazione che quelli definiti in questo documento come ASR/ASA, RAR/RAA e STR/STA, DEVONO portare l'ID applicazione dell'applicazione. I messaggi Diameter relativi alla creazione e manutenzione della connessione peer come CER/CEA, DWR/DWA e DPR/DPA DEVONO portare un ID applicazione di zero (0).

2.6. Tabella dei peer

La tabella dei peer Diameter viene utilizzata nell'inoltro dei messaggi ed è referenziata dalla tabella di routing. Una voce della tabella dei peer contiene i seguenti campi:

Identità host

Seguendo le convenzioni descritte per il formato dati AVP derivato da DiameterIdentity nella Sezione 4.3.1, questo campo contiene il contenuto dell'AVP Origin-Host (Sezione 6.3) trovato nel messaggio CER o CEA.

StatusT

Questo è lo stato della voce del peer e DEVE corrispondere a uno dei valori elencati nella Sezione 5.6.

Statico o dinamico

Specifica se una voce del peer è stata configurata staticamente o scoperta dinamicamente.

Tempo di scadenza

Specifica il momento in cui le voci della tabella dei peer scoperte dinamicamente devono essere aggiornate o scadute. Se vengono utilizzati certificati a chiave pubblica per la sicurezza Diameter (ad esempio, con TLS), questo valore NON DEVE essere superiore ai tempi di scadenza nei certificati pertinenti.

TLS/TCP e DTLS/SCTP abilitati

Specifica se TLS/TCP e DTLS/SCTP devono essere utilizzati quando si comunica con il peer.

Informazioni di sicurezza aggiuntive, quando necessario (ad esempio, chiavi, certificati).

2.7. Tabella di routing

Tutte le ricerche di routing basate su realm vengono eseguite rispetto a ciò che è comunemente noto come tabella di routing (vedere la Sezione 12). Ogni voce della tabella di routing contiene i seguenti campi:

Nome del realm

Questo è il campo che DEVE essere utilizzato come chiave primaria nelle ricerche della tabella di routing. Si noti che alcune implementazioni eseguono le loro ricerche basandosi sulla corrispondenza più lunga da destra sul realm piuttosto che richiedere una corrispondenza esatta.

Identificatore dell'applicazione

Un'applicazione è identificata da un ID applicazione. Una voce di route può avere una destinazione diversa in base all'ID applicazione nell'intestazione del messaggio. Questo campo DEVE essere utilizzato come campo chiave secondario nelle ricerche della tabella di routing.

Azione locale

Il campo Azione locale viene utilizzato per identificare come deve essere trattato un messaggio. Sono supportate le seguenti azioni:

LOCAL - Messaggi Diameter che possono essere soddisfatti localmente e non devono essere instradati verso un'altra entità Diameter.
RELAY - Tutti i messaggi Diameter che rientrano in questa categoria DEVONO essere instradati verso un'entità Diameter del prossimo hop indicata dall'identificatore descritto di seguito. Il routing viene eseguito senza modificare alcun AVP non di routing. Vedere la Sezione 6.1.9 per le linee guida sul relay.
PROXY - Tutti i messaggi Diameter che rientrano in questa categoria DEVONO essere instradati verso un'entità Diameter successiva indicata dall'identificatore descritto di seguito. Il server locale PUÒ applicare le sue politiche locali al messaggio includendo nuovi AVP nel messaggio prima del routing. Vedere la Sezione 6.1.9 per le linee guida sul proxy.
REDIRECT - I messaggi Diameter che rientrano in questa categoria DEVONO avere l'identità del/dei server Diameter principale/i aggiunta e restituita al mittente del messaggio. Vedere la Sezione 6.1.8 per le linee guida sul reindirizzamento.

Identificatore del server

L'identità di uno o più server a cui il messaggio deve essere instradato. Questa identità DEVE essere presente anche nel campo Identità host della tabella dei peer (Sezione 2.6). Quando l'azione locale è impostata su RELAY o PROXY, questo campo contiene l'identità del/dei server a cui il messaggio DEVE essere instradato. Quando il campo Azione locale è impostato su REDIRECT, questo campo contiene l'identità di uno o più server a cui il messaggio DEVE essere reindirizzato.

Statico o dinamico

Specifica se una voce di route è stata configurata staticamente o scoperta dinamicamente.

Tempo di scadenza

Specifica il momento in cui una voce della tabella di route scoperta dinamicamente scade. Se vengono utilizzati certificati a chiave pubblica per la sicurezza Diameter (ad esempio, con TLS), questo valore NON DEVE essere superiore al tempo di scadenza nei certificati pertinenti.

È importante notare che gli agenti Diameter DEVONO supportare almeno una delle modalità di funzionamento LOCAL, RELAY, PROXY o REDIRECT. Gli agenti non devono supportare tutte le modalità di funzionamento per essere conformi alla specifica del protocollo, ma DEVONO seguire le linee guida di conformità del protocollo nella Sezione 2. Gli agenti relay e i proxy NON DEVONO riordinare gli AVP.

La tabella di routing PUÒ includere una voce predefinita che DEVE essere utilizzata per tutte le richieste che non corrispondono a nessuna delle altre voci. La tabella di routing PUÒ essere costituita solo da tale voce.

Quando una richiesta viene instradata, il server di destinazione DEVE aver annunciato l'ID applicazione (vedere la Sezione 2.4) per il messaggio dato o essersi annunciato come agente relay o proxy. Altrimenti, viene restituito un errore con l'AVP Result-Code impostato su DIAMETER_UNABLE_TO_DELIVER.

2.8. Ruolo degli agenti Diameter

Oltre ai client e ai server, il protocollo Diameter introduce agenti relay, proxy, reindirizzamento e traduzione, ognuno dei quali è definito nella Sezione 1.2. Gli agenti Diameter sono utili per diversi motivi:

Possono distribuire l'amministrazione dei sistemi a un raggruppamento configurabile, inclusa la manutenzione delle associazioni di sicurezza.
Possono essere utilizzati per la concentrazione delle richieste da un numero di set di apparecchiature NAS co-locate o distribuite a un insieme di gruppi di utenti simili.
Possono eseguire elaborazioni a valore aggiunto sulle richieste o risposte.
Possono essere utilizzati per il bilanciamento del carico.
Una rete complessa avrà più fonti di autenticazione, possono ordinare le richieste e inoltrarle verso l'obiettivo corretto.

Il protocollo Diameter richiede che gli agenti mantengano lo stato della transazione, che viene utilizzato per scopi di failover. Lo stato della transazione implica che al momento dell'inoltro di una richiesta, il suo identificatore Hop-by-Hop viene salvato; il campo viene sostituito con un identificatore univoco locale, 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 è quello che mantiene solo lo stato della transazione.

L'AVP Proxy-Info consente agli agenti senza stato di aggiungere uno stato locale a una richiesta Diameter, con la garanzia che lo stesso stato sarà presente nella risposta. Tuttavia, le procedure di failover del protocollo richiedono che gli agenti mantengano una copia delle richieste in sospeso.

Un agente con stato è quello che mantiene le informazioni sullo stato della sessione tenendo traccia di tutte le sessioni attive autorizzate. Ogni sessione autorizzata è associata a un particolare servizio e il suo stato è considerato attivo fino a quando l'agente non viene informato diversamente o la sessione scade. Ogni sessione autorizzata ha una scadenza, che viene comunicata dai server Diameter tramite l'AVP Session-Timeout.

Il mantenimento dello stato della sessione può essere utile in determinate applicazioni, come:

Traduzione di protocollo (ad esempio, RADIUS <-> Diameter)
Limitazione delle risorse autorizzate a un particolare utente
Audit per utente o per transazione

Un agente Diameter PUÒ agire in modo con stato per alcune richieste ed essere senza stato per altre. Un'implementazione Diameter PUÒ agire come un tipo di agente per alcune richieste e come un altro tipo di agente per altre.

2.8.1. Agenti relay

Gli agenti relay sono agenti Diameter che accettano richieste e instradano messaggi ad altri nodi Diameter in base alle informazioni trovate nei messaggi (ad esempio, il valore dell'AVP Destination-Realm Sezione 6.6). Questa decisione di routing viene eseguita utilizzando un elenco di realm supportati e peer noti. Questo è noto come tabella di routing, come definito ulteriormente nella Sezione 2.7.

I relay possono, ad esempio, essere utilizzati per aggregare richieste da più server di accesso alla rete (NAS) all'interno di un'area geografica comune (punto di presenza, POP). L'uso dei relay è vantaggioso poiché elimina la necessità per i NAS di essere configurati con le informazioni di sicurezza necessarie che altrimenti richiederebbero per comunicare con i server Diameter in altri realm. Allo stesso modo, questo riduce il carico di configurazione sui server Diameter che sarebbe altrimenti necessario quando i NAS vengono aggiunti, modificati o eliminati.