DIAMETER

In informatica e telecomunicazioni Diameter è un protocollo AAA (Authentication, Authorization and Accounting) successivo a RADIUS, anche se non è direttamente retrocompatibile. RADIUS è un protocollo AAA client-server tra un NAS (Network Access Server) e un server RADIUS centralizzato, basato sul protocollo di livello di trasporto TCP; Diameter è un protocollo AAA peer-to-peer e consiste di un protocollo di base (specificato nell'RFC 3588) e di un set di estensioni chiamate applicazioni Diameter. Il protocollo base non può essere utilizzato da solo, ma sempre associato a qualche applicazione Diameter specifica del servizio da fornire (Mobile IP, NASREQ, Strong Security, ecc.). È basato sui protocolli di trasporto TCP o SCTP, e richiede l'utilizzo obbligatorio di IPsec.

Nascita

[modifica | modifica wikitesto]

I principali motivi che hanno spinto a definire un nuovo protocollo sono stati i problemi di RADIUS elencati di seguito.

  • Dimensione limitata degli attributi: un attributo RADIUS è trasportato in un messaggio RADIUS come una tupla di lunghezza 3 { Attribute Type, Attribute Length, Attribute Value }. Il campo Attribute Length è di un ottetto, e il valore massimo di 255 pone un tetto massimo al numero di ottetti dei dati di un determinato attributo. Un attributo Diameter è trasportato in un messaggio Diameter come una tupla di lunghezza 5 { Attribute Type, Flags, Attribute Length, Vendor-ID, Attribute Value }. Il campo Attribute Length è di tre ottetti, quindi il suo valore massimo consente oltre 16 milioni di ottetti di dati per un determinato attributo.
  • Numero limitato di messaggi in sospeso concorrenti: il campo Identifier nell'header di un pacchetto RADIUS è utilizzato per riconoscere le ritrasmissioni. Il campo identificatore è di un ottetto, che impone un limite massimo di 255 messaggi in attesa tra un RADIUS client e un RADIUS server. Il campo End-to-End Identifier nell'header di un messaggio Diameter è anch'esso utilizzato per riconoscere le ritrasmissioni; ha una lunghezza di 4 ottetti, consentendo oltre 4 miliardi di messaggi in attesa da un client Diameter.
  • Inabilità al controllo di flusso sul server: RADIUS lavora su UDP, un semplice protocollo di trasporto non connesso che manca di qualsiasi meccanismo per il nodo ricevente di regolare il flusso di dati dal nodo mittente. Diameter opera su TCP o SCTP (Stream Control Transmission Protocol), protocolli di trasporto orientati alla connessione con meccanismi di controllo di flusso e per evitare congestione.
  • Rilevamento limitato di un blocco del server: possono esserci molte ragioni per cui un NAS può bloccarsi e non ricevere una risposta ad una data richiesta RADIUS, tra cui congestione della rete, o una temporanea caduta del segnale nel percorso tra il NAS e il server, o un blocco del server stesso, ecc. Con RADIUS, e quindi UDP, il NAS non può distinguere la causa che ha determinato il blocco, quindi assume che il problema sia sul next hop e ritrasmette verso un hop alternativo; questa sorta di recovery molto spesso è inappropriata. Con un layer di trasporto orientato alla connessione e grazie ai messaggi Diameter keepalive, un nodo Diameter può accorgersi della caduta locale di un peer.
  • Rigetto silenzioso dei pacchetti: il protocollo RADIUS specifica che i messaggi possano essere respinti silenziosamente per una varietà di condizioni d'errore. In questi casi, il NAS assumerà che il server non abbia ricevuto il messaggio, e farà svariati tentativi di ritrasmissione prima di abbandonare definitivamente la richiesta. Il protocollo Diameter restituisce una risposta per tutte, o quasi, le condizioni d'errore.
  • Fail-over inefficiente del server: molte implementazioni NAS configurano RADIUS server multipli, un server primario e un set di server alternativi. Quando deve passare su un server alternativo, il NAS non sa se quest'ultimo è raggiungibile; questo può comportare un notevole ritardo per gli utenti, finché venga trovata un'alternativa utile. Con un layer di trasporto orientato alla connessione e grazie ai messaggi Diameter keepalive, un nodo Diameter ha la possibilità di accorgersi della configurazione della rete, e anche di ritornare sul server primario quando esso ritorna disponibile, senza ritardi né timeout.
  • Uso inefficiente dei server RADIUS in ambienti proxy: sotto RADIUS, tutte le ritrasmissioni sono effettuate dal NAS. I server proxy non ritrasmettono richieste RADIUS; il NAS, non sapendo se la caduta sia locale o remota, può inappropriatamente ritrasmettere a un next hop peer alternativo. Sotto Diameter, ogni nodo che un messaggio attraversa lungo il cammino dall'origine al server rileverà un blocco del proprio next hop peer e ritrasmetterà. Inoltre, un blocco è gestito localmente.
  • Assenza di messaggi server non sollecitati: il protocollo RADIUS non consente ad un server di inviare messaggi non richiesti al NAS. Per le necessarie attività di inizializzazione, le case produttrici hanno ripiegato su soluzioni al di fuori del protocollo RADIUS (ad esempio, SNMP) oppure su soluzioni proprietarie che coinvolgono estensioni di RADIUS ma che spesso compromettono l'interoperabilità. Diameter, che è un protocollo peer-to-peer anziché client-server, permette messaggi di inizializzazione del server. Il protocollo base definisce due tipi di messaggi, uno per richiedere che il client Diameter termini una specifica sessione utente, e un altro per richiedere che il client riautentichi o reautorizzi uno specifico utente.
  • Attacchi replay: il protocollo RADIUS non fornisce prevenzione degli attacchi replay. Un pacchetto vecchio può essere reinviato da un finto NAS malizioso senza che venga rilevato. Questo può produrre un Denial of Service se il server ha un limite di sessioni concorrenti per un utente.
  • Sicurezza solo hop-by-hop e non end-to-end: il protocollo RADIUS offre sicurezza soltanto hop-by-hop e non contiene facilitazioni per rendere sicuri i peer intermedi tra il NAS e il server. Ciò consente ai server proxy di collezionare informazioni confidenziali o di modificare i messaggi (ad esempio le informazioni di accounting) senza che gli endpoint se ne accorgano. Il protocollo Diameter offre sicurezza end-to-end in aggiunta a quella hop-by-hop. Le firme digitali assicurano l'integrità dei peer coinvolti, e la loro confidenzialità è assicurata dalla crittografia.
  • Nessun supporto per i comandi vendor-specific: il protocollo RADIUS supporta attributi vendor-specific, ma non i comandi. Ciò ha fatto sì che i codici dei comandi privati creati dalle case produttrici hanno creato problemi di interoperabilità. Il protocollo Diameter supporta sia gli attributi sia i comandi vendor-specific.
  • Nessun requisito di allineamento: il protocollo RADIUS non impone requisiti di allineamento, che potrebbe sovraccaricare inutilmente molti processori. Tutti i campi all'interno dell'header e gli attributi devono essere trattati byte a byte. Il protocollo Diameter richiede che tutti gli attributi siano allineati con parole di 32 bit, così come i campi nell'header del messaggio.
  • Segreto condiviso obbligatorio: il protocollo RADIUS richiede che esista un segreto condiviso tra i peer, anche se è impiegato IPSec su una comunicazione locale. Il protocollo Diameter può assicurare comunicazioni tra peer sia con IPSec che con TLS.

Dettagli sul protocollo

[modifica | modifica wikitesto]

Struttura

[modifica | modifica wikitesto]

Diameter è definito in termini di un protocollo base e di un set di applicazioni. Questa progettazione consente al protocollo di essere esteso a nuove tecnologie d'accesso. Il protocollo base fornisce meccanismi di base per un trasporto affidabile, delivery dei messaggi e gestione degli errori, e deve essere utilizzato in concomitanza con un'applicazione Diameter. Ogni applicazione si affida ai servizi del protocollo base per supportare uno specifico tipo di accesso alla rete. Le due principali applicazioni sono Mobile IPv4 e NASREQ (Network Access Server Requirements). L'applicazione NASREQ supporta PPP/IP dial-in ed è inteso come sostituto di RADIUS.

Il protocollo base definisce il formato di un messaggio Diameter di base. I dati sono trasportati nel messaggio Diameter come collezione di AVP (Attribute Value Pair); un AVP è l'equivalente di un attributo RADIUS e consiste di campi multipli: AVP Code, Length, Flags e Data. Alcuni AVP sono utilizzati dal protocollo base di Diameter; altri AVP servono alle applicazioni Diameter; altri ancora possono essere usati dall'applicazione di alto livello dell'end system che impiega Diameter.

Diameter, a differenza di RADIUS, opera su un layer di trasporto affidabile (TCP o SCTP) che fornisce controllo di flusso, conferme a livello trasporto e ritrasmissioni. Mentre TCP è universalmente noto, Stream Control Transmission Protocol (SCTP) è qualcosa di simile ad un nuovo protocollo di trasporto IP, esistente allo stesso livello di UDP o TCP. Nel 2000 SCTP è stato proposto come standard ed è specificato nella RFC 2960.

Definizioni

[modifica | modifica wikitesto]

Oltre a client e server, il protocollo Diameter definisce altri tipi di nodi:

  • un Client Diameter è un dispositivo che accede alla rete in maniera controllata. Anche un NAS è un client Diameter;
  • un Server Diameter è l'entità che gestisce le richieste di autenticazione, autorizzazione e accounting per un dominio;
  • un Relay Agent si occupa del routing dei messaggi Diameter basandosi sulle informazioni contenute nel messaggio. Le decisioni di routing vengono prese usando una lista di domini supportati e peer conosciuti. I Relay Agent sono trasparenti; possono modificare i messaggi solo inserendo o cancellando informazioni di routing, ma non possono modificare altre porzioni del messaggio;
  • un Proxy Agent si occupa anch'esso del routing; può modificare i messaggi per implementare decisioni di policy, come ad esempio il controllo di utilizzo delle risorse;
  • un Redirect Agent si occupa ancora del routing, generalmente agendo come sorgente centralizzata di mappe di indirizzi di dominio per i membri dello stesso. Diversamente dagli altri tipi di agent, un Redirect Agent restituisce uno speciale tipo di messaggio di risposta al peer che ha inviato la richiesta. Questo messaggio di risposta contiene informazioni di routing che consentono al peer di reinviare la richiesta, direttamente alla corretta destinazione. Un Redirect Agent non ritarda le richieste;
  • un Translation Agent effettua “traduzioni” tra protocolli diversi, per esempio da RADIUS a Diameter. In questo caso, il Translation Agent supporta la migrazione da RADIUS a Diameter, consentendo conversioni del server a Diameter, per esempio.

Specifiche

[modifica | modifica wikitesto]

Un messaggio Diameter consiste di un header di lunghezza fissa di 20 byte, seguito da un numero variabile di AVP. Il formato dell'header è il seguente: 

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version     |                                             |
|0 0 0 0 0 0 0 1|              Message Length                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Flags     |                                             |
|R P E T x x x x|              Command-Code                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Application-ID                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Hop-by-hop Identifier                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      End-to-End Identifier                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

L'header del messaggio Diameter contiene due identificatori da 32 bit. L'Hop-by-hop Identifier aiuta nella corrispondenza tra richieste e risposte. Nelle richieste, questo identificatore è sostituito ad ogni hop fin quando il messaggio non viene inoltrato alla sua destinazione finale. Il mittente del messaggio di risposta restituisce lo stesso valore che ha trovato nella corrispondente richiesta. L'End-to-end Identifier, assieme all'identità dell'host di origine, è utilizzato per riconoscere messaggi di richiesta duplicati, e non viene mai modificato fino all'arrivo a destinazione della richiesta. Il mittente della risposta restituisce lo stesso valore che ha trovato nella richiesta corrispondente.

Diameter ammette tipi di dati come Integer32, Unsigned32, Integer64, Unsigned64, Float32, Float64, Float128, OctetString e Grouped; un AVP Grouped è un AVP i cui dati sono una sequenza di AVP.

Sono definiti anche tipi di dati derivati: enumerativi (derivati da integer32), DiameterIdentity (derivati da octetstring), temporali (derivati da unsigned32), UTF8String (derivati da octetstring), IPFilterRule (derivati da octetstring), e QoSFilterRule (derivati da octetstring).

Ogni processo Diameter che gira su un host genera una Diameter Identity, che è una stringa con la sintassi di un Uniform Resource Identifier (URI) che rappresenta il FQDN (Fully Qualified Domain Name) dell'host, una delle porte in ascolto per connessioni in entrata, il protocollo di trasporto (TCP o SCTP), il protocollo AAA (Diameter), e il security transport (nessuno o TLS).

Poiché l'identità trasporta il FQDN dell'host, e poiché più processi Diameter su un singolo host non possono stare in ascolto sulla stessa porta di un dato protocollo, il DiameterIdentity di ogni processo ha la garanzia di essere unico.

Per quanto riguarda i messaggi, ce ne sono di due tipi: Richiesta e Risposta. Ogni messaggio di risposta include un Result-Code AVP, il cui valore è un intero che indica se una particolare richiesta è stata completata con successo oppure se si è verificato un errore. Ciascun messaggio Diameter contiene la Diameter Identity del processo mittente nell'host di origine, ed anche il dominio di tale processo. I messaggi di richiesta possono essere “proxiable” o “non-proxiable”, a seconda di uno dei flag nell'header. Le richieste non-proxiable sono intese strettamente per il next-hop peer, e non vengono mai inoltrate oltre. Le richieste proxiable sono instradabili, e instradate a seconda del dominio. Ogni richiesta proxiable contiene il dominio target nel Destination-Realm AVP.

Un messaggio Diameter pertinente a una specifica sessione utente include un Session-Id AVP, un valore costante per tutta la vita della sessione. Questo valore è una stringa di testo globalmente ed eternamente unica, atta a identificare univocamente una sessione utente senza far riferimento a nessun'altra informazione. Il client Diameter che avvia la sessione crea il Session-Id, il quale inizia con la stringa Diameter Identity del mittente e continua con una sequenza che garantisce unicità sia topologica sia temporale.

Elenco dei comandi

[modifica | modifica wikitesto]

Ogni comando è contraddistinto da un codice, utilizzato sia per le richieste che per le risposte:

Comando Abbr. Codice
Abort-Session-Request ASR 274
Abort-Session-Answer ASA 274
Accounting-Request ACR 271
Accounting-Answer ACA 271
Capabilities-Exchange-Request CER 257
Capabilities-Exchange-Answer CEA 257
Device-Watchdog-Request DWR 280
Device-Watchdog-Answer DWA 280
Disconnect-Peer-Request DPR 282
Disconnect-Peer-Answer DPA 282
Re-Auth-Request RAR 258
Re-Auth-Answer RAA 258
Session-Termination-Request STR 275
Session-Termination-Answer STA 275
Credit-Control-Request CCR 272
Credit-Control-Answer CCA 272

Attribute-Value Pairs (AVP)

[modifica | modifica wikitesto]

Il formato dell'header di un AVP Diameter è il seguente: 

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      AVP Code                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Flags     |                                             |
|V M P x x x x x|                AVP Length                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Vendor-ID (if vendor-specific AVP)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   AVP Data ... (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

L'AVP Code, assieme al campo Vendor-ID, identificano univocamente l'attributo. I primi 256 numeri, assieme al Vendor-ID settato a zero, sono riservati per compatibilità all'indietro con RADIUS. Il campo AVP Data è formato da zero o più ottetti e contiene informazioni specifiche dell'Attributo. I campi AVP Code e AVP Length determinano il formato e la lunghezza del campo Data.

Attribute-Name Code Data Type
Acct-Interim-Interval 85 Unsigned32
Accounting-Realtime-Required 483 Enumerated
Acct-Multi-Session-Id 50 UTF8String
Accounting-Record-Number 485 Unsigned32
Accounting-Record-Type 480 Enumerated
Accounting-Session-Id 44 OctetString
Accounting-Sub-Session-Id 287 Unsigned64
Acct-Application-Id 259 Unsigned32
Auth-Application-Id 258 Unsigned32
Auth-Request-Type 274 Enumerated
Authorization-Lifetime 291 Unsigned32
Auth-Grace-Period 276 Unsigned32
Auth-Session-State 277 Enumerated
Re-Auth-Request-Type 285 Enumerated
CC-Request-Type 416 Unsigned32
CC-Request-Number 415 Unsigned32
Class 25 OctetString
Destination-Host 293 DiamIdent
Destination-Realm 283 DiamIdent
Disconnect-Cause 273 Enumerated
E2E-Sequence 300 Grouped
Error-Message 281 UTF8String
Error-Reporting-Host 294 DiamIdent
Event-Timestamp 55 Time
Experimental-Result 297 Grouped
Experimental-Result-Code 298 Unsigned32
Failed-AVP 279 Grouped
Firmware-Revision 267 Unsigned32
Host-IP-Address 257 Address
Inband-Security-Id 299 Unsigned32
Multi-Round-Time-Out 272 Unsigned32
Origin-Host 264 DiamIdent
Origin-Realm 296 DiamIdent
Origin-State-Id 278 Unsigned32
Product-Name 269 UTF8String
Proxy-Host 280 DiamIdent
Proxy-Info 284 Grouped
Proxy-State 33 OctetString
Redirect-Host 292 DiamURI
Redirect-Host-Usage 261 Enumerated
Redirect-Max-Cache-Time 262 Unsigned32
Result-Code 268 Unsigned32
Route-Record 282 DiamIdent
Session-Id 263 UTF8String
Session-Timeout 27 Unsigned32
Session-Binding 270 Unsigned32
Session-Server-Failover 271 Enumerated
Supported-Vendor-Id 265 Unsigned32
Termination-Cause 295 Enumerated
User-Name 1 UTF8String
Vendor-Id 266 Unsigned32
Vendor-Specific-Application-Id 260 Grouped

Collegamenti esterni

[modifica | modifica wikitesto]
Controllo di autoritàGND (DE) 7625755-1
  Portale Sicurezza informatica
  Portale Telematica