4.3.1. Common Derived AVP Data Formats
I seguenti sono formati di dati AVP derivati comunemente utilizzati.
Address
Il formato Address è derivato dal formato AVP di base OctetString. È un'unione discriminata che rappresenta, ad esempio, un indirizzo a 32 bit (IPv4) [RFC0791] o 128 bit (IPv6) [RFC4291], ottetto più significativo per primo. I primi due ottetti dell'AVP Address rappresentano l'AddressType, che contiene una famiglia di indirizzi definita in [IANAADFAM]. L'AddressType viene utilizzato per discriminare il contenuto e il formato degli ottetti rimanenti.
Time
Il formato Time è derivato dal formato AVP di base OctetString. La stringa DEVE contenere quattro ottetti, nello stesso formato dei primi quattro byte nel formato timestamp NTP. Il formato timestamp NTP è definito nella Sezione 3 di [RFC5905].
Questo rappresenta il numero di secondi dall'0h del 1° gennaio 1900 rispetto al tempo coordinato universale (UTC).
Il 7 febbraio 2036 alle 6h 28m 16s UTC, il valore temporale andrà in overflow. Il Simple Network Time Protocol (SNTP) [RFC5905] descrive una procedura per estendere il tempo al 2104. Questa procedura DEVE essere supportata da tutti i nodi Diameter.
UTF8String
Il formato UTF8String è derivato dal formato AVP di base OctetString. Questa è una stringa leggibile dall'uomo rappresentata utilizzando il set di caratteri ISO/IEC IS 10646-1, codificata come OctetString utilizzando il formato di trasformazione UTF-8 [RFC3629].
Poiché periodicamente vengono aggiunti punti di codice aggiuntivi tramite emendamenti allo standard 10646, le implementazioni DEVONO essere preparate a incontrare qualsiasi punto di codice da 0x00000001 a 0x7fffffff. Le sequenze di byte che non corrispondono alla codifica valida di un punto di codice nel set di caratteri UTF-8 o sono al di fuori di questo intervallo sono proibite.
L'uso di codici di controllo DOVREBBE essere evitato. Quando è necessario rappresentare una nuova riga, DOVREBBE essere utilizzata la sequenza di codici di controllo CR LF.
L'uso di spazi bianchi iniziali o finali DOVREBBE essere evitato.
Per i punti di codice non direttamente supportati dall'hardware o dal software dell'interfaccia utente, PUÒ essere fornito un mezzo alternativo di input e visualizzazione, come l'esadecimale.
Per le informazioni codificate in US-ASCII a 7 bit, il set di caratteri UTF-8 è identico al set di caratteri US-ASCII.
UTF-8 può richiedere più byte per rappresentare un singolo carattere / punto di codice; pertanto, la lunghezza di una UTF8String in ottetti può essere diversa dal numero di caratteri codificati.
Si noti che il campo AVP Length di una UTF8String è misurato in ottetti e non in caratteri.
DiameterIdentity
Il formato DiameterIdentity è derivato dal formato AVP di base OctetString.
DiameterIdentity = FQDN/Realm
Il valore DiameterIdentity viene utilizzato per identificare in modo univoco:
-
Un nodo Diameter per scopi di rilevamento di connessioni duplicate e loop di routing.
-
Un Realm per determinare se i messaggi possono essere soddisfatti localmente o se devono essere instradati o reindirizzati.
Quando un valore DiameterIdentity viene utilizzato per identificare un nodo Diameter, il contenuto della stringa DEVE essere il nome di dominio completamente qualificato (FQDN) del nodo Diameter. Se più nodi Diameter vengono eseguiti sullo stesso host, a ciascun nodo Diameter DEVE essere assegnata una DiameterIdentity univoca. Se un nodo Diameter può essere identificato da più FQDN, un singolo FQDN dovrebbe essere scelto all'avvio e utilizzato come unica DiameterIdentity per quel nodo, indipendentemente dalla connessione su cui viene inviato. In questo documento, si noti che DiameterIdentity è in forma ASCII per essere compatibile con l'infrastruttura DNS esistente. Vedere l'Appendice D per le interazioni tra il protocollo Diameter e i nomi di dominio internazionalizzati (IDN).
DiameterURI
Il DiameterURI DEVE seguire le regole di sintassi degli identificatori di risorse uniformi (RFC3986) [RFC3986] specificate di seguito:
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; Nessuna sicurezza di trasporto
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Sicurezza di trasporto utilizzata
FQDN = < Nome di dominio completamente qualificato >
port = ":" 1*DIGIT
; Una delle porte utilizzate per ascoltare le
; connessioni in entrata.
; Se assente, si presume la porta Diameter predefinita
; (3868) se non viene utilizzata alcuna sicurezza di
; trasporto e la porta 5658 quando viene utilizzata
; la sicurezza di trasporto (TLS/TCP e DTLS/SCTP).
transport = ";transport=" transport-protocol
; Uno dei trasporti utilizzati per ascoltare le
; connessioni in entrata. Se assente, si presume che
; il protocollo predefinito sia TCP.
; UDP NON DEVE essere utilizzato quando il campo
; aaa-protocol è impostato su diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; Se assente, il protocollo AAA predefinito è Diameter.
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
I seguenti sono esempi di identità host Diameter valide:
aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius
Enumerated
Il formato Enumerated è derivato dal formato AVP di base Integer32. La definizione contiene un elenco di valori validi e la loro interpretazione ed è descritta nell'applicazione Diameter che introduce l'AVP.
IPFilterRule
Il formato IPFilterRule è derivato dal formato AVP di base OctetString e utilizza il set di caratteri ASCII. La sintassi delle regole è un sottoinsieme modificato di ipfw(8) di FreeBSD. I pacchetti possono essere filtrati in base alle seguenti informazioni ad essi associate:
Direction (in o out)
Source and destination IP address (possibilmente mascherato)
Protocol
Source and destination port (elenchi o intervalli)
TCP flags
IP fragment flag
IP options
ICMP types
Le regole per la direzione appropriata vengono valutate in ordine, con la prima regola corrispondente che termina la valutazione. Ogni pacchetto viene valutato una volta. Se nessuna regola corrisponde, il pacchetto viene scartato se l'ultima regola valutata era un permit, e passato se l'ultima regola era un deny.
I filtri IPFilterRule DEVONO seguire il formato:
action dir proto from src to dst [options]
action permit - Consenti i pacchetti che corrispondono alla regola.
deny - Scarta i pacchetti che corrispondono alla regola.
dir "in" proviene dal terminale, "out" va verso il terminale.
proto Un protocollo IP specificato da un numero. La parola
chiave "ip" significa che qualsiasi protocollo
corrisponderà.
src and dst <address/mask> [ports]
L'<address/mask> può essere specificato come:
ipno Un numero IPv4 o IPv6 in notazione decimale
puntata o forma IPv6 canonica. Solo questo
numero IP esatto corrisponderà alla regola.
ipno/bits Un numero IP come sopra con una larghezza di
maschera della forma 192.0.2.10/24. In questo
caso, tutti i numeri IP da 192.0.2.0 a
192.0.2.255 corrisponderanno. La larghezza dei
bit DEVE essere valida per la versione IP, e il
numero IP NON DEVE avere bit impostati oltre la
maschera. Affinché si verifichi una corrispondenza,
la stessa versione IP deve essere presente nel
pacchetto che è stata utilizzata per descrivere
l'indirizzo IP. Per testare una particolare
versione IP, la parte dei bit può essere
impostata a zero. La parola chiave "any" è
0.0.0.0/0 o l'equivalente IPv6. La parola chiave
"assigned" è l'indirizzo o l'insieme di indirizzi
assegnati al terminale. Per IPv4, una tipica prima
regola è spesso "deny in ip! assigned".
Il senso della corrispondenza può essere invertito
precedendo un indirizzo con il modificatore not (!),
facendo corrispondere invece tutti gli altri indirizzi.
Ciò non influisce sulla selezione dei numeri di porta.
Con i protocolli TCP, UDP e SCTP, le porte opzionali
possono essere specificate come:
{port/port-port}[,ports[,...]]
La notazione '-' specifica un intervallo di porte
(inclusi i confini).
I pacchetti frammentati che hanno un offset diverso da
zero (cioè, non il primo frammento) non corrisponderanno
mai a una regola che ha una o più specifiche di porta.
Vedere l'opzione frag per dettagli sulla corrispondenza
dei pacchetti frammentati.
options:
frag Corrisponde se il pacchetto è un frammento e questo non
è il primo frammento del datagramma. frag non può essere
utilizzato in combinazione con tcpflags o specifiche di
porta TCP/UDP.
ipoptions spec
Corrisponde se l'intestazione IP contiene l'elenco di
opzioni separate da virgole specificato in spec. Le
opzioni IP supportate sono:
ssrr (instradamento sorgente rigoroso), lsrr
(instradamento sorgente libero), rr (registrazione percorso
pacchetto) e ts (timestamp). L'assenza di un'opzione
particolare può essere indicata con un '!'.
tcpoptions spec
Corrisponde se l'intestazione TCP contiene l'elenco di
opzioni separate da virgole specificato in spec. Le
opzioni TCP supportate sono:
mss (dimensione massima del segmento), window (annuncio
finestra tcp), sack (riconoscimento selettivo), ts
(timestamp rfc1323) e cc (conteggio connessioni t/tcp
rfc1644). L'assenza di un'opzione particolare può essere
indicata con un '!'.
established
Solo pacchetti TCP. Corrisponde ai pacchetti che hanno i
bit RST o ACK impostati.
setup Solo pacchetti TCP. Corrisponde ai pacchetti che hanno il
bit SYN impostato ma nessun bit ACK.
tcpflags spec
Solo pacchetti TCP. Corrisponde se l'intestazione TCP
contiene l'elenco di flag separati da virgole specificato
in spec. I flag TCP supportati sono:
fin, syn, rst, psh, ack e urg. L'assenza di un flag
particolare può essere indicata con un '!'. Una regola che
contiene una specifica tcpflags non può mai corrispondere
a un pacchetto frammentato che ha un offset diverso da zero.
Vedere l'opzione frag per dettagli sulla corrispondenza dei
pacchetti frammentati.
icmptypes types
Solo pacchetti ICMP. Corrisponde se il tipo ICMP è
nell'elenco types. L'elenco può essere specificato come
qualsiasi combinazione di intervalli o tipi individuali
separati da virgole. Possono essere utilizzati sia i valori
numerici che i valori simbolici elencati di seguito. I tipi
ICMP supportati sono:
echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17)
e address mask reply (18).
C'è un tipo di pacchetto che il dispositivo di accesso DEVE sempre scartare, ovvero un frammento IP con un offset di frammento di uno. Questo è un pacchetto valido, ma ha un solo uso: tentare di aggirare i firewall.
Un dispositivo di accesso che non è in grado di interpretare o applicare una regola deny DEVE terminare la sessione. Un dispositivo di accesso che non è in grado di interpretare o applicare una regola permit PUÒ applicare una regola più restrittiva. Un dispositivo di accesso PUÒ applicare proprie regole deny prima delle regole fornite, ad esempio per proteggere l'infrastruttura del proprietario del dispositivo di accesso.