4.3.1. Common Derived AVP Data Formats
Les formats de données AVP dérivés suivants sont couramment utilisés.
Address
Le format Address est dérivé du format AVP de base OctetString. Il s'agit d'une union discriminée représentant, par exemple, une adresse de 32 bits (IPv4) [RFC0791] ou 128 bits (IPv6) [RFC4291], octet le plus significatif en premier. Les deux premiers octets de l'AVP Address représentent l'AddressType, qui contient une famille d'adresses définie dans [IANAADFAM]. L'AddressType est utilisé pour discriminer le contenu et le format des octets restants.
Time
Le format Time est dérivé du format AVP de base OctetString. La chaîne DOIT contenir quatre octets, dans le même format que les quatre premiers octets du format d'horodatage NTP. Le format d'horodatage NTP est défini dans la Section 3 de [RFC5905].
Ceci représente le nombre de secondes depuis 0h le 1er janvier 1900 par rapport au temps universel coordonné (UTC).
Le 7 février 2036 à 6h 28m 16s UTC, la valeur temporelle débordera. Le protocole de temps réseau simple (SNTP) [RFC5905] décrit une procédure pour étendre le temps jusqu'en 2104. Cette procédure DOIT être prise en charge par tous les nœuds Diameter.
UTF8String
Le format UTF8String est dérivé du format AVP de base OctetString. Il s'agit d'une chaîne lisible par l'homme représentée à l'aide du jeu de caractères ISO/IEC IS 10646-1, encodée en tant qu'OctetString en utilisant le format de transformation UTF-8 [RFC3629].
Étant donné que des points de code supplémentaires sont ajoutés par des amendements à la norme 10646 de temps en temps, les implémentations DOIVENT être préparées à rencontrer n'importe quel point de code de 0x00000001 à 0x7fffffff. Les séquences d'octets qui ne correspondent pas à l'encodage valide d'un point de code dans le jeu de caractères UTF-8 ou qui sont en dehors de cette plage sont interdites.
L'utilisation de codes de contrôle DEVRAIT être évitée. Lorsqu'il est nécessaire de représenter une nouvelle ligne, la séquence de codes de contrôle CR LF DEVRAIT être utilisée.
L'utilisation d'espaces blancs de début ou de fin DEVRAIT être évitée.
Pour les points de code non directement pris en charge par le matériel ou le logiciel de l'interface utilisateur, un moyen alternatif de saisie et d'affichage, tel que l'hexadécimal, PEUT être fourni.
Pour les informations codées en US-ASCII 7 bits, le jeu de caractères UTF-8 est identique au jeu de caractères US-ASCII.
UTF-8 peut nécessiter plusieurs octets pour représenter un seul caractère / point de code ; ainsi, la longueur d'une UTF8String en octets peut être différente du nombre de caractères encodés.
Notez que le champ AVP Length d'une UTF8String est mesuré en octets et non en caractères.
DiameterIdentity
Le format DiameterIdentity est dérivé du format AVP de base OctetString.
DiameterIdentity = FQDN/Realm
La valeur DiameterIdentity est utilisée pour identifier de manière unique soit :
-
Un nœud Diameter à des fins de détection de connexion en double et de boucle de routage.
-
Un Realm pour déterminer si les messages peuvent être satisfaits localement ou s'ils doivent être routés ou redirigés.
Lorsqu'une valeur DiameterIdentity est utilisée pour identifier un nœud Diameter, le contenu de la chaîne DOIT être le nom de domaine pleinement qualifié (FQDN) du nœud Diameter. Si plusieurs nœuds Diameter s'exécutent sur le même hôte, chaque nœud Diameter DOIT se voir attribuer une DiameterIdentity unique. Si un nœud Diameter peut être identifié par plusieurs FQDN, un seul FQDN devrait être choisi au démarrage et utilisé comme seule DiameterIdentity pour ce nœud, quelle que soit la connexion sur laquelle il est envoyé. Dans ce document, notez que DiameterIdentity est au format ASCII afin d'être compatible avec l'infrastructure DNS existante. Voir l'Annexe D pour les interactions entre le protocole Diameter et les noms de domaine internationalisés (IDN).
DiameterURI
Le DiameterURI DOIT suivre les règles de syntaxe des identificateurs de ressources uniformes (RFC3986) [RFC3986] spécifiées ci-dessous :
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; Aucune sécurité de transport
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Sécurité de transport utilisée
FQDN = < Nom de domaine pleinement qualifié >
port = ":" 1*DIGIT
; L'un des ports utilisés pour écouter les
; connexions entrantes.
; S'il est absent, le port Diameter par défaut
; (3868) est supposé si aucune sécurité de transport
; n'est utilisée et le port 5658 lorsque la
; sécurité de transport (TLS/TCP et DTLS/SCTP)
; est utilisée.
transport = ";transport=" transport-protocol
; L'un des transports utilisés pour écouter les
; connexions entrantes. S'il est absent, le
; protocole par défaut est supposé être TCP.
; UDP NE DOIT PAS être utilisé lorsque le champ
; aaa-protocol est défini sur diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; S'il est absent, le protocole AAA par défaut
; est Diameter.
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
Voici des exemples d'identités d'hôte Diameter valides :
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
Le format Enumerated est dérivé du format AVP de base Integer32. La définition contient une liste de valeurs valides et leur interprétation et est décrite dans l'application Diameter introduisant l'AVP.
IPFilterRule
Le format IPFilterRule est dérivé du format AVP de base OctetString et utilise le jeu de caractères ASCII. La syntaxe des règles est un sous-ensemble modifié d'ipfw(8) de FreeBSD. Les paquets peuvent être filtrés en fonction des informations suivantes qui y sont associées :
Direction (entrant ou sortant)
Source and destination IP address (éventuellement masquée)
Protocol
Source and destination port (listes ou plages)
TCP flags
IP fragment flag
IP options
ICMP types
Les règles pour la direction appropriée sont évaluées dans l'ordre, la première règle correspondante terminant l'évaluation. Chaque paquet est évalué une fois. Si aucune règle ne correspond, le paquet est abandonné si la dernière règle évaluée était un permit, et passé si la dernière règle était un deny.
Les filtres IPFilterRule DOIVENT suivre le format :
action dir proto from src to dst [options]
action permit - Autoriser les paquets qui correspondent à la règle.
deny - Abandonner les paquets qui correspondent à la règle.
dir "in" provient du terminal, "out" va vers le terminal.
proto Un protocole IP spécifié par un numéro. Le mot-clé "ip"
signifie que n'importe quel protocole correspondra.
src and dst <address/mask> [ports]
Le <address/mask> peut être spécifié comme :
ipno Un numéro IPv4 ou IPv6 en notation décimale
pointée ou forme IPv6 canonique. Seul ce
numéro IP exact correspondra à la règle.
ipno/bits Un numéro IP comme ci-dessus avec une largeur
de masque de la forme 192.0.2.10/24. Dans ce
cas, tous les numéros IP de 192.0.2.0 à
192.0.2.255 correspondront. La largeur de bits
DOIT être valide pour la version IP, et le
numéro IP NE DOIT PAS avoir de bits définis
au-delà du masque. Pour qu'une correspondance
se produise, la même version IP doit être
présente dans le paquet qui a été utilisée
pour décrire l'adresse IP. Pour tester une
version IP particulière, la partie bits peut
être définie à zéro. Le mot-clé "any" est
0.0.0.0/0 ou l'équivalent IPv6. Le mot-clé
"assigned" est l'adresse ou l'ensemble
d'adresses attribuées au terminal. Pour IPv4,
une première règle typique est souvent "deny
in ip! assigned".
Le sens de la correspondance peut être inversé en
faisant précéder une adresse du modificateur not (!),
ce qui fait que toutes les autres adresses correspondent
à la place. Cela n'affecte pas la sélection des numéros
de port.
Avec les protocoles TCP, UDP et SCTP, des ports
facultatifs peuvent être spécifiés comme :
{port/port-port}[,ports[,...]]
La notation '-' spécifie une plage de ports (y compris
les limites).
Les paquets fragmentés qui ont un décalage non nul
(c'est-à-dire pas le premier fragment) ne correspondront
jamais à une règle qui a une ou plusieurs spécifications
de port. Voir l'option frag pour des détails sur la
correspondance des paquets fragmentés.
options:
frag Correspond si le paquet est un fragment et que ce n'est
pas le premier fragment du datagramme. frag ne peut pas
être utilisé en conjonction avec tcpflags ou des
spécifications de port TCP/UDP.
ipoptions spec
Correspond si l'en-tête IP contient la liste d'options
séparées par des virgules spécifiée dans spec. Les
options IP prises en charge sont :
ssrr (routage source strict), lsrr (routage source
lâche), rr (enregistrement de route de paquet) et ts
(horodatage). L'absence d'une option particulière peut
être indiquée par un '!'.
tcpoptions spec
Correspond si l'en-tête TCP contient la liste d'options
séparées par des virgules spécifiée dans spec. Les
options TCP prises en charge sont :
mss (taille de segment maximale), window (annonce de
fenêtre tcp), sack (accusé de réception sélectif), ts
(horodatage rfc1323) et cc (compte de connexion t/tcp
rfc1644). L'absence d'une option particulière peut être
indiquée par un '!'.
established
Paquets TCP uniquement. Correspond aux paquets qui ont
les bits RST ou ACK définis.
setup Paquets TCP uniquement. Correspond aux paquets qui ont
le bit SYN défini mais pas le bit ACK.
tcpflags spec
Paquets TCP uniquement. Correspond si l'en-tête TCP
contient la liste de drapeaux séparés par des virgules
spécifiée dans spec. Les drapeaux TCP pris en charge sont :
fin, syn, rst, psh, ack et urg. L'absence d'un drapeau
particulier peut être indiquée par un '!'. Une règle qui
contient une spécification tcpflags ne peut jamais
correspondre à un paquet fragmenté qui a un décalage non
nul. Voir l'option frag pour des détails sur la
correspondance des paquets fragmentés.
icmptypes types
Paquets ICMP uniquement. Correspond si le type ICMP est
dans la liste types. La liste peut être spécifiée comme
n'importe quelle combinaison de plages ou de types
individuels séparés par des virgules. Les valeurs
numériques et les valeurs symboliques listées ci-dessous
peuvent être utilisées. Les types ICMP pris en charge sont :
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)
et address mask reply (18).
Il existe un type de paquet que le dispositif d'accès DOIT toujours rejeter, c'est un fragment IP avec un décalage de fragment de un. C'est un paquet valide, mais il n'a qu'une seule utilisation, essayer de contourner les pare-feu.
Un dispositif d'accès qui est incapable d'interpréter ou d'appliquer une règle deny DOIT terminer la session. Un dispositif d'accès qui est incapable d'interpréter ou d'appliquer une règle permit PEUT appliquer une règle plus restrictive. Un dispositif d'accès PEUT appliquer ses propres règles deny avant les règles fournies, par exemple pour protéger l'infrastructure du propriétaire du dispositif d'accès.