4.3.1. Common Derived AVP Data Formats
Die folgenden sind häufig verwendete abgeleitete AVP-Datenformate.
Address
Das Address-Format ist vom OctetString Basic AVP Format abgeleitet. Es ist eine diskriminierte Union, die beispielsweise eine 32-Bit- (IPv4) [RFC0791] oder 128-Bit- (IPv6) [RFC4291] Adresse darstellt, wobei das höchstwertige Oktett zuerst kommt. Die ersten beiden Oktette des Address AVP stellen den AddressType dar, der eine in [IANAADFAM] definierte Adressfamilie enthält. Der AddressType wird verwendet, um den Inhalt und das Format der verbleibenden Oktette zu unterscheiden.
Time
Das Time-Format ist vom OctetString Basic AVP Format abgeleitet. Die Zeichenfolge MUSS vier Oktette enthalten, im gleichen Format wie die ersten vier Bytes im NTP-Zeitstempelformat. Das NTP-Zeitstempelformat ist in Abschnitt 3 von [RFC5905] definiert.
Dies stellt die Anzahl der Sekunden seit 0h am 1. Januar 1900 in Bezug auf die koordinierte Weltzeit (UTC) dar.
Am 7. Februar 2036 um 6h 28m 16s UTC wird der Zeitwert überlaufen. Das Simple Network Time Protocol (SNTP) [RFC5905] beschreibt ein Verfahren zur Verlängerung der Zeit bis 2104. Dieses Verfahren MUSS von allen Diameter-Knoten unterstützt werden.
UTF8String
Das UTF8String-Format ist vom OctetString Basic AVP Format abgeleitet. Dies ist eine menschenlesbare Zeichenfolge, die unter Verwendung des ISO/IEC IS 10646-1-Zeichensatzes dargestellt und als OctetString unter Verwendung des UTF-8-Transformationsformats [RFC3629] kodiert wird.
Da dem 10646-Standard von Zeit zu Zeit durch Änderungen zusätzliche Codepunkte hinzugefügt werden, MÜSSEN Implementierungen darauf vorbereitet sein, auf jeden Codepunkt von 0x00000001 bis 0x7fffffff zu stoßen. Bytesequenzen, die nicht der gültigen Kodierung eines Codepunkts in den UTF-8-Zeichensatz entsprechen oder außerhalb dieses Bereichs liegen, sind verboten.
Die Verwendung von Steuerungscodes SOLLTE vermieden werden. Wenn es notwendig ist, eine neue Zeile darzustellen, SOLLTE die Steuerungscodesequenz CR LF verwendet werden.
Die Verwendung von führenden oder nachfolgenden Leerzeichen SOLLTE vermieden werden.
Für Codepunkte, die nicht direkt von Hardware oder Software der Benutzerschnittstelle unterstützt werden, KANN ein alternatives Mittel zur Eingabe und Anzeige, wie z.B. hexadezimal, bereitgestellt werden.
Für Informationen, die in 7-Bit US-ASCII kodiert sind, ist der UTF-8-Zeichensatz identisch mit dem US-ASCII-Zeichensatz.
UTF-8 kann mehrere Bytes erfordern, um ein einzelnes Zeichen / einen einzelnen Codepunkt darzustellen; daher kann die Länge einer UTF8String in Oktetten von der Anzahl der kodierten Zeichen abweichen.
Beachten Sie, dass das AVP Length-Feld einer UTF8String in Oktetten und nicht in Zeichen gemessen wird.
DiameterIdentity
Das DiameterIdentity-Format ist vom OctetString Basic AVP Format abgeleitet.
DiameterIdentity = FQDN/Realm
Der DiameterIdentity-Wert wird verwendet, um eindeutig zu identifizieren:
-
Einen Diameter-Knoten für Zwecke der Erkennung doppelter Verbindungen und Routing-Schleifen.
-
Einen Realm, um zu bestimmen, ob Nachrichten lokal erfüllt werden können oder ob sie geroutet oder umgeleitet werden müssen.
Wenn ein DiameterIdentity-Wert verwendet wird, um einen Diameter-Knoten zu identifizieren, MUSS der Inhalt der Zeichenfolge der vollqualifizierte Domänenname (FQDN) des Diameter-Knotens sein. Wenn mehrere Diameter-Knoten auf demselben Host ausgeführt werden, MUSS jedem Diameter-Knoten eine eindeutige DiameterIdentity zugewiesen werden. Wenn ein Diameter-Knoten durch mehrere FQDNs identifiziert werden kann, sollte beim Start ein einzelner FQDN ausgewählt und als einzige DiameterIdentity für diesen Knoten verwendet werden, unabhängig von der Verbindung, über die er gesendet wird. Beachten Sie in diesem Dokument, dass DiameterIdentity in ASCII-Form vorliegt, um mit der vorhandenen DNS-Infrastruktur kompatibel zu sein. Siehe Anhang D für Interaktionen zwischen dem Diameter-Protokoll und internationalisierten Domainnamen (IDNs).
DiameterURI
Der DiameterURI MUSS den unten angegebenen Syntaxregeln für Uniform Resource Identifiers (RFC3986) [RFC3986] folgen:
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; Keine Transportsicherheit
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transportsicherheit verwendet
FQDN = < Vollqualifizierter Domänenname >
port = ":" 1*DIGIT
; Einer der Ports, die zum Abhören eingehender
; Verbindungen verwendet werden.
; Falls nicht vorhanden, wird der Standard-Diameter-Port
; (3868) angenommen, wenn keine Transportsicherheit
; verwendet wird, und Port 5658, wenn Transportsicherheit
; (TLS/TCP und DTLS/SCTP) verwendet wird.
transport = ";transport=" transport-protocol
; Einer der Transporte, die zum Abhören eingehender
; Verbindungen verwendet werden. Falls nicht vorhanden,
; wird das Standardprotokoll als TCP angenommen.
; UDP DARF NICHT verwendet werden, wenn das
; aaa-protocol-Feld auf diameter gesetzt ist.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; Falls nicht vorhanden, ist das Standard-AAA-Protokoll
; Diameter.
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
Die folgenden sind Beispiele für gültige Diameter-Hostidentitäten:
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
Das Enumerated-Format ist vom Integer32 Basic AVP Format abgeleitet. Die Definition enthält eine Liste gültiger Werte und deren Interpretation und wird in der Diameter-Anwendung beschrieben, die das AVP einführt.
IPFilterRule
Das IPFilterRule-Format ist vom OctetString Basic AVP Format abgeleitet und verwendet den ASCII-Zeichensatz. Die Regelsyntax ist eine modifizierte Teilmenge von ipfw(8) aus FreeBSD. Pakete können basierend auf den folgenden damit verbundenen Informationen gefiltert werden:
Direction (ein oder aus)
Source and destination IP address (möglicherweise maskiert)
Protocol
Source and destination port (Listen oder Bereiche)
TCP flags
IP fragment flag
IP options
ICMP types
Regeln für die entsprechende Richtung werden in der Reihenfolge ausgewertet, wobei die erste übereinstimmende Regel die Auswertung beendet. Jedes Paket wird einmal ausgewertet. Wenn keine Regel übereinstimmt, wird das Paket verworfen, wenn die zuletzt ausgewertete Regel ein permit war, und durchgelassen, wenn die letzte Regel ein deny war.
IPFilterRule-Filter MÜSSEN dem folgenden Format folgen:
action dir proto from src to dst [options]
action permit - Pakete zulassen, die der Regel entsprechen.
deny - Pakete verwerfen, die der Regel entsprechen.
dir "in" kommt vom Terminal, "out" geht zum Terminal.
proto Ein durch eine Nummer spezifiziertes IP-Protokoll. Das
Schlüsselwort "ip" bedeutet, dass jedes Protokoll passt.
src and dst <address/mask> [ports]
Die <address/mask> kann wie folgt angegeben werden:
ipno Eine IPv4- oder IPv6-Nummer in gepunkteter
Quad-Notation oder kanonischer IPv6-Form.
Nur diese exakte IP-Nummer passt zur Regel.
ipno/bits Eine IP-Nummer wie oben mit einer Maskenbreite
der Form 192.0.2.10/24. In diesem Fall passen
alle IP-Nummern von 192.0.2.0 bis 192.0.2.255.
Die Bitbreite MUSS für die IP-Version gültig
sein, und die IP-Nummer DARF KEINE Bits
jenseits der Maske gesetzt haben. Damit eine
Übereinstimmung auftritt, muss dieselbe
IP-Version im Paket vorhanden sein, die beim
Beschreiben der IP-Adresse verwendet wurde.
Um eine bestimmte IP-Version zu testen, kann
der Bitsteil auf Null gesetzt werden. Das
Schlüsselwort "any" ist 0.0.0.0/0 oder das
IPv6-Äquivalent. Das Schlüsselwort "assigned"
ist die dem Terminal zugewiesene Adresse oder
der Adresssatz. Für IPv4 lautet eine typische
erste Regel oft "deny in ip! assigned".
Der Sinn der Übereinstimmung kann umgekehrt werden,
indem einer Adresse der Not-Modifikator (!) vorangestellt
wird, wodurch stattdessen alle anderen Adressen passen.
Dies beeinflusst die Auswahl der Portnummern nicht.
Bei den Protokollen TCP, UDP und SCTP können optionale
Ports wie folgt angegeben werden:
{port/port-port}[,ports[,...]]
Die '-'-Notation gibt einen Portbereich an
(einschließlich Grenzen).
Fragmentierte Pakete, die einen Nicht-Null-Offset haben
(d.h. nicht das erste Fragment), passen niemals zu einer
Regel, die eine oder mehrere Portspezifikationen hat.
Siehe die frag-Option für Details zum Abgleich
fragmentierter Pakete.
options:
frag Passt, wenn das Paket ein Fragment ist und dies nicht
das erste Fragment des Datagramms ist. frag darf nicht
in Verbindung mit tcpflags oder TCP/UDP-Portspezifikationen
verwendet werden.
ipoptions spec
Passt, wenn der IP-Header die in spec angegebene
kommagetrennte Liste von Optionen enthält. Die
unterstützten IP-Optionen sind:
ssrr (strikte Quellenroute), lsrr (lose Quellenroute),
rr (Paketroute aufzeichnen) und ts (Zeitstempel). Das
Fehlen einer bestimmten Option kann mit einem '!'
gekennzeichnet werden.
tcpoptions spec
Passt, wenn der TCP-Header die in spec angegebene
kommagetrennte Liste von Optionen enthält. Die
unterstützten TCP-Optionen sind:
mss (maximale Segmentgröße), window (TCP-Fenster-
Ankündigung), sack (selektive Bestätigung), ts
(rfc1323-Zeitstempel) und cc (rfc1644 t/tcp-
Verbindungszählung). Das Fehlen einer bestimmten Option
kann mit einem '!' gekennzeichnet werden.
established
Nur TCP-Pakete. Passt zu Paketen, bei denen die RST-
oder ACK-Bits gesetzt sind.
setup Nur TCP-Pakete. Passt zu Paketen, bei denen das SYN-Bit
gesetzt ist, aber kein ACK-Bit.
tcpflags spec
Nur TCP-Pakete. Passt, wenn der TCP-Header die in spec
angegebene kommagetrennte Liste von Flags enthält. Die
unterstützten TCP-Flags sind:
fin, syn, rst, psh, ack und urg. Das Fehlen eines
bestimmten Flags kann mit einem '!' gekennzeichnet werden.
Eine Regel, die eine tcpflags-Spezifikation enthält, kann
niemals zu einem fragmentierten Paket passen, das einen
Nicht-Null-Offset hat. Siehe die frag-Option für Details
zum Abgleich fragmentierter Pakete.
icmptypes types
Nur ICMP-Pakete. Passt, wenn der ICMP-Typ in der Liste
types enthalten ist. Die Liste kann als beliebige
Kombination von Bereichen oder einzelnen Typen angegeben
werden, die durch Kommas getrennt sind. Sowohl die
numerischen Werte als auch die unten aufgeführten
symbolischen Werte können verwendet werden. Die
unterstützten ICMP-Typen sind:
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)
und address mask reply (18).
Es gibt eine Art von Paket, das das Zugriffsgerät immer verwerfen MUSS, nämlich ein IP-Fragment mit einem Fragment-Offset von eins. Dies ist ein gültiges Paket, hat aber nur eine Verwendung: den Versuch, Firewalls zu umgehen.
Ein Zugriffsgerät, das eine Deny-Regel nicht interpretieren oder anwenden kann, MUSS die Sitzung beenden. Ein Zugriffsgerät, das eine Permit-Regel nicht interpretieren oder anwenden kann, KANN eine restriktivere Regel anwenden. Ein Zugriffsgerät KANN vor den gelieferten Regeln eigene Deny-Regeln anwenden, beispielsweise zum Schutz der Infrastruktur des Zugriffsgerätbesitzers.