4. Comportamento generale
Questa sezione contiene regole generali di elaborazione TURN che si applicano a tutti i messaggi TURN.
TURN è un'estensione di STUN. Tutti i messaggi TURN, ad eccezione del messaggio ChannelData, sono messaggi in formato STUN. Tutte le regole di elaborazione di base descritte in [RFC5389] si applicano ai messaggi in formato STUN. Ciò significa che tutte le descrizioni di formazione ed elaborazione dei messaggi in questo documento sono implicitamente precedute dalle regole di [RFC5389].
[RFC5389] specifica un meccanismo di autenticazione chiamato meccanismo di credenziali a lungo termine (Long-Term Credential Mechanism). I server e i client TURN devono implementare questo meccanismo. Il server deve richiedere che tutte le richieste dal client siano autenticate utilizzando questo meccanismo, o utilizzando un meccanismo di uguale forza o più forte.
Si noti che il meccanismo di credenziali a lungo termine si applica solo alle richieste e non può essere utilizzato per autenticare le indicazioni; pertanto, le indicazioni in TURN non sono mai autenticate. Se il server richiede che le richieste siano autenticate, l'amministratore del server deve scegliere un valore di realm che identificherà in modo univoco la combinazione di nome utente e password che il client deve utilizzare, anche se il client utilizza più server sotto diverse amministrazioni. L'amministratore del server può scegliere di allocare un nome utente univoco per ciascun client, o può scegliere di allocare lo stesso nome utente per più client (ad esempio, per tutti i client dello stesso dipartimento o azienda). Per ogni allocazione, il server dovrebbe generare un nuovo nonce casuale quando l'allocazione viene tentata per la prima volta, seguendo le raccomandazioni di casualità in [RFC4086], e dovrebbe far scadere il nonce almeno una volta all'ora durante la durata dell'allocazione.
Tutte le richieste dopo l'Allocate iniziale devono utilizzare lo stesso nome utente utilizzato per creare l'allocazione, per impedire a un attaccante di dirottare l'allocazione del client. In particolare, se il server richiede l'uso del meccanismo di credenziali a lungo termine, e se una richiesta non-Allocate supera l'autenticazione sotto questo meccanismo, e se la 5-tupla identifica un'allocazione esistente, ma la richiesta non utilizza lo stesso nome utente utilizzato per creare l'allocazione, allora la richiesta deve essere rifiutata con un errore 441 (Wrong Credentials).
Quando un messaggio TURN arriva al server dal client, il server utilizza la 5-tupla nel messaggio per identificare l'allocazione associata. Per tutti i messaggi TURN (incluso ChannelData) diversi da una richiesta Allocate, se la 5-tupla non identifica un'allocazione esistente, allora il messaggio deve essere rifiutato con un errore 437 (Allocation Mismatch) (se è una richiesta) o ignorato silenziosamente (se è un'indicazione o un messaggio ChannelData). Un client che riceve una risposta di errore 437 a una richiesta diversa da Allocate deve presumere che l'allocazione non esista più.
[RFC5389] definisce un certo numero di attributi, inclusi gli attributi SOFTWARE e FINGERPRINT. Il client dovrebbe includere l'attributo SOFTWARE in tutte le richieste Allocate e Refresh e può includerlo in qualsiasi altra richiesta o indicazione. Il server dovrebbe includere l'attributo SOFTWARE in tutte le risposte Allocate e Refresh (successo o fallimento) e può includerlo in altre risposte o indicazioni. Il client e il server possono includere l'attributo FINGERPRINT in qualsiasi messaggio in formato STUN definito in questo documento.
TURN non utilizza il meccanismo di retrocompatibilità descritto in [RFC5389].
Come attualmente definito, TURN supporta solo IPv4. Gli indirizzi IP del client, del server e tutti gli indirizzi IP che appaiono negli indirizzi di trasporto inoltrati devono essere indirizzi IPv4.
Per impostazione predefinita, TURN viene eseguito sulle stesse porte di STUN: 3478 per TURN su UDP e TCP, e 5349 per TURN su TLS. Tuttavia, TURN ha il proprio set di nomi di record di servizio (Service Record, SRV): "turn" per UDP e TCP, e "turns" per TLS. Le procedure SRV o le procedure ALTERNATE-SERVER, entrambe descritte nella sezione 6, possono essere utilizzate per eseguire TURN su una porta diversa.
Per garantire l'interoperabilità, un server TURN deve supportare l'uso del trasporto UDP tra il client e il server, e dovrebbe supportare l'uso dei trasporti TCP e TLS.
Quando viene utilizzato il trasporto UDP tra il client e il server, il client ritrasmette una richiesta se non riceve una risposta entro un certo periodo di timeout. Per questo motivo, il server può ricevere due (o più) richieste con la stessa 5-tupla e lo stesso ID di transazione. STUN richiede che il server riconosca questo caso e tratti la richiesta come idempotente (vedere [RFC5389]). Alcune implementazioni possono scegliere di soddisfare questo requisito ricordando tutte le richieste ricevute e le risposte corrispondenti per 40 secondi. Altre implementazioni possono scegliere di rielaborare la richiesta e organizzare che tale rielaborazione restituisca essenzialmente la stessa risposta. Per aiutare gli implementatori che scelgono quest'ultimo approccio (il cosiddetto "approccio stack senza stato"), questa specifica include alcune note di implementazione su come farlo. Le implementazioni sono libere di scegliere uno dei due approcci o di scegliere un altro approccio che dia gli stessi risultati.
Quando viene utilizzato il trasporto TCP tra il client e il server, gli errori di bit possono corrompere il campo di lunghezza in un pacchetto TURN, causando la perdita di sincronizzazione del ricevitore con il flusso in arrivo di messaggi TURN. Un client o un server che rileva una lunga sequenza di messaggi TURN non validi su un trasporto TCP dovrebbe chiudere la connessione TCP corrispondente per aiutare l'altra estremità a rilevare la situazione più rapidamente.
Per mitigare gli attacchi di denial-of-service intenzionali o non intenzionali contro il server da parte di client con nomi utente e password validi, si raccomanda che il server imponga sia un limite sul numero di allocazioni attive contemporaneamente per un determinato nome utente sia un limite sulla quantità di larghezza di banda che tali allocazioni possono utilizzare. Il server dovrebbe rifiutare nuove allocazioni che supererebbero il limite del numero consentito di allocazioni simultanee attive con un errore 486 (Allocation Quota Exceeded) (vedere sezione 6.2), e dovrebbe scartare il traffico di dati dell'applicazione che supera la quota di larghezza di banda.