Groupe de travail Réseau	G. Fairhurst, University of Aberdeen	
Request for Comments: 5595	septembre 2009	
RFC mise à jour : 4340		
Catégorie : Sur la voie de la normalisation 	Traduction Claude Brière de L'Isle	

Codes de service du protocole de contrôle d'encombrement de datagrammes (DCCP)

Résumé
Le présent document décrit l'usage des codes de service par le protocole de contrôle d'encombrement de datagrammes, RFC  4340. Il motive le réglage d'un code de service par les applications. Les codes de service fournissent une méthode pour identifier le service/application prévu pour traiter une demande de connexion DCCP. Cela donne une souplesse accrue dans l'utilisation et l'allocation de numéros d'accès pour le multiplexage de connexion. L'utilisation d'un code de service DCCP peut aussi permettre une coordination plus explicite des services avec des boîtiers de médiation (par exemple, des traducteurs d'adresse réseau et des pare-feu). Le présent document met à jour la spécification de la RFC 4340.

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 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
1.1 Historique	2
1.2 Conventions utilisées dans le document	4
2. Architecture pour les codes de service	4
2.1 Numéros d'accès de l'IANA	4
2.2 Valeurs des codes de service DCCP	4
2.4 Code de service zéro	5
2.5 Code de service invalide	5
2.6 SDP pour décrire les codes de service	5
2.7 Méthode de hachage du code de service sur un accès dynamique	6
3. Utilisation du code de service DCCP	6
3.1 Réglage des codes de service chez le client	6
3.2 Utilisation des codes de service dans le réseau	6
3.3 Utilisation des codes de service chez le serveur	7
4. Considérations sur la sécurité	8
4.1 Réutilisation de numéro d'accès de serveur	9
4.2 Association d'applications à des codes de service	9
4.3 Interactions avec IPsec	9
5. Considérations relatives à l'IANA	9
6. Remerciements	9
8. Références	10
8.1 Références normatives	10
7.2 Références pour information	10
Adresse de l'auteur	11

 	1.	Introduction

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], paragraphe 8.1.2). Un code de service identifie le protocole (ou le profil standard, par exemple, [RFC5762]) à utiliser à la couche application. Il n'est pas destiné à être utilisé pour spécifier une variante d'une application ou une variante spécifique d'un protocole (paragraphe 2.2).

Le mécanisme de code de service permet à une application de déclarer l'ensemble de services associés à des numéros d'accès de serveur. Cela peut affecter comment une application interagit avec DCCP. Cela permet aussi de découpler le rôle des numéros d'accès pour indiquer un service désiré du rôle des numéros d'accès dans le démultiplexage et la gestion d'état. Une application DCCP identifie le service demandé par la valeur de code de service dans un paquet DCCP-Request (demande DCCP). Chaque application associe donc un ou plusieurs codes de service à chaque accès qui écoute ([RFC4340], paragraphe 8.1.2).

