7. Base Protocol Procedures (Procédures du protocole de base)
Cette section définit les procédures de base du protocole STUN. Elle décrit comment les messages sont formés, comment ils sont envoyés et comment ils sont traités lorsqu'ils sont reçus. Elle définit également le traitement détaillé de la méthode Binding. D'autres sections de ce document décrivent les procédures optionnelles qu'une utilisation peut choisir d'utiliser dans certaines situations. D'autres documents peuvent définir d'autres extensions à STUN en ajoutant de nouvelles méthodes, de nouveaux attributs ou de nouveaux codes de réponse d'erreur.
7.1. Forming a Request or an Indication (Formation d'une requête ou d'une indication)
Lors de la formation d'un message de requête ou d'indication, l'agent doit (MUST) suivre les règles de la Section 6 pour créer l'en-tête. De plus, la classe de message doit (MUST) être soit "Request" soit "Indication" (selon le cas), et la méthode doit (must) être Binding ou une méthode définie dans un autre document.
L'agent ajoute ensuite tous les attributs spécifiés par la méthode ou l'utilisation. Par exemple, certaines utilisations peuvent spécifier que l'agent utilise une méthode d'authentification (Section 10) ou l'attribut FINGERPRINT (Section 8).
Si l'agent envoie une requête, il devrait (SHOULD) ajouter un attribut SOFTWARE à la requête. Selon la méthode, l'agent peut (MAY) inclure un attribut SOFTWARE dans les indications. Les extensions à STUN devraient discuter si SOFTWARE est utile dans les nouvelles indications.
Pour la méthode Binding sans authentification, aucun attribut n'est requis sauf si l'utilisation le spécifie autrement.
Tous les messages STUN envoyés via UDP devraient (SHOULD) être inférieurs au MTU du chemin, s'il est connu. Si le MTU du chemin est inconnu, les messages devraient (SHOULD) être le plus petit de 576 octets et le MTU du premier saut pour IPv4 [RFC1122] et 1280 octets pour IPv6 [RFC2460]. Cette valeur correspond à la taille globale du paquet IP. Par conséquent, pour IPv4, le message STUN réel doit être inférieur à 548 octets (576 moins l'en-tête IP de 20 octets, moins l'en-tête UDP de 8 octets, en supposant qu'aucune option IP n'est utilisée). STUN ne fournit pas la capacité de gérer le cas où la requête tient sous le MTU mais la réponse serait plus grande que le MTU. On ne s'attend pas à ce que cette limitation soit un problème pour STUN. La limitation MTU est un SHOULD, et non un MUST, pour tenir compte des cas où STUN lui-même est utilisé pour sonder les caractéristiques MTU [BEHAVE-NAT]. En dehors de telles applications ou similaires, la contrainte MTU doit (MUST) être respectée.
7.2. Sending the Request or Indication (Envoi de la requête ou de l'indication)
L'agent envoie ensuite la requête ou l'indication. Ce document spécifie comment envoyer des messages STUN via UDP, TCP ou TLS-over-TCP ; d'autres protocoles de transport peuvent être ajoutés à l'avenir. Une utilisation STUN doit (must) spécifier quel protocole de transport est utilisé et comment l'agent détermine l'adresse IP et le port du destinataire. La Section 9 décrit une méthode basée sur DNS pour déterminer l'adresse IP et le port d'un serveur qu'une utilisation peut choisir d'utiliser. STUN peut être utilisé avec des adresses anycast, mais uniquement avec UDP et uniquement lorsque l'authentification n'est pas utilisée.
À tout moment, un client peut (MAY) avoir plusieurs requêtes STUN en attente avec le même serveur STUN (c'est-à-dire plusieurs transactions en cours, avec des ID de transaction différents). En l'absence d'autres limites sur le taux de nouvelles transactions (telles que celles spécifiées par ICE pour les vérifications de connectivité ou lorsque STUN est exécuté sur TCP), un client devrait (SHOULD) espacer les nouvelles transactions vers un serveur de RTO et devrait (SHOULD) se limiter à dix transactions en attente vers le même serveur.
7.2.1. Sending over UDP (Envoi via UDP)
Lors de l'exécution de STUN sur UDP, les messages STUN peuvent être perdus par le réseau. La fiabilité des transactions requête/réponse STUN est obtenue par la retransmission du message de requête par l'application client elle-même. Les indications STUN ne sont pas retransmises ; ainsi, les transactions d'indication sur UDP ne sont pas fiables.
Un client devrait (SHOULD) retransmettre un message de requête STUN en commençant par un intervalle de RTO ("Retransmission TimeOut", délai de retransmission), en doublant après chaque retransmission. Le RTO est une estimation du temps aller-retour (RTT, round-trip time) et est calculé comme décrit dans RFC 2988 [RFC2988], avec deux exceptions. Premièrement, la valeur initiale de RTO devrait (SHOULD) être configurable (plutôt que les 3 s recommandés dans RFC 2988) et devrait (SHOULD) être supérieure à 500 ms. L'exception à ce "SHOULD" concerne les cas où d'autres mécanismes sont utilisés pour dériver les seuils de congestion (tels que les mécanismes définis par ICE pour les flux à débit fixe) ou lorsque STUN est utilisé dans des environnements non-Internet avec des capacités réseau connues. Dans les liens d'accès à ligne fixe, une valeur de 500 ms est recommandée (RECOMMENDED). Deuxièmement, la valeur de RTO ne devrait pas (SHOULD NOT) être arrondie à la seconde la plus proche. Au lieu de cela, une précision de 1 ms devrait (SHOULD) être maintenue. Comme pour TCP, l'algorithme de Karn [KARN87] est recommandé (RECOMMENDED). Cela signifie que les estimations RTT ne devraient pas (SHOULD NOT) être calculées à partir de transactions STUN qui entraînent la retransmission d'une requête.
La valeur de RTO devrait (SHOULD) être mise en cache par un client après l'achèvement de la transaction et utilisée comme valeur de départ pour RTO pour la transaction suivante vers le même serveur (basée sur l'égalité de l'adresse IP). La valeur devrait (SHOULD) être considérée comme périmée et abandonnée après 10 minutes.
Les retransmissions se poursuivent jusqu'à ce qu'une réponse soit reçue, ou jusqu'à ce qu'un total de Rc requêtes aient été envoyées. Rc devrait (SHOULD) être configurable et devrait (SHOULD) avoir une valeur par défaut de 7. Si, après la dernière requête, une durée égale à Rm fois le RTO s'est écoulée sans réponse (fournissant amplement de temps pour obtenir une réponse si seule cette dernière requête réussit effectivement), le client devrait (SHOULD) considérer que la transaction a expiré. Rm devrait (SHOULD) être configurable et devrait (SHOULD) avoir une valeur par défaut de 16. Une transaction STUN sur UDP est également considérée comme échouée s'il y a eu une erreur ICMP dure [RFC1122]. Par exemple, en supposant un RTO de 500 ms, les requêtes seraient envoyées aux temps 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms et 31500 ms. Si le client n'a pas reçu de réponse après 39500 ms, le client considérera que la transaction a expiré.
7.2.2. Sending over TCP or TLS-over-TCP (Envoi via TCP ou TLS-over-TCP)
Pour TCP et TLS-over-TCP, le client ouvre une connexion TCP au serveur.
Dans certaines utilisations de STUN, STUN est envoyé comme seul protocole sur la connexion TCP. Dans ce cas, il peut être envoyé sans l'aide d'aucun tramage ou démultiplexage supplémentaire. Dans d'autres utilisations, ou avec d'autres extensions, il peut être multiplexé avec d'autres données sur une connexion TCP. Dans ce cas, STUN doit (MUST) être exécuté au-dessus d'une sorte de protocole de tramage, spécifié par l'utilisation ou l'extension, qui permet à l'agent d'extraire des messages STUN complets et des messages de couche application complets. Le service STUN fonctionnant sur le port bien connu ou sur un port découvert via les procédures DNS de la Section 9 est pour STUN seul, et non pour STUN multiplexé avec d'autres données. Par conséquent, aucun protocole de tramage n'est utilisé dans les connexions à ces serveurs. Lorsqu'un tramage supplémentaire est utilisé, l'utilisation spécifiera comment le client sait l'appliquer et à quel port se connecter. Par exemple, dans le cas des vérifications de connectivité ICE, ces informations sont apprises par négociation hors bande entre le client et le serveur.
Lorsque STUN est exécuté seul sur TLS-over-TCP, la suite de chiffrement TLS_RSA_WITH_AES_128_CBC_SHA doit (MUST), au minimum, être implémentée. Une implémentation peut (MAY) également prendre en charge toute autre suite de chiffrement. Lorsqu'un message de certificat TLS est reçu, le client devrait (SHOULD) vérifier le certificat et vérifier que le certificat identifie la partie appropriée. Si le certificat est invalide ou révoqué, ou s'il n'identifie pas la partie appropriée, le client ne doit pas (MUST NOT) envoyer le message STUN ou autrement poursuivre la transaction STUN. Le client doit (MUST) vérifier l'identité du serveur. Pour ce faire, il suit les procédures d'identification définies dans la Section 3.1 de RFC 2818 [RFC2818]. Ces procédures supposent que le client déréférence un URI. Pour une utilisation avec cette spécification, le client traite le nom de domaine ou l'adresse IP utilisé dans la Section 8.1 comme la partie hôte de l'URI qui a été déréférencé. Alternativement, un client peut (MAY) être configuré avec un ensemble de domaines ou d'adresses IP de confiance ; si un certificat est reçu qui identifie l'un de ces domaines ou adresses IP, le client considère que l'identité du serveur a été vérifiée.
Lorsque STUN est multiplexé avec d'autres protocoles sur une connexion TLS-over-TCP, les suites de chiffrement obligatoires et les procédures de traitement TLS fonctionnent comme défini par ces protocoles.
La fiabilité de STUN sur TCP et TLS-over-TCP est gérée par TCP lui-même, et il n'y a pas de retransmissions au niveau du protocole STUN. Cependant, pour une transaction requête/réponse, si le client ne reçoit pas de réponse dans les Ti secondes après avoir envoyé le SYN pour établir la connexion, il considère que la transaction a expiré. Ti devrait (SHOULD) être configurable et devrait (SHOULD) avoir une valeur par défaut de 39,5 secondes. Cette valeur a été choisie pour être égale au délai d'expiration TCP avec le RTO initial par défaut pour TCP et UDP.
(Le contenu continue dans l'implémentation réelle)