Groupe de travail Réseau	R. Denis-Courmont, VideoLAN project	
Request for Comments: 5597	septembre 2009	
BCP : 150		
Catégorie : Bonnes pratiques actuelles	Traduction Claude Brière de L'Isle	

Exigences comportementales des traducteurs d'adresse réseau (NAT) pour le protocole de contrôle d'encombrement de datagramme

Résumé
Le présent document définit un ensemble d'exigences pour le traitement par les NAT du protocole de contrôle d'encombrement de datagramme (DCCP, Datagram Congestion Control Protocol). Ces exigences permettent aux applications de DCCP, telles que les applications d'écoulement de flux en direct, de fonctionner de façon cohérente, et elles sont très similaires aux exigences de TCP pour les NAT, qui ont déjà été publiées par l'IETF. S'assurer que les NAT satisfont à cet ensemble d'exigences va beaucoup augmenter la probabilité que les applications qui utilisent DCCP fonctionnent correctement.

Statut de ce mémoire
Ce document spécifie les bonnes pratiques actuelles sur l'Internet pour la communauté de l'Internet, et demande des discussions et suggestions pour son amélioration. La diffusion du présent mémoire n'est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2012 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Table des matières
1. Introduction	2
2. Définitions	2
3. Déclaration d'applicabilité	2
4. Initiation de connexion DCCP	3
4.1 Comportement de transposition d'adresse et d'accès	3
4.2 Connexions établies	3
4.3 Connexions initiées en externe	3
5. Rafraîchissement de session de NAT	3
6. Passerelles de niveau application	4
7. Autres exigences applicables à DCCP	4
7.1 Allocation d'accès	4
7.2 Comportement d'épinglage	4
7.3 Réponses ICMP aux paquets DCCP	4
8. Exigences spécifiques de DCCP	4
8.1 Couverture de somme de contrôle partielle	4
8.2 Codes de services	5
9. DCCP sans prise en charge de NAT	5
10. Considérations sur la sécurité	5
11. Remerciements	6
12. Références	6
12.1 Références normatives	6
12.2 Références pour information	6
Adresse de l'auteur	6

 	1.	Introduction

Pour des raisons historiques, les appareils de NAT ne sont normalement pas capables de traiter les datagrammes et flux pour les applications qui utilisent le protocole de contrôle d'encombrement de datagrammes (DCCP, Datagram Congestion Control Protocol) [RFC4340].

Le présent mémoire discute des problèmes techniques impliqués et propose un ensemble d'exigences pour que les appareils de NAT traitent DCCP d'une façon qui permette la communication quand l'un et/ou l'autre des points d'extrémité DCCP sont situés derrière un ou plusieurs appareils de NAT. Toutes les définitions et exigences de la [RFC4787] sont héritées ici. Les exigences sont par ailleurs conçues de la même façon que celles de la [RFC5382], dont le présent mémoire emprunte la structure et beaucoup du contenu.

Noter cependant que, si les deux points d'extrémité sont entravés par des appareils de NAT, le modèle normal de connexion asymétrique pour DCCP ne va pas fonctionner. Une ouverture simultanée doit être effectuée, comme dans la [RFC5596].  Aussi, un mécanisme séparé, non spécifié, peut être nécessaire, comme les protocoles d'auto correction d'adressage unilatérale (UNSAF, Unilateral Self Address Fixing) [RFC3424], si un point d'extrémité a besoin d'apprendre ses propres transpositions de NAT externes.

 	2.	Définitions

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Le présent document utilise le terme de "connexion DCCP" pour se référer à des flux DCCP individuels, comme identifiés de façon univoque par le quadruplet (adresses IP de source et destination et accès DCCP) à un moment donné.

Le présent document utilise le terme de "transposition de NAT" pour se référer à un état au NAT qui est nécessaire pour la traduction d'adresse et accès réseau des connexions DCCP. Le présent document utilise aussi les termes de "transposition indépendante du point d'extrémité", de "transposition dépendante de l'adresse", et de "transposition dépendante de l'adresse et de l'accès", de "comportement de filtrage", de "filtrage indépendant du point d'extrémité", de "filtrage dépendant de l'adresse", de "filtrage dépendant de l'adresse et de l'accès", "d'allocation d'accès", de "surcharge d'accès", "d'épinglage", et "d'adresse IP et accès de source externe" comme définis dans la [RFC4787].

 	3.	Déclaration d'applicabilité

Le présent document s'applique aux appareils de NAT qui veulent traiter des datagrammes DCCP. Il n'est pas dans l'intention de ce document de déconseiller la majorité écrasante des appareils de NAT déployés. Ces NAT ne sont simplement pas supposés traiter DCCP, donc le présent mémoire ne s'applique pas à eux.