L'utilisation des codes de service peut aider à identifier le service voulu à un pare-feu et peut aider d'autres boîtiers de médiation (par exemple, un serveur mandataire ou un traducteur d'adresse réseau (NAT) [RFC2663]). Les boîtiers de médiation qui désirent identifier le type de données qu'un flux prétend transporter devraient utiliser le code de service à cette fin. Quand il est utilisé de façon conséquente, le code de service peut fournir une indication plus spécifique du service réel (par exemple, en indiquant le type de flux multimédia ou le comportement d'application prévu) que de déduire cette information de la valeur de l'accès de serveur.

L'utilisation la plus souple de l'accès de serveur peut aussi offrir des avantages aux applications où les serveurs doivent traiter de très grands nombres d'accès ouverts simultanément pour le même service.

La RFC 4340 omet de décrire la motivation des codes de service, et ne décrit pas correctement comment les accès de serveur bien connus et enregistrés se rapportent aux codes de service. L'intention du présent document est de préciser ces points.

La RFC 4340 déclare que les codes de service ne sont pas destinés à être spécifiques de DCCP. Les codes de service, ou des concepts similaires, peuvent donc aussi être utiles à d'autres protocoles de transport de l'IETF.

 	1.1	Historique
Le plus simple pour comprendre les motifs de la définition des codes de service est de décrire l'histoire du protocole DCCP.

La plupart des protocoles de transport courants de l'Internet (TCP [RFC793], UDP [RFC768], SCTP (le protocole de transmission de commandes de flux) [RFC4960], et UDP-léger [RFC3828]) utilisent les numéros d'accès "publiés" provenant des espaces de numéros bien connus ou enregistrés [RFC0814]. Ces valeurs de 16 bits indiquent le service d'application associé à une connexion ou à un message. L'accès de serveur doit être connu du client pour permettre l'établissement d'une connexion. Cela peut être réalisé en utilisant une signalisation hors bande (par exemple, décrite en utilisant SDP [RFC4566]), mais plus couramment un accès publié est alloué à un protocole ou application particulier ; par exemple, HTTP utilise couramment l'accès 80 et SMTP utilise couramment l'accès 25. Publier un numéro d'accès [RFC1122] implique l'enregistrement auprès de l'Autorité d'allocation des numéros de l'Internet (IANA, Internet Assigned Numbers Authority) ce qui inclut de définir un service par un mot-clé unique et de réserver un numéro d'accès dans un réservoir fixé [IANA].

Dans le plus récent projet de DCCP, les auteurs voulaient régler le problème des accès publiés d'une manière définitive, car cette méthode souffre de plusieurs problèmes :

o	L'espace d'accès n'est pas suffisamment grand pour que les accès soient facilement alloués (par exemple, d'une manière non régulée). Donc, de nombreuses applications opèrent en utilisant des accès non enregistrés, éventuellement avec des collisions avec l'usage par d'autres applications.

o	L'utilisation de pare-feu fondés sur l'accès encourage les rédacteurs d'application à déguiser une application en une autre pour tenter d'outrepasser les règles de filtre de pare-feu. Cela a motivé les constructeurs de pare-feu à utiliser une inspection en profondeur de paquet pour tenter d'identifier le service associé à un numéro d'accès.

o	Les fournisseurs d'accès Internet (FAI) déploient souvent des mandataires transparents, principalement pour améliorer les performances et réduire les coûts. Par exemple, les demandes TCP destinées à l'accès TCP 80 sont souvent redirigées sur un mandataire de la Toile.

Ces problèmes sont couplés. Quand les applications sont en collision sur le même accès publié mais non enregistré, il n'y a pas de façon simple pour un équipement de sécurité du réseau de les distinguer, et donc il est probable que des problèmes vont être introduits par l'interaction des caractéristiques.

Le concepteur de protocole de transport ne peut pas faire grand chose sur les applications qui tentent de se faire passer pour d'autres applications. Pour celles qui ne tentent pas de se cacher, le problème peut être simplement qu'elle ne peuvent pas obtenir de façon simple un accès publié. Idéalement, il devrait être suffisamment facile que chaque rédacteur d'application puisse demander un accès bien connu ou enregistré et en recevoir un instantanément sans qu'on lui pose de questions. L'espace d'accès de 16 bits traditionnellement utilisé n'est pas assez grand pour prendre en charge une allocation aussi triviale des accès.

Donc, les concepteurs de DCCP ont pensé à une solution de remplacement. L'idée était simple. Un espace d'accès de serveur de 32 bits devrait être suffisant pour permettre l'utilisation de politiques d'allocation très simples. Cependant, des considérations de frais généraux rendaient indésirable une valeur d'accès de 32 bits (DCCP devait être utile pour les applications à bas débit).

La solution de DCCP à ce problème était d'utiliser un code de service de 32 bit [RFC4340] qui est seulement inclus dans le paquet DCCP-Request. L'utilisation d'une valeur de 32 bits était destinée à rendre trivialement simple d'obtenir une valeur unique pour chaque application. Placer la valeur dans un paquet DCCP-Request n'exige pas de frais généraux supplémentaires pour le flux de données réel. Il est cependant suffisant pour les deux systèmes d'extrémité, et donne à tous les boîtiers de médiation à états pleins le long du chemin des informations supplémentaires pour comprendre quelles applications sont utilisées.

Les premières discussions du protocole DCCP envisageaient une solution de remplacement à l'utilisation des accès traditionnels ; il était suggéré qu'un client utilise un identifiant de 32 bits pour identifier de façon univoque chaque connexion et que le serveur écoute sur une prise liée seulement à un code de service. Cette solution était sans ambiguïté ; le code de service était le seul identifiant pour une prise d'écoute du côté serveur. Le client DCCP incluait un code de service dans la demande, lui permettant de joindre l'application écoutante correspondante. L'inconvénient est que cela empêchait le déploiement de deux serveurs pour le même service sur une seule machine, chose qui est triviale avec les accès. Cette conception souffrait aussi de l'inconvénient d'être suffisamment différente des protocoles existants pour qu'on puisse craindre que cela empêche l'utilisation de DCCP à travers les NAT et autres boîtiers de médiation.

La RFC 4340 a abandonné l'utilisation d'un identifiant de connexion de 32 bits en faveur des deux valeurs traditionnelles d'accès de 16 bits, une choisie par le serveur et une par le client. Cela permet aux boîtiers de médiation d'utiliser des techniques similaires pour DCCP, UDP, TCP, etc. Cependant, cela introduit un nouveau problème : "Comment l'accès de serveur se rapporte t-il au code de service ?" L'intention était que le code de service identifie l'application ou protocole en utilisant DCCP, fournissant aux boîtiers de médiation les informations sur l'utilisation prévue d'une connexion, et que la paire d'accès forme effectivement un identifiant de connexion de 32 bits, qui soit unique entre une paire de systèmes d'extrémité.

Le grand nombre de valeurs uniques de code de service disponibles permet que toutes les applications reçoivent un code de service unique. Cependant, il restait un problème : l'accès de serveur était choisi par le serveur, mais le client avait besoin de connaître cet accès pour établir une connexion. Il était indésirable de rendre obligatoire une communication hors bande pour découvrir l'accès de serveur. La solution choisie était d'enregistrer les accès de serveur DCCP. La disponibilité limitée des accès de serveur DCCP paraît contradictoire avec les avantages des codes de service DCCP parce que, bien qu'il puisse être trivial d'obtenir un code de service, il n'a traditionnellement pas été trivial d'obtenir un accès enregistré de la part de l'IANA et, à long terme, il pourrait n'être pas possible d'allouer un accès DCCP unique enregistré aux nouvelles applications. Comme les numéros d'accès deviennent rares, cela motive le besoin d'associer plus d'un code de service à un accès d'écoute (par exemple, deux applications différentes pourraient être allouées au même accès de serveur et devoir fonctionner sur le même hôte au même moment, différenciées par leur code de service différent associé).

Les codes de service donnent de la souplesse à la façon dont les clients identifient l'application de serveur à laquelle ils souhaitent communiquer. Le mécanisme permet à un serveur d'associer un ensemble d'accès de serveur à un service. L'ensemble peut être commun avec d'autres services disponibles au même hôte serveur, permettant un plus grand nombre de connexions concurrentes pour un service particulier qu'il n'est possible quand le service est identifié par un seul numéro d'accès publié.

 	1.2	Conventions utilisées dans le document
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].

 	2.	Architecture pour les codes de service

