5.2. Scoperta dei peer Diameter

La scoperta dinamica degli agent Diameter (agents) semplifica e rende più robusto il dispiegamento. Per interoperabilità si descrivono configurazione manuale e DNS, basate su standard IETF. Entrambi DEVONO essere supportati; si può usare l'uno o l'altro (MAY).

Si scopre quando un client cerca il primo hop o un agent ne cerca un altro. Ordine consigliato:

1. Elenco statico (manuale) di posizioni agent, se esistono e rispondono.

2. Query NAPTR nel realm noto a priori, ad es. dal realm di un NAI.

NAPTR segue S-NAPTR DDDS [RFC3958]; SERVICE contiene tag applicazione e protocollo. Per Diameter il tag servizio è aaa e i protocolli diameter.tcp, diameter.sctp, diameter.dtls, diameter.tls.tcp [RFC6408]. Risoluzione [RFC3958] fino a SRV/A/AAAA adatto. I suffissi replacement NAPTR DOVREBBERO combaciare col dominio della query. Appendice B.

3. Senza NAPTR, SRV diretti: _diameter._tcp.realm, _diameters._tcp.realm, _diameter._sctp.realm, _diameters._sctp.realm. Con SRV, A/AAAA per [RFC2782], altrimenti stop.

Con certificato di sito (site certificate), domini NAPTR e replacement e domini SRV/target DEVONO essere validi rispetto allo stesso certificato TLS/TCP, DTLS/SCTP o IKE (MUST).

Il peer DEVE verificare che i peer scoperti siano autorizzati al ruolo. IKE/TLS/DNSSEC da soli non bastano.

Autorizzazione es. tramite CA server Diameter con OID di uso esteso [RFC5280]. Alla stesura non esistevano CA dedicate.

Peer dinamici creano voce nella tabella peer (sezione 2.6). Voci DNS DEVONO scadere o aggiornarsi entro TTL. Fuori realm locale si crea voce di routing (2.7) con scadenza uguale al peer (MUST).