Les comportements de NAT applicables aux connexions DCCP sont très similaires à ceux applicables aux connexions TCP (à l'exception de la REC-6 ci-dessous). Les exigences suivantes sont discutées et justifiées de façon extensive dans la [RFC5382]. Ces justifications ne sont pas reproduites ici dans un souci de concision.

En plus des changements habituels de l'en-tête IP (en particulier, les adresses IP) les appareils de NAT doivent décortiquer :
o	l'accès de source DCCP pour les paquets sortants, selon la transposition de NAT,
o	l'accès de destination DCCP pour les paquets entrants, selon la transposition de NAT, et
o	la somme de contrôle DCCP, pour compenser les modifications d'adresse IP et de numéro d'accès.

Parce que changer l'adresse IP de source ou destination d'un paquet DCCP va normalement invalider la somme de contrôle DCCP, il n'est pas possible d'utiliser DCCP à travers un NAT sans un support dédié. Certains appareils de NAT sont connus pour fournir une prise en charge "générique" de protocole de transport, par laquelle seul l'en-tête IP est décortiqué. Ce schéma n'est pas suffisant pour prendre en charge DCCP.

 	4.	Initiation de connexion DCCP
 	4.1	Comportement de transposition d'adresse et d'accès
Un NAT utilise une transposition pour traduire les paquets pour chaque connexion DCCP. Une transposition est allouée dynamiquement pour les connexions initiées de l'intérieur, et est potentiellement réutilisée pour certaines connexions suivantes. Le comportement de NAT concernant quand une transposition peut être réutilisée diffère selon les NAT, comme décrit dans la [RFC4787].

REC-1 : un NAT DOIT avoir un comportement de "transposition indépendante du point d'extrémité" pour DCCP.

 	4.2	Connexions établies
REC-2 : un NAT DOIT prendre en charge toutes les séquences valides de paquets DCCP (défini dans la [RFC4340] et ses mises à jour) pour les connexions initiées en interne aussi bien qu'en externe quand la connexion est permise par le NAT. En particulier, en plus de traiter l'initiation de mode de connexion de prise de contact en trois phases de DCCP, un NAT DOIT traiter l'initiation de mode de connexion d'ouverture simultanée de DCCP, définie dans la [RFC5596]. Ce mode met à jour DCCP en ajoutant un nouveau type de paquet : DCCP-Listen. Le paquet DCCP-Listen communique les informations nécessaires pour identifier de façon unique une session DCCP. Les NAT peuvent utiliser les informations de connexion (adresse, accès, code de service) pour établir l'état de transmission local.

 	4.3	Connexions initiées en externe
REC-3 : si la transparence d'application est des plus importantes, il est RECOMMANDÉ qu'un NAT ait un comportement de "filtrage indépendant du point d'extrémité" pour DCCP. Si un comportement de filtrage plus strict est important, il est RECOMMANDÉ qu'un NAT ait un comportement de "filtrage dépendant de l'adresse" pour DCCP.

o	Le comportement de filtrage PEUT être une option configurable par l'administrateur du NAT.

o	Le comportement de filtrage pour DCCP PEUT être indépendant du comportement de filtrage pour tout autre protocole de couche transport, comme UDP, UDP-léger, TCP, et SCTP (le protocole de transmission des commandes de flux).

REC-4 : un NAT DOIT attendre au moins 6 secondes la réception d'un paquet entrant DCCP-Listen ou DCCP-Sync non sollicité avant qu'il puisse répondre avec une erreur ICMP Accès injoignable, une erreur ICMP Protocole inaccessible, ou un DCCP-Reset. Si, durant cet intervalle, le NAT reçoit et traduit un paquet DCCP-Request sortant pour la connexion, le NAT DOIT éliminer en silence le paquet DCCP-Listen entrant original non sollicité. Autrement, le NAT DEVRAIT envoyer une erreur ICMP Accès injoignable (type 3, code 3) pour le DCCP-Listen original sauf si la politique de sécurité l'interdit.

 	5.	Rafraîchissement de session de NAT

La "temporisation d'inactivité de connexion établie" pour un NAT est définie comme la durée minimum pendant laquelle une connexion DCCP dans l'état établi doit rester inactive avant que le NAT considère que la session associée est candidate à la suppression. La "temporisation d'inactivité de connexion transitoire" pour un NAT est définie comme la durée minimum pendant laquelle une connexion DCCP dans les phases CLOSEREQ ou CLOSING doit rester inactive avant que le NAT considère que la session associée est candidate à la suppression. Les connexions DCCP dans l'état TIMEWAIT ne sont pas affectées par la "temporisation d'inactivité de connexion transitoire".

REC-5 : si un NAT ne peut pas déterminer si les points d'extrémité d'une connexion DCCP sont actifs, il PEUT abandonner la session si il a été inactif depuis quelques temps. Lorsque un NAT met en œuvre les fins de temporisation de session, la valeur par défaut de la "temporisation d'inactivité de connexion établie" DOIT être de 124 minutes ou plus, et la valeur par défaut de la "temporisation d'inactivité de connexion transitoire" DOIT être de 4 minutes ou plus. Un NAT qui met en œuvre les fins de temporisation de session peut être configurable à utiliser des valeurs plus petites pour les temporisations d'inactivité de NAT.

Le comportement des NAT pour traiter les paquets DCCP-Reset ou les connexions dans l'état TIMEWAIT reste non spécifié

 	6.	Passerelles de niveau application

Au contraire de TCP, DCCP est un protocole tolérant aux pertes. Donc, modifier la charge utile des paquets DCCP peut présenter un défi supplémentaire significatif pour maintenir un état de couche application nécessaire pour qu'une passerelle de niveau application (ALG, Application Level Gateway) fonctionne correctement. De plus, il n'y a pas d'ALG capable de DCCP connue au moment de la rédaction du présent document.

REC-6 : si un NAT inclut des ALG, ces ALG NE DOIVENT PAS affecter DCCP.

Note : ceci n'est pas cohérent avec la REC-6 de la [RFC5382].

 	7.	Autres exigences applicables à DCCP

Une liste des exigences de comportement de NAT générales et spécifiques de UDP est décrite dans la [RFC4787]. Une liste des exigences de comportement de NAT spécifiques de ICMP est décrite dans la [RFC5508]. Les exigences mentionnées ci-dessous réitèrent les exigences de ces deux documents qui affectent directement DCCP. Les exigences suivantes ne relâchent aucune des exigences des [RFC4787] ou [RFC5508].

 	7.1	Allocation d'accès
REC-7 : un NAT NE DOIT PAS avoir un comportement "d'allocation d'accès"de "surcharge d'accès" pour DCCP.

 	7.2	Comportement d'épinglage
REC-8 : un NAT DOIT prendre en charge "l'épinglage" pour DCCP. De plus, un comportement d'épinglage de NAT DOIT être du type "adresse IP et accès de source externe".

 	7.3	Réponses ICMP aux paquets DCCP
REC-9 : Si un NAT traduit DCCP, il DEVRAIT traduire les messages ICMP Destination injoignable (type 3).

REC-10 : la réception de toute sorte de message ICMP NE DOIT PAS terminer la transposition de NAT ou la connexion DCCP pour laquelle de message ICMP a été généré.

 	8.	Exigences spécifiques de DCCP
 	8.1	Couverture de somme de contrôle partielle
DCCP prend en charge la couverture de somme de contrôle partielle. Un NAT va généralement devoir effectuer des changements incrémentaires au champ Somme de contrôle du paquet, comme pour les autres protocoles définis par l'IETF.  Cependant, si il a besoin de recalculer une valeur correcte de somme de contrôle, il doit prendre en compte la couverture de la somme de contrôle, comme décrit au paragraphe 9.2 de la [RFC4340].

REC-11 : si un NAT traduit un paquet DCCP avec une somme de contrôle DCCP valide, il DOIT s'assurer que la somme de contrôle DCCP est traduite de telle façon qu'elle soit valide après la traduction.

REC-12 : un NAT NE DOIT PAS modifier la valeur de la couverture de somme de contrôle DCCP.

Le champ Couverture de somme de contrôle dans l'en-tête DCCP détermine les parties du paquet qui sont couvertes par le champ Somme de contrôle. Cela inclut toujours l'en-tête DCCP et les options, mais certaines ou toutes les données d'application peuvent être exclues comme déterminé paquet par paquet par l'application. Changer la couverture de somme de contrôle dans le réseau viole les hypothèses d'intégrité chez le receveur et peut résulter en un comportement d'application imprévisible ou incorrect.

 	8.2	Codes de services
DCCP spécifie un code de service comme une valeur de quatre octets (32 bits) qui décrit le service de niveau application auquel une application cliente souhaite se connecter [RFC4340].

REC-13 : si un NAT traduit un paquet DCCP, il NE DOIT PAS modifier la valeur de son code de service DCCP.

De plus, des lignes directrices sur l'utilisation des codes de service par les boîtiers de médiation, incluant les NAT, peuvent être trouvées dans la [RFC5595].

 	9.	DCCP sans prise en charge de NAT

Si l'appareil de NAT ne peut pas être mis à jour pour prendre en charge DCCP, les datagrammes DCCP peuvent être encapsulés dans un en-tête de transport UDP. Bien sûr, la plupart des appareils de NAT sont déjà capables de traiter UDP.  cela sort cependant du domaine d'application du présent document.

 	10.	Considérations sur la sécurité

La [RFC4787] discute des considérations sur la sécurité pour les NAT qui traitent le trafic IP et en envoi individuel (UDP) dont toutes s'appliquent également au présent document. Les problèmes de sécurité spécifiques du traitement des paquets DCCP sont discutés dans cette section.

Les REC-1 et REC-6 à REC-13 n'introduisent aucun nouveau problème de sécurité connu.

La REC-2 n'introduit pas de nouveau problème de sécurité connu. Bien qu'un NAT puisse choisir de garder trace de certains états par flux spécifiques de DCCP (comparés à UDP) il n'a aucune obligation de le faire.

La REC-3 permet à un NAT d'adopter une politique de filtrage plus sûre ou plus transparente à l'application. Ceci est déjà traité par les [RFC4787] et [RFC5382].

Comme dans la [RFC5382], la REC-4 du présent document recommande qu'un NAT réponde à des paquets Listen et Sync entrants non sollicités avec une erreur ICMP retardée de quelques secondes. Le faire peut révéler la présence d'un NAT à un attaquant externe. L'élimination en silence du Listen rend plus difficile de diagnostiquer les problèmes de réseau et force les applications à attendre que la pile DCCP finisse plusieurs retransmissions avant de rapporter une erreur. Une mise en œuvre doit donc comprendre et soupeser avec soin les effets de ne pas envoyer d'erreur ICMP ou de limiter en débit de telles erreurs ICMP à un très petit nombre.

La REC-5 recommande qu'un NAT qui surveille passivement la pile DCCP garde en vie ses sessions inactives pendant au moins 124 minutes ou 4 minutes, selon l'état de la connexion. Pour protéger contre les attaques de déni de service en remplissant sa capacité de mémorisation d'état, un NAT peut tenter de déterminer activement la vivacité d'une connexion DCCP, ou l'administrateur de NAT pourraient configurer des temporisations plus prudentes.

 	11.	Remerciements

L'auteur tient à remercier Gorry Fairhurst, Eddie Kohler, Dan Wing, Alfred Hoenes, Magnus Westerlund, Miguel Garcia, Catherine Meadows, Tim Polk, Lars Eggert, et Christian Vogt de leurs commentaires et de leur aide sur ce document.

Le présent mémoire emprunte beaucoup à la [RFC5382] de S. Guha (éditeur), K. Biswas, B. Ford, S. Sivakumar, et P. Srisuresh.

 	12.	Références
 	12.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC4340]	E. Kohler et autres, "Protocole de contrôle d'encombrement de datagrammes (DCCP)", mars 2006. (P.S.) (MàJ par 6773)