DCCP définit l'utilisation d'une combinaison d'accès et de codes de service pour identifier l'application de serveur ([RFC4340], paragraphe 8.1.2). Ceci est décrit dans les paragraphes qui suivent.

 	2.1	Numéros d'accès de l'IANA
Dans DCCP, les paquets qui appartiennent à une connexion sont démultiplexés sur la base d'une combinaison de quatre valeurs {adresse IP de source, accès de source, adresse IP de destination, accès de destination} comme dans TCP. Une adresse de point d'extrémité est associée à un numéro d'accès (par exemple, formant une prise) et une paire d'associations identifie chaque connexion de façon univoque. Les accès fournissent la fonction fondamentale de démultiplexage par paquet.

L'Autorité d'allocation des numéros de l'Internet gère actuellement l'ensemble mondial des numéros d'accès réservés [IANA]. L'accès de source associé à une demande de connexion, souvent appelé "accès éphémère", est traditionnellement dans la gamme 49152-65535 et inclut aussi la gamme 1024-49151. La valeur utilisée pour l'accès éphémère est généralement choisie par le système d'exploitation du client. Il a été suggéré qu'une valeur de numéro d'accès choisie au hasard, pourrait aider à se défendre contre les attaques "à l'aveugle" [RFC6056] dans TCP. Cette méthode peut être applicable à d'autres protocoles de transport définis par l'IETF, y compris DCCP.

Traditionnellement, la valeur d'accès de destination (serveur) associée à un service est déterminée soit par un indice de système d'exploitation qui pointe sur une copie du tableau de l'IANA (par exemple, getportbyname() dans Unix, qui indexe le fichier /etc/services) soit par l'application en spécifiant une transposition directe.

L'espace de numéros d'accès UDP et TCP, de 0 à 65535, est partagé en trois gammes [RFC2780] :
o	0 0 1023 "bien connu", aussi appelé accès "système",
o	1024 0 49151 "enregistré", aussi appelé accès "utilisateur", et
o	49152 0 65535 "dynamique", aussi appelé accès "privé".

DCCP prend en charge les accès bien connus (Well Known) et enregistrés (Registered). Ils sont alloués dans le registre IANA des numéros d'accès DCCP ([RFC4340], paragraphe 19.9). Chaque accès DCCP enregistré DOIT être associé à au moins un code de service pré-défini.

Les applications qui n'ont pas besoin d'utiliser un accès de serveur dans la gamme "bien connu" ou "enregistré" DEVRAIENT utiliser un accès de serveur dynamique (c'est-à-dire, un qui n'est pas obligé d'être enregistré dans le registre des accès DCCP). Les clients peuvent identifier la valeur de l'accès de serveur pour les services auxquels ils souhaitent se connecter en utilisant une gamme de méthodes. Une méthode courante est par la réception d'un enregistrement SDP (paragraphe 2.6) échangé hors bande (par exemple, en utilisant SIP [RFC3261] ou le protocole d'échange de flux en temps réel (RTSP, Real Time Streaming Protocol) [RFC2326]). Les enregistrements de ressource SRV du DNS fournissent aussi un moyen pour identifier un accès de serveur pour un service particulier sur la base de la chaîne de nom du service [RFC2782].

Les applications qui n'utilisent pas de signalisation hors bande peuvent quand même communiquer, pourvu que le client et le serveur s'accordent sur la valeur de l'accès à utiliser. Cela élimine le besoin que chaque code de service enregistré soit alloué à un accès de serveur alloué par l'IANA (voir aussi le paragraphe 2.7).

 	2.2	Valeurs des codes de service DCCP
DCCP spécifie un code de service de quatre octets ([RFC4340], paragrahe 8.1.2) représenté dans une des trois formes suivantes : un nombre décimal (méthode canonique) une chaîne ASCII de quatre caractères [ANSI.X3-4.1986], ou un nombre hexadécimal de huit chiffres. Tous les codes de service alloués standard, y compris toutes les valeurs allouées par l'IANA, sont obligées d'utiliser une valeur qui puisse être représentée en utilisant un sous ensemble du jeu de caractères ASCII. Les codes de service privés n'ont pas besoin de suivre cette convention, bien que la RFC 4340 suggère que les utilisateurs choisissent des codes de service qui peuvent aussi être représentés en ASCII.

