7. Base Protocol Procedures (Procedure del protocollo di base)
Questa sezione definisce le procedure di base del protocollo STUN. Descrive come vengono formati i messaggi, come vengono inviati e come vengono elaborati quando ricevuti. Definisce anche l'elaborazione dettagliata del metodo Binding. Altre sezioni di questo documento descrivono procedure opzionali che un utilizzo può scegliere di usare in determinate situazioni. Altri documenti possono definire altre estensioni a STUN aggiungendo nuovi metodi, nuovi attributi o nuovi codici di risposta di errore.
7.1. Forming a Request or an Indication (Formazione di una richiesta o indicazione)
Quando si forma un messaggio di richiesta o indicazione, l'agente deve (MUST) seguire le regole nella Sezione 6 per creare l'intestazione. Inoltre, la classe di messaggio deve (MUST) essere "Request" o "Indication" (a seconda dei casi), e il metodo deve (must) essere Binding o un metodo definito in un altro documento.
L'agente aggiunge quindi tutti gli attributi specificati dal metodo o dall'utilizzo. Ad esempio, alcuni utilizzi possono specificare che l'agente utilizza un metodo di autenticazione (Sezione 10) o l'attributo FINGERPRINT (Sezione 8).
Se l'agente sta inviando una richiesta, dovrebbe (SHOULD) aggiungere un attributo SOFTWARE alla richiesta. A seconda del metodo, l'agente può (MAY) includere un attributo SOFTWARE nelle indicazioni. Le estensioni a STUN dovrebbero discutere se SOFTWARE è utile nelle nuove indicazioni.
Per il metodo Binding senza autenticazione, non sono richiesti attributi a meno che l'utilizzo non specifichi diversamente.
Tutti i messaggi STUN inviati tramite UDP dovrebbero (SHOULD) essere inferiori al MTU del percorso, se noto. Se il MTU del percorso è sconosciuto, i messaggi dovrebbero (SHOULD) essere il minore tra 576 byte e il MTU del primo hop per IPv4 [RFC1122] e 1280 byte per IPv6 [RFC2460]. Questo valore corrisponde alla dimensione complessiva del pacchetto IP. Di conseguenza, per IPv4, il messaggio STUN effettivo deve essere inferiore a 548 byte (576 meno l'intestazione IP di 20 byte, meno l'intestazione UDP di 8 byte, assumendo che non vengano utilizzate opzioni IP). STUN non fornisce la capacità di gestire il caso in cui la richiesta rientra nel MTU ma la risposta sarebbe più grande del MTU. Non si prevede che questa limitazione sia un problema per STUN. La limitazione MTU è uno SHOULD, e non un MUST, per tenere conto dei casi in cui STUN stesso viene utilizzato per sondare le caratteristiche MTU [BEHAVE-NAT]. Al di fuori di tali o simili applicazioni, il vincolo MTU deve (MUST) essere rispettato.
7.2. Sending the Request or Indication (Invio della richiesta o indicazione)
L'agente invia quindi la richiesta o l'indicazione. Questo documento specifica come inviare messaggi STUN tramite UDP, TCP o TLS-over-TCP; altri protocolli di trasporto possono essere aggiunti in futuro. Un utilizzo STUN deve (must) specificare quale protocollo di trasporto viene utilizzato e come l'agente determina l'indirizzo IP e la porta del destinatario. La Sezione 9 descrive un metodo basato su DNS per determinare l'indirizzo IP e la porta di un server che un utilizzo può scegliere di usare. STUN può essere utilizzato con indirizzi anycast, ma solo con UDP e solo quando l'autenticazione non viene utilizzata.
In qualsiasi momento, un client può (MAY) avere più richieste STUN in sospeso con lo stesso server STUN (cioè più transazioni in corso, con ID di transazione diversi). In assenza di altri limiti sulla velocità di nuove transazioni (come quelli specificati da ICE per i controlli di connettività o quando STUN viene eseguito su TCP), un client dovrebbe (SHOULD) distanziare le nuove transazioni a un server di RTO e dovrebbe (SHOULD) limitarsi a dieci transazioni in sospeso verso lo stesso server.
7.2.1. Sending over UDP (Invio tramite UDP)
Quando si esegue STUN su UDP, i messaggi STUN possono essere persi dalla rete. L'affidabilità delle transazioni richiesta/risposta STUN viene ottenuta attraverso la ritrasmissione del messaggio di richiesta da parte dell'applicazione client stessa. Le indicazioni STUN non vengono ritrasmesse; pertanto, le transazioni di indicazione su UDP non sono affidabili.
Un client dovrebbe (SHOULD) ritrasmettere un messaggio di richiesta STUN iniziando con un intervallo di RTO ("Retransmission TimeOut", timeout di ritrasmissione), raddoppiando dopo ogni ritrasmissione. L'RTO è una stima del tempo di andata e ritorno (RTT, round-trip time) ed è calcolato come descritto in RFC 2988 [RFC2988], con due eccezioni. Primo, il valore iniziale per RTO dovrebbe (SHOULD) essere configurabile (piuttosto che i 3 s raccomandati in RFC 2988) e dovrebbe (SHOULD) essere maggiore di 500 ms. L'eccezione a questo "SHOULD" è per i casi in cui altri meccanismi vengono utilizzati per derivare soglie di congestione (come i meccanismi definiti da ICE per flussi a velocità fissa) o quando STUN viene utilizzato in ambienti non Internet con capacità di rete note. Nei collegamenti di accesso a linea fissa, un valore di 500 ms è raccomandato (RECOMMENDED). Secondo, il valore di RTO non dovrebbe (SHOULD NOT) essere arrotondato al secondo più vicino. Piuttosto, dovrebbe (SHOULD) essere mantenuta una precisione di 1 ms. Come per TCP, è raccomandato (RECOMMENDED) l'algoritmo di Karn [KARN87]. Questo significa che le stime RTT non dovrebbero (SHOULD NOT) essere calcolate da transazioni STUN che risultano nella ritrasmissione di una richiesta.
Il valore per RTO dovrebbe (SHOULD) essere memorizzato nella cache da un client dopo il completamento della transazione e utilizzato come valore iniziale per RTO per la transazione successiva allo stesso server (basato sull'uguaglianza dell'indirizzo IP). Il valore dovrebbe (SHOULD) essere considerato obsoleto e scartato dopo 10 minuti.
Le ritrasmissioni continuano fino a quando non viene ricevuta una risposta, o fino a quando non sono state inviate in totale Rc richieste. Rc dovrebbe (SHOULD) essere configurabile e dovrebbe (SHOULD) avere un valore predefinito di 7. Se, dopo l'ultima richiesta, è trascorsa una durata pari a Rm volte l'RTO senza una risposta (fornendo ampio tempo per ottenere una risposta se solo quest'ultima richiesta ha effettivamente successo), il client dovrebbe (SHOULD) considerare la transazione scaduta. Rm dovrebbe (SHOULD) essere configurabile e dovrebbe (SHOULD) avere un valore predefinito di 16. Una transazione STUN su UDP è anche considerata fallita se si è verificato un errore ICMP duro [RFC1122]. Ad esempio, assumendo un RTO di 500 ms, le richieste sarebbero inviate ai tempi 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms e 31500 ms. Se il client non ha ricevuto una risposta dopo 39500 ms, il client considererà la transazione scaduta.
7.2.2. Sending over TCP or TLS-over-TCP (Invio tramite TCP o TLS-over-TCP)
Per TCP e TLS-over-TCP, il client apre una connessione TCP al server.
In alcuni utilizzi di STUN, STUN viene inviato come unico protocollo sulla connessione TCP. In questo caso, può essere inviato senza l'aiuto di alcun framing o demultiplexing aggiuntivo. In altri utilizzi, o con altre estensioni, può essere multiplexato con altri dati su una connessione TCP. In tal caso, STUN deve (MUST) essere eseguito sopra una sorta di protocollo di framing, specificato dall'utilizzo o dall'estensione, che consente all'agente di estrarre messaggi STUN completi e messaggi di livello applicazione completi. Il servizio STUN in esecuzione sulla porta ben nota o su una porta scoperta tramite le procedure DNS nella Sezione 9 è solo per STUN, e non per STUN multiplexato con altri dati. Di conseguenza, nessun protocollo di framing viene utilizzato nelle connessioni a questi server. Quando viene utilizzato un framing aggiuntivo, l'utilizzo specificherà come il client sa applicarlo e a quale porta connettersi. Ad esempio, nel caso dei controlli di connettività ICE, queste informazioni vengono apprese tramite negoziazione fuori banda tra client e server.
Quando STUN viene eseguito da solo su TLS-over-TCP, la cipher suite TLS_RSA_WITH_AES_128_CBC_SHA deve (MUST), come minimo, essere implementata. Un'implementazione può (MAY) anche supportare qualsiasi altra cipher suite. Quando viene ricevuto un messaggio di certificato TLS, il client dovrebbe (SHOULD) verificare il certificato e controllare che il certificato identifichi la parte appropriata. Se il certificato è invalido o revocato, o se non identifica la parte appropriata, il client non deve (MUST NOT) inviare il messaggio STUN o altrimenti procedere con la transazione STUN. Il client deve (MUST) verificare l'identità del server. Per farlo, segue le procedure di identificazione definite nella Sezione 3.1 di RFC 2818 [RFC2818]. Queste procedure presuppongono che il client stia dereferenziando un URI. Per l'uso con questa specifica, il client tratta il nome di dominio o l'indirizzo IP utilizzato nella Sezione 8.1 come la parte host dell'URI che è stato dereferenziato. In alternativa, un client può (MAY) essere configurato con un insieme di domini o indirizzi IP fidati; se viene ricevuto un certificato che identifica uno di questi domini o indirizzi IP, il client considera l'identità del server verificata.
Quando STUN è multiplexato con altri protocolli su una connessione TLS-over-TCP, le cipher suite obbligatorie e le procedure di gestione TLS operano come definito da tali protocolli.
L'affidabilità di STUN su TCP e TLS-over-TCP è gestita da TCP stesso, e non ci sono ritrasmissioni a livello di protocollo STUN. Tuttavia, per una transazione richiesta/risposta, se il client non riceve una risposta entro Ti secondi dopo aver inviato il SYN per stabilire la connessione, considera la transazione scaduta. Ti dovrebbe (SHOULD) essere configurabile e dovrebbe (SHOULD) avere un valore predefinito di 39,5 secondi. Questo valore è stato scelto per essere uguale al timeout TCP con RTO iniziale predefinito sia per TCP che per UDP.
(Il contenuto continua nell'implementazione effettiva)