[RFC4787]	F. Audet, éd., C. Jennings, "Exigences sur le comportement des traducteurs d'adresse réseau (NAT) pour UDP en envoi individuel", janvier 2007, DOI 10.17487/RFC4787. (BCP0127) (MàJ par RFC7857)

[RFC5508]	P. Srisuresh, B. Ford, S. Sivakumar, S. Guha, "Exigences de comportement des NAT pour ICMP", avril 2009. (BCP0148) (MàJ par RFC7857)

[RFC5596]	G. Fairhurst, "Technique d'ouverture simultanée du protocole de contrôle d'encombrement de datagrammes (DCCP) pour faciliter la traversée de NAT/boîtier de médiation", septembre 2009. (MàJ RFC4340) (P.S.) 

 	12.2	Références pour information

[RFC3424]	L. Daigle, éd., IAB, "Considérations de l'IAB sur l'auto correction d'adressage unilatérale (UNSAF) à travers la traduction d'adresse réseau", novembre 2002, DOI 10.17487/RFC3424. (Information)

[RFC5382]	S. Guha et autres, "Exigences sur le comportement des NAT pour TCP", octobre 2008, DOI 10.17487/RFC5382. (BCP0142) (MàJ par RFC7857)

[RFC5595]	G. Fairhurst, "Codes de service du protocole de contrôle d'encombrement de datagrammes (DCCP)", septembre 2009. (MàJ RFC4340) (P.S.)

 	Adresse de l'auteur

Rémi Denis-Courmont
VideoLAN project
mél : rem@videolan.org
URI : http://www.videolan.org/