Le code de service identifie le service de niveau application auquel une application cliente souhaite se connecter. Par exemple, des services ont été définis pour le protocole de transport en temps réel (RTP, Real-Time Protocol) [RFC5762]. Dans un autre exemple, la sécurité de la couche de transport de datagramme (DTLS, Datagram Transport Layer Security) [RFC5238] fournit un service de transport (pas un service de couche application) ; donc, les applications qui utilisent DTLS sont identifiées individuellement par un ensemble de valeurs de code de service correspondantes.

Les points d'extrémité DOIVENT associer un code de service à chaque prise DCCP [RFC4340], ouverte activement et passivement. L'application va généralement fournir ce code de service. Un seul accès d'écoute passive peut être associé à plus d'une valeur de code de service. L'ensemble de codes de service pourrait être associé à une ou plusieurs applications de serveur. Cela permet une correspondance plus souple entre services et numéros d'accès que ce qui est possible en utilisant la paire correspondante de prises (quadruplet d'adresses de couche 3 et d'accès de couche 4). Dans l'ensemble actuellement défini de types de paquet, la valeur de code de service est présente seulement dans les paquets DCCP-Request ([RFC4340], paragraphe 5.2) et DCCP-Response ([RFC4340], paragraphe 5.3). Noter que de nouveaux types de paquet DCCP (par exemple, [RFC5596]) pourraient aussi porter une valeur de code de service.

 	2.2.1	Nouvelles versions des applications ou protocoles
Les applications/protocoles qui fournissent une négociation ou indication de version dans le protocole qui opère sur DCCP n'exigent pas un nouvel accès de serveur ou nouveau code de service pour chaque nouvelle version de protocole. Les nouvelles versions de ces applications/protocoles DEVRAIENT continuer d'utiliser le même code de service. Si les développeurs d'application estiment que la nouvelle version fournit des capacités significativement nouvelles (par exemple, qui vont changer le comportement des boîtiers de médiation) elles PEUVENT allouer un nouveau code de service associé au même ou à un ensemble différent d'accès bien connus. Si le nouveau code de service est associé à un accès bien connu ou enregistré, le registre des accès DCCP DOIT aussi être mis à jour pour inclure la nouvelle valeur de de service, mais PEUT partager la ou les mêmes allocations d'accès de serveur.

 	2.3	Registre des codes de service
L'ensemble des codes de service enregistrés dont l'utilisation est spécifiée dans l'Internet général est défini dans un espace de noms contrôlé par l'IANA. L'IANA gère les nouvelles allocations de codes de service dans cet espace [RFC4340]. Les codes de service privés qui ne sont pas alloués centralement sont noté par la gamme décimale 1  056  964  608 à 1  073  741  823 (c'est-à-dire, des valeurs de 32 bits dont l'octet de poids fort est égal à la valeur de 63, correspondant au caractère ASCII "?").

Les associations de code de service à des accès bien connus sont aussi définies dans le registre IANA des accès DCCP (paragraphe 2.1).

 	2.4	Code de service zéro
Un code de service de zéro est "réservé en permanence (il représente l'absence d'un code de service significatif)" [RFC4340]. Cela indique qu'aucune information d'application n'a été fournie. La RFC 4340 déclare que des applications PEUVENT être associées à ce code de service de la même façon qu'à d'autres valeurs de code de service. Cette utilisation est permise pour tout accès de serveur.

Le présent document précise le paragraphe 19.8 de la RFC 4340 en ajoutant ce qui suit :

Les applications NE DEVRAIT PAS utiliser un code de service de zéro.

Les rédacteurs d'application qui ont besoin d'une valeur de code de service temporaire DEVRAIENT choisir une valeur de la gamme privée (paragraphe 2.3).

Les applications destinées à un déploiement dans l'Internet sont invitées à utiliser un code de service défini par l'IANA. Si aucun code de service spécifique n'existe, elles DEVRAIENT demander une nouvelle allocation à l'IANA.

 	2.5	Code de service invalide
La RFC 4340 définit la valeur de code de service de 4 294 967 295 en décimal (0xFFFFFFFF) comme "invalide". Elle est fournie afin que les mises en œuvre puissent utiliser une valeur spéciale de quatre octets pour indiquer "aucun code de service valide". Les mises en œuvre NE DOIVENT PAS accepter une demande DCCP avec cette valeur, et NE DEVRAIENT PAS permettre aux applications de se lier à cette valeur de code de service [RFC4340].

 	2.6	SDP pour décrire les codes de service
Les méthodes qui signalent actuellement des numéros d'accès de destination, comme le protocole de description de session (SDP, Session Description Protocol) [RFC4566], exigent une extension pour prendre en charge les codes de service DCCP [RFC5762].

 	2.7	Méthode de hachage du code de service sur un accès dynamique
Les applications qui n'utilisent pas de signalisation hors bande ou un accès alloé par l'IANA exigent quand même que le client et le serveur s'accordent sur la valeur d'accès de serveur à utiliser. Ce paragraphe décrit une méthode facultative qui permet à une application de déduire un numéro d'accès de serveur par défaut du code de service. La valeur retournée est dans la gamme d'accès dynamique [RFC4340] :

int s_port; /* accès de serveur */
s_port = ((sc[0]<<7)^(sc[1]<<5)^(sc[2]<<3)^sc[3]) | 0xC000;
sif (s_port==0xFFFF) {s_port = 0xC000;}

où sc[] représente les quatre octets du code de service, et sc[3] est l'octet de moindre poids. Par exemple, cette fonction associe SC:fdpz à l'accès de serveur 64634.

Cet algorithme a les propriétés suivantes :
o	Il identifie un accès de serveur par défaut pour chaque service.
o	Il cherche à allouer des codes de service différents aux différents accès, mais ne garantit pas qu'une allocation est unique.
o	Il préserve les quatre bits de moindre poids des octets de fin du code de service, ce qui permet que de nombreuses séries de codes de service communes soient transposées en un ensemble de numéros d'accès adjacents, par exemple, à Foo1, et Foo2, Fooa et Foob seraient alloués à des accès adjacents. (Note : cette numérotation consécutive s'applique seulement aux caractères dans la gamme de 0 à 9, A-O et P-Z. Quand les caractères franchissent une limite de gamme, l'algorithme introduit une discontinuité, résultant en la transposition en accès non consécutifs. Donc, Fooo et Foop se transposent respectivement en les valeurs décimales de 65015 et 65000).
o	Il évite l'accès 0xFFFF, qui n'est pas accessible sur toutes les plates-formes d'hôte.

Les applications et les protocoles de couche supérieure auxquels est alloué un code de service (ou qui utilisent un code de service de l'espace privé non alloué) peuvent utiliser cette méthode. Cela n'empêche pas d'autres applications qui utilisent l'accès de serveur choisi, car les serveurs DCCP sont différenciés par la valeur de code de service.

 	3.	Utilisation du code de service DCCP

Le fonctionnement de base des codes de service est comme suit :

Un client qui initie une connexion produit une DCCP-Request avec un code de service et choisit un numéro d'accès de destination (serveur) qui est supposé être associé au code de service spécifié à la destination.

Un serveur qui reçoit une demande DCCP :
-	détermine si un service disponible correspondant au code de service est supporté pour l'accès de serveur de destination spécifié. La session est associée au code de service et à un serveur correspondant. Une DCCP-Response est retournée.
-	Si le service n'est pas disponible, la session est rejetée et un paquet DCCP-Reset est retourné.

 	3.1	Réglage des codes de service chez le client
Une application cliente DOIT associer chaque connexion DCCP (et donc chaque prise DCCP active) à une seule valeur de code de service [RFC4340]). Cette valeur est utilisée dans le paquet DCCP-Request correspondant.

 	3.2	Utilisation des codes de service dans le réseau
Les connexions DCCP identifiées par le code de service continuent d'utiliser les adresses et accès IP, bien qu'aucun numéro d'accès ne puisse être publié.

Les numéros d'accès et les adresses IP sont les méthodes traditionnelles pour identifier un flux au sein d'un réseau IP. Les mises en œuvre de boîtiers de médiation [RFC3234] ont donc besoin de noter que les nouvelles connexions DCCP sont identifiées par la paire d'accès de serveur et de code de service en plus de l'adresse IP. Cela signifie que l'IANA peut allouer un accès de serveur à plus d'une application DCCP [RFC4340].

Les traducteurs d'adresse et d'accès réseau, appelés collectivement des NAT [RFC2663], peuvent interpréter les accès DCCP ([RFC2993] et [RFC5597]). Ils peuvent aussi interpréter les codes de service DCCP. Interpréter les codes de service DCCP peut réduire le besoin d'interpréter correctement les numéros d'accès, conduisant à de nouvelles opportunités de traducteurs d'adresse et accès réseau. Bien qu'il soit encouragé d'associer des priorités de livraison spécifiques au code de service, par exemple, pour identifier la nature en temps réel d'un flux qui revendique d'utiliser RTP, il n'est pas garanti que les données de connexion réelles correspondent au code de service associé. Une mise en œuvre de boîtier de médiation peut quand même faire une inspection de paquet en profondeur, et utiliser d'autres moyens, pour tenter de vérifier le contenu d'une connexion.

L'utilisation du code de service DCCP peut potentiellement conduire à des interactions avec d'autres protocoles qui interprètent ou modifient les numéros d'accès DCCP [RFC3234]. Les précisions supplémentaires suivantes mettent à jour la description fournie à la Section 16 de la RFC 4340:

o	Un boîtier de médiation qui veut différencier les applications DEVRAIT tester le code de service en plus de l'accès de destination ou de source d'un paquet DCCP-Request ou DCCP-Response.

o	Un boîtier de médiation qui ne modifie pas l'application prévue (par exemple, les NAT [RFC5597] et les pare-feu) NE DOIT PAS changer le code de service.

o	Un boîtier de médiation PEUT envoyer un DCCP-Reset en réponse à un paquet avec un code de service qui est considéré comme non convenable.

 	3.3	Utilisation des codes de service chez le serveur
La combinaison du code de service et de l'accès de serveur ôte les ambiguïtés sur les DCCP-Requests entrantes reçues par un serveur. Le code de service est utilisé pour associer une nouvelle connexion DCCP au service d'application correspondant. Quatre cas peuvent survenir quand deux applications de serveur DCCP écoutent passivement sur le même hôte :
o	Le cas le plus simple est quand deux serveurs sont associés à différents codes de service et sont liés à des accès de serveur différents (paragraphe 3.3.1).
o	Deux serveurs peuvent être associés à la même valeur de code de service DCCP mais être liés à des accès de serveur différents (paragraphe 3.3.2).
o	Deux serveurs pourraient utiliser des valeurs différentes de code de service DCCP et être liés au même accès de serveur (paragraphS 3.3.1).
o	Deux serveurs pourraient tenter d'utiliser le même code de service DCCP et être liés au même accès de serveur. Une mise en œuvre de DCCP DOIT interdire cela, car il n'y a aucun moyen pour l'hôte DCCP de diriger une nouvelle connexion sur l'application de serveur correcte.

La RFC 4340 (paragraphe 8.1.2) déclare qu'une mise en œuvre DOIT associer chaque prise active à exactement un code de service sur un accès de serveur spécifié.

De plus, le paragraphe 8.1.2 de la RFC 4340 déclare aussi : "Les prises passive PEUVENT, à la discrétion de la mise en œuvre, être associées à plus d'un code de service ; cela pourrait laisser plusieurs applications, ou plusieurs versions de la même application, écouter sur le même accès, différenciées par le code de service."

Le présent document met à jour le texte de la RFC 4340 ci-dessus en le remplaçant par ce qui suit :
Une mise en œuvre DEVRAIT permettre que plus d'un code de service soit associé à un accès de serveur passif, permettant à plusieurs applications, ou plusieurs versions d'une application, d'écouter sur le même accès, différenciées par le code de service associé.

Il ajoute aussi : "Une mise en œuvre DEVRAIT fournir une méthode qui informe un serveur de la valeur du code de service qui a été choisie par une connexion active."

