5.2. Diameter-Peer-Entdeckung

Dynamische Entdeckung von Diameter-Agenten (agents) vereinfacht den Betrieb. Zur Interoperabilität werden manuelle Konfiguration und DNS beschriehen, basierend auf IETF-Standards. Beides MUSS unterstützt werden; es darf jeweils eines genutzt werden (MAY).

Entdeckung erfolgt, wenn ein Client den ersten Hop-Agenten sucht oder ein Agent einen weiteren Agenten braucht. Empfohlene Suchreihenfolge:

1. Statisch (manuell) konfigurierte Agentenstandorte, falls vorhanden und erreichbar.

2. NAPTR-Abfrage im Realm. Das Realm muss bekannt sein, z. B. aus dem Realm eines NAI.

NAPTR folgt S-NAPTR DDDS [RFC3958]; SERVICE enthält Anwendungs- und Protokoll-Tags. Diameter nutzt den Dienst-Tag aaa und diameter.tcp, diameter.sctp, diameter.dtls, diameter.tls.tcp [RFC6408]. Auflösung gemäß [RFC3958] bis passendem SRV/A/AAAA. NAPTR-Replacement-Domain-Suffixe SOLLTEN zur ursprünglichen Abfrage passen. Beispiel in Anhang B.

3. Ohne NAPTR direkte SRV: _diameter._tcp.realm, _diameters._tcp.realm, _diameter._sctp.realm, _diameters._sctp.realm. Bei Treffern A/AAAA gemäß [RFC2782], sonst Abbruch.

Bei Site-Zertifikat müssen NAPTR- und Replacement-Domains sowie SRV-Abfrage und SRV-Ziel gegen dasselbe Site-Zertifikat aus TLS/TCP, DTLS/SCTP oder IKE gültig sein (MUST), sonst DNS-Manipulation möglich.

Der Diameter-Peer MUSS prüfen, ob entdeckte Peers für ihre Rolle autorisiert sind. IKE/TLS/DNSSEC allein genügen nicht.

Autorisierung z. B. über eine Diameter-Server-CA mit Extended Key Usage OID [RFC5280]. Zum Zeitpunkt der Veröffentlichung gab es keine speziellen Diameter-CAs.

Dynamisch entdeckte Peers erzeugen einen Eintrag in der Peer-Tabelle (Abschnitt 2.6). DNS-Einträge MÜSSEN innerhalb des DNS-TTL ablaufen oder erneuert werden. Außerhalb des lokalen Realms entsteht ein Routing-Tabelleneintrag (2.7); dessen Ablauf MUSS mit dem des Peers übereinstimmen.