4. Comportement général
Cette section contient les règles générales de traitement TURN qui s'appliquent à tous les messages TURN.
TURN est une extension de STUN. Tous les messages TURN, à l'exception du message ChannelData, sont des messages au format STUN. Toutes les règles de traitement de base décrites dans [RFC5389] s'appliquent aux messages au format STUN. Cela signifie que toutes les descriptions de formation et de traitement de messages dans ce document sont implicitement préfixées par les règles de [RFC5389].
[RFC5389] spécifie un mécanisme d'authentification appelé mécanisme de credential à long terme (Long-Term Credential Mechanism). Les serveurs et clients TURN doivent implémenter ce mécanisme. Le serveur doit exiger que toutes les demandes du client soient authentifiées en utilisant ce mécanisme, ou en utilisant un mécanisme d'égale force ou plus fort.
Notez que le mécanisme de credential à long terme s'applique uniquement aux demandes et ne peut pas être utilisé pour authentifier les indications ; ainsi, les indications dans TURN ne sont jamais authentifiées. Si le serveur exige que les demandes soient authentifiées, alors l'administrateur du serveur doit choisir une valeur de domaine (realm) qui identifiera de manière unique la combinaison de nom d'utilisateur et de mot de passe que le client doit utiliser, même si le client utilise plusieurs serveurs sous différentes administrations. L'administrateur du serveur peut choisir d'allouer un nom d'utilisateur unique pour chaque client, ou peut choisir d'allouer le même nom d'utilisateur pour plusieurs clients (par exemple, pour tous les clients du même département ou de la même entreprise). Pour chaque allocation, le serveur devrait générer un nouveau nonce aléatoire lors de la première tentative d'allocation, en suivant les recommandations de caractère aléatoire dans [RFC4086], et devrait expirer le nonce au moins une fois par heure pendant la durée de vie de l'allocation.
Toutes les demandes après l'Allocate initial doivent utiliser le même nom d'utilisateur que celui utilisé pour créer l'allocation, afin d'empêcher un attaquant de détourner l'allocation du client. Plus précisément, si le serveur exige l'utilisation du mécanisme de credential à long terme, et si une demande non-Allocate passe l'authentification sous ce mécanisme, et si le 5-tuple identifie une allocation existante, mais que la demande n'utilise pas le même nom d'utilisateur que celui utilisé pour créer l'allocation, alors la demande doit être rejetée avec une erreur 441 (Wrong Credentials).
Lorsqu'un message TURN arrive au serveur depuis le client, le serveur utilise le 5-tuple dans le message pour identifier l'allocation associée. Pour tous les messages TURN (y compris ChannelData) autres qu'une demande Allocate, si le 5-tuple n'identifie pas une allocation existante, alors le message doit être rejeté avec une erreur 437 (Allocation Mismatch) (s'il s'agit d'une demande) ou ignoré silencieusement (s'il s'agit d'une indication ou d'un message ChannelData). Un client recevant une réponse d'erreur 437 à une demande autre qu'Allocate doit supposer que l'allocation n'existe plus.
[RFC5389] définit un certain nombre d'attributs, y compris les attributs SOFTWARE et FINGERPRINT. Le client devrait inclure l'attribut SOFTWARE dans toutes les demandes Allocate et Refresh et peut l'inclure dans toute autre demande ou indication. Le serveur devrait inclure l'attribut SOFTWARE dans toutes les réponses Allocate et Refresh (succès ou échec) et peut l'inclure dans d'autres réponses ou indications. Le client et le serveur peuvent inclure l'attribut FINGERPRINT dans tout message au format STUN défini dans ce document.
TURN n'utilise pas le mécanisme de rétrocompatibilité décrit dans [RFC5389].
Tel que défini actuellement, TURN ne prend en charge qu'IPv4. Les adresses IP du client, du serveur et toutes les adresses IP apparaissant dans les adresses de transport relayées doivent être des adresses IPv4.
Par défaut, TURN s'exécute sur les mêmes ports que STUN : 3478 pour TURN sur UDP et TCP, et 5349 pour TURN sur TLS. Cependant, TURN a son propre ensemble de noms d'enregistrement de service (Service Record, SRV) : « turn » pour UDP et TCP, et « turns » pour TLS. Les procédures SRV ou les procédures ALTERNATE-SERVER, toutes deux décrites dans la section 6, peuvent être utilisées pour exécuter TURN sur un port différent.
Pour assurer l'interopérabilité, un serveur TURN doit prendre en charge l'utilisation du transport UDP entre le client et le serveur, et devrait prendre en charge l'utilisation des transports TCP et TLS.
Lorsque le transport UDP est utilisé entre le client et le serveur, le client retransmettra une demande s'il ne reçoit pas de réponse dans un certain délai d'expiration. De ce fait, le serveur peut recevoir deux (ou plus) demandes avec le même 5-tuple et le même ID de transaction. STUN exige que le serveur reconnaisse ce cas et traite la demande comme idempotente (voir [RFC5389]). Certaines implémentations peuvent choisir de satisfaire cette exigence en mémorisant toutes les demandes reçues et les réponses correspondantes pendant 40 secondes. D'autres implémentations peuvent choisir de retraiter la demande et organiser que ce retraitement renvoie essentiellement la même réponse. Pour aider les implémenteurs qui choisissent cette dernière approche (l'approche dite « pile sans état »), cette spécification inclut quelques notes d'implémentation sur la façon de le faire. Les implémentations sont libres de choisir l'une ou l'autre approche ou de choisir une autre approche qui donne les mêmes résultats.
Lorsque le transport TCP est utilisé entre le client et le serveur, les erreurs de bits peuvent corrompre le champ de longueur dans un paquet TURN, provoquant la perte de synchronisation du récepteur avec le flux entrant de messages TURN. Un client ou un serveur qui détecte une longue séquence de messages TURN invalides sur un transport TCP devrait fermer la connexion TCP correspondante pour aider l'autre extrémité à détecter la situation plus rapidement.
Pour atténuer les attaques par déni de service intentionnelles ou non intentionnelles contre le serveur par des clients avec des noms d'utilisateur et des mots de passe valides, il est recommandé que le serveur impose à la fois une limite sur le nombre d'allocations actives simultanément pour un nom d'utilisateur donné et une limite sur la quantité de bande passante que ces allocations peuvent utiliser. Le serveur devrait rejeter les nouvelles allocations qui dépasseraient la limite du nombre autorisé d'allocations simultanées actives avec une erreur 486 (Allocation Quota Exceeded) (voir section 6.2), et devrait rejeter le trafic de données d'application qui dépasse le quota de bande passante.