Un seul accès ouvert passif (d'écoute) PEUT donc être associé à plusieurs codes de service, bien qu'une connexion active (ouverte) puisse seulement être associée à un seul code de service. Une seule application peut souhaiter accepter des connexions pour plus d'un code de service en utilisant le même accès de serveur. Cela peut permettre à un serveur d'offrir plus que la limite de 65  536 services selon la taille du champ "Port". La limite supérieure est seulement fondée sur le nombre de connexions uniques entre deux hôtes (c'est-à-dire, 4  294  967  296).

 	3.3.1	Réception d'une demande DCCP
Quand une demande DCCP est reçue et que l'accès de destination spécifié n'est pas lié à un serveur, l'hôte DOIT rejeter la connexion en produisant un DCCP-Reset avec le code de réinitialisation de "Connexion refusée". Un hôte PEUT aussi utiliser le code de réinitialisation de "Trop occupé" ([RFC4340], paragraphe 8.1.3).

Quand l'accès de destination demandé est lié à un serveur, l'hôte DOIT aussi vérifier que l'accès de serveur est associé au code de service spécifié (il pourrait y avoir plusieurs valeurs de code de service associées au même accès de serveur). Deux cas peuvent se produire :
o	Si l'hôte receveur écoute sur un accès de serveur et si la DCCP-Request utilise un code de service qui est associé à l'accès, l'hôte accepte la connexion. Une fois connecté, le serveur retourne une copie du code de service dans le paquet DCCP-Response, terminant la prise de contact initiale [RFC4340].
o	Si l'accès de serveur n'est pas associé au code de service demandé, le serveur DEVRAIT rejeter la demande en envoyant un paquet DCCP-Reset avec le code de réinitialisation 8, "Mauvais code de service" ([RFC4340], paragraphe 8.1.2) mais PEUT utiliser la raison "Connexion refusée".

Après qu'une connexion a été acceptée, le bloc de contrôle du protocole est associé à une paire d'accès, une paire d'adresses IP, et une seule valeur de code de service.

 	3.3.2	Plusieurs associations d'un code de service à des accès
Les codes de service DCCP ne sont pas restreints à des accès spécifiques, bien qu'ils puissent être associés à un accès bien connu spécifique. Cela permet que la même valeur de code de service DCCP soit associée à plus d'un accès de serveur (en état actif ou passif).

 	3.3.3	Lancement automatique d'un serveur
Une mise en œuvre d'hôte peut permettre qu'un service soit associé à un accès de serveur (ou gamme d'accès) qui ne soit pas en fonctionnement permanent sur le serveur. Dans ce cas, l'arrivée d'une demande DCCP peut exiger une méthode pour associer une demande DCCP à un serveur qui traite le code de service correspondant. Cette opération pourrait ressembler à celle de "inetd" [inetd].

Comme dans le paragraphe précédent, quand le code de service spécifié n'est pas associé à l'accès de serveur spécifié, la connexion DOIT être interrompue et un message DCCP-Reset envoyé [RFC4340].

 	4.	Considérations sur la sécurité

Les considérations sur la sécurité de la RFC 4340 identifient et offrent des directives sur les questions de sécurité relatives à DCCP. Le présent document discute de l'usage des codes de service. Il ne décrit pas de nouvelles fonctions du protocole.

Tous les modes IPsec protègent l'intégrité de l'en-tête DCCP. Cela protège le champ de code de service contre une modification non détectée au sein du réseau. De plus, le mode IPsec de charge utile de sécurité encapsulée (ESP, Encapsulated Security Payload) peut être utilisé pour chiffrer le champ Code de service, cachant la valeur du code de service dans le réseau et empêchant aussi l'interprétation par les boîtiers de médiation. L'en-tête DCCP n'est pas protégé par la sécurité de couche application (par exemple, l'utilisation de DTLS [RFC5238] comme spécifié dans DTLS/DCCP [RFC4347]).

Quatre domaines de sécurité sont importants :
1.	La réutilisation de numéro d'accès de serveur (paragraphe 4.1).
2.	L'interaction avec les NAT et les pare-feu (paragraphe 3.2 décrit le comportement des boîtiers de médiation). Les exigences relatives à DCCP sont décrites dans la [RFC5597].
3.	L'interprétation des codes de service DCCP outrepassant l'utilisation traditionnelle de numéros d'accès réservés/bien connus (paragraphe 4.2).
4.	L'interaction avec IPsec et la sécurité DTLS (paragraphe 4.3).

 	4.1	Réutilisation de numéro d'accès de serveur
Les codes de service sont utilisé en plus des accès quand on démultiplexe les connexions entrantes. Cela change le modèle de service à utiliser par les applications et les boîtiers de médiation. Le registre des numéros d'accès contient déjà des instances de plusieurs enregistrements d'application pour un seul numéro d'accès pour TCP et UDP. Ils sont relativement rares. Comme le code de service DCCP permet que plusieurs applications partagent en toute sécurité le même numéro d'accès, même sur le même hôte, le numéro d'accès de serveur réutilisé dans DCCP peut être plus courant que dans TCP et UDP.

 	4.2	Association d'applications à des codes de service
L'utilisation de codes de service fournit des retours plus directs qu'un service concret associé à un accès donné sur un serveur que pour un service qui n'emploie pas de codes de service. En répondant à une demande de connexion entrante, les systèmes qui n'utilisent pas ces codes peuvent indiquer qu'un service est, ou n'est pas, disponible sur un accès donné, mais les systèmes qui utilisent ce mécanisme fournissent une confirmation (ou dénégation) immédiate qu'un service particulier est présent. Cela peut avoir des implications en termes d'examen et reconnaissance d'accès.

Il faut faire attention quand on interprète la transposition d'une valeur de code de service en le service correspondant. Le même service (application) peut être accédé en utilisant plus d'un code de service. Des exemples incluent l'utilisation de codes de service distincts pour une application mise en couche directement sur DCCP et une qui utilise le transport DTLS sur DCCP [RFC5238]. D'autres possibilités incluent l'utilisation d'un code de service privé pour transposer en une application à qui a déjà été allouée une valeur de code de service définie par l'IANA, ou plusieurs valeurs de code de service qui se transposent en une seule application fournissant plus d'un service. Différentes versions d'un service (application) peuvent aussi être transposées en un ensemble correspondant de valeurs de code de service.

Le traitement des codes de service peut impliquer plus de traitement que ce qui est couramment associé à des numéros d'accès entrants. Les mises en œuvre doivent se garder contre des opportunités croissantes d'attaques de déni de service.

 	4.3	Interactions avec IPsec
Le protocole d'échange de clés Internet (IKEv2, Internet Key Exchange protocol) ne spécifie actuellement pas de méthode pour utiliser des codes de service DCCP au titre des informations utilisées pour établir une association de sécurité IPsec.

IPsec utilise des numéros d'accès pour effectuer le contrôle d'accès en mode transport [RFC4301]. Des politiques de sécurité peuvent définir un contrôle d'accès spécifique de l'accès (PROTECT, BYPASS, DISCARD) ainsi que des algorithmes et clés spécifiques de l'accès. De même, des politiques de pare-feu permettent ou bloquent le trafic sur la base des numéros d'accès.

L'utilisation de numéros d'accès dans les sélecteurs IPsec et les pare-feu peut supposer que les numéros correspondent à des services bien connus. Il est utile de noter qu'il n'y a pas cette exigence ; tout service peut fonctionner sur tout accès, sous réserve d'un accord mutuel entre les hôtes d'extrémité. L'utilisation d'un code de service peut interférer avec cette hypothèse aussi bien dans IPsec que dans d'autres systèmes de pare-feu, mais cela n'ajoute pas de nouvelle vulnérabilité. Les nouvelles mises en œuvre de IPsec et de systèmes de pare-feu peuvent interpréter le code de service quand elles mettent en œuvre des règles de politique, mais ne devraient pas s'appuyer sur les numéros d'accès ou les codes de service pour indiquer un service spécifique.

 	5.	Considérations relatives à l'IANA

Le présent document ne met pas à jour les procédures d'allocation de l'IANA pour les registres de numéro d'accès DCCP et de codes de service DCCP définies dans la RFC 4340.

Pour être complet, le document note qu'il n'est pas exigé de fournir un document approuvé (par exemple, une RFC publiée) pour prendre en charge une application pour une valeur de code de service ou de numéro d'accès DCCP, bien que des RFC puissent être utilisées pour demander des valeurs de code de service via la Section des considérations relatives à l'IANA. Une spécification est cependant requise pour allouer un code de service qui utilise une combinaison de chiffres ASCII, de lettres majuscules, et de caractères d'espace, '-', '.', et '/') [RFC4340].

 	6.	Remerciements

Le présent travail a été soutenu par le projet EC IST SatSix. Des contributions significatives au présent document ont résulté de discussions avec Joe Touch, et celui-ci a droit à nos chaleureux remerciements. L'auteur remercie aussi Ian McDonald, Fernando Gont, Eddie Kohler, et le groupe de travail DCCP pour leurs commentaires utiles sur ce sujet, et Gerrit Renker pour son aide à déterminer le comportement DCCP et la relecture de ce document. Mark Handley a fourni des apports significatifs au texte sur la définition des codes de service et leur utilisation. Il a aussi beaucoup contribué au matériaux qui ont formé la section d'arrière plan historique.

 	8.	Références
 	8.1	Références normatives

[RFC1122]	R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, DOI 10.17487/RFC1122, octobre 1989. (MàJ par RFC6633, 8029, 9293 )

[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)

[RFC5597]	R. Denis-Courmont, "Exigences comportementales des traducteurs d'adresse réseau (NAT) pour le protocole de contrôle d'encombrement de datagramme", BCP0150, septembre 2009. 

 	7.2	Références pour information
[ANSI.X3-4]	American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.

[IANA]	Internet Assigned Numbers Authority, www.iana.org.

[inetd]	The extended inetd project, http://xinetd.org.

[RFC0768]	J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.

[RFC0793]	J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7,  DOI 10.17487/RFC0793, septembre 1981. (Remplacée par 9293)

[RFC0814]	D. Clark, "Noms, adresses, accès et chemins", juillet 1982. (Information)

[RFC2326]	H. Schulzrinne, A. Rao et R. Lanphier, "Protocole de flux directs en temps réel (RTSP)", avril 1998. (Remplacée par RFC7826)

[RFC2663]	P. Srisuresh, M. Holdrege, "Terminologie et considérations sur les traducteurs d'adresse réseau IP (NAT)", août 1999. (Information)

[RFC2780]	S. Bradner et V. Paxson, "Lignes directrices pour les allocations par l'IANA des valeurs du protocole Internet et des en-têtes qui s'y rapportent", BCP 37, mars 2000.

[RFC2782]	A. Gulbrandsen, P. Vixie et L. Esibov, "Enregistrement de ressource DNS pour la spécification de la localisation des services (DNS SRV)", février 2000, DOI 10.17487/RFC2782.

[RFC2993]	T. Hain, "Implications architecturales des traducteurs d'adresse réseau (NAT)", novembre 2000. (Information)

[RFC3234]	B. Carpenter, S. Brim, "Boîtiers de médiation : taxonomie et problèmes", février 2002. (Information)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002, DOI 10.17487/RFC3261. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3828]	L-A. Larzon et autres, "Protocole léger de datagramme d'utilisateur (UDP-Lite)", juillet 2004. (P.S, MàJ par RFC6335)

[RFC4301]	S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", DOI 10.17487/RFC4301, décembre 2005. (P.S.) (Remplace la RFC2401)

[RFC4347]	E. Rescorla, N. Modadugu, "Sécurité de la couche de transport de datagrammes", avril 2006. (P.S.)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006, DOI 10.17487/RFC4566. (P.S.  ; remplacée par RFC8866)

[RFC4960]	R. Stewart, éd., "Protocole de transmission de commandes de flux (SCTP)", septembre 2007. (Remplace RFC2960, RFC3309 ; P.S. ; Remplacée par RFC9260)

[RFC5238]	T. Phelan, "Sécurité de la couche de transport de datagrammes (DTLS) sur le protocole de contrôle de l'encombrement de datagrammes (DCCP)", DOI 10.17487/RFC5238, mai 2008. (P.S.)

[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.) 

[RFC5762]	C. Perkins, "RTP et le protocole de contrôle de l'encombrement de datagrammes (DCCP)", avril 2010. (P. S.) (MàJ par la RFC6773)

[RFC6056]	M. Larsen, F.Gont, "Recommandations d'aléa pour l'accès transport-protocole", BCP156, janvier 2011.

 	Adresse de l'auteur
Godred Fairhurst,
School of Engineering,
University of Aberdeen,
Kings College,
Aberdeen, AB24 3UE,
UK
mél : gorry@erg.abdn.ac.uk
URL : http://www.erg.abdn.ac.uk/users/gorry