Services différenciés et tunnels

Statut de ce mémoire

Le présent mémoire apporte des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé

Le présent document examine l'interaction des services différenciés (diffserv) (RFC 2474, RFC 2475) et des tunnels IP de diverses formes. La discussion des tunnels dans l'architecture diffserv (RFC 2475) donne des lignes directrices insuffisantes aux concepteurs de tunnels et à leur mise en œuvre. Ce document décrit deux modèles conceptuels pour l'interaction de diffserv avec les tunnels du protocole Internet (IP) et les emploie pour explorer les configurations et les combinaisons de fonctionnalités résultantes. Une considération importante est celle de la façon et de l'endroit où il est approprié d'effectuer le conditionnement du trafic diffserv en présence d'encapsulation et désencapsulation de tunnel. Quelques mécanismes simples sont aussi proposés pour limiter la complexité qu'ajouteraient autrement les tunnels au modèle diffserv de conditionnement du trafic. Les considérations pour la sécurité concernant les tunnels IPSec limitent les fonctionnalités possibles dans certaines circonstances.

1.   Conventions utilisées dans le document

Un tunnel IP encapsule du trafic IP dans un autre en-tête IP lorsque il passe à travers le tunnel ; la présence de ces deux en-têtes IP est une caractéristique de définition des tunnels IP, bien qu'il puisse y avoir des en-têtes supplémentaires insérés entre les deux en-têtes IP. L'en-tête IP interne est celui du trafic original ; un en-tête IP externe est attaché et détaché aux points d'extrémité du tunnel. En général, les nœuds de réseau intermédiaires entre les points d'extrémité du tunnel n'opèrent que sur l'en-tête IP externe, et donc les nœuds intermédiaires à capacité diffserv n'accèdent et ne modifient que le champ DSCP dans l'en-tête IP externe. Dans ce document, les termes de "tunnel" et "tunnel IP" sont utilisés de façon interchangeable. Pour simplifier, ce document ne considère pas de tunnels autres que des tunnels IP (c'est-à-dire, pour lesquels il n'y a pas d'en-tête IP encapsulant) tels que les chemins MPLS et les "tunnels" formés par l'encapsulation dans des en-têtes de couche 2 (de liaison), bien que le modèle conceptuel et l'approche décrits ici puissent être utiles pour comprendre l'interaction de diffserv avec de tels tunnels.

Cette analyse considère les tunnels comme unidirectionnels ; les tunnels bidirectionnels sont considérés comme composés de deux tunnels unidirectionnels portant du trafic dans des directions opposées entre les mêmes points d'extrémité de tunnel. Un tunnel consiste en une entrée où le trafic entre dans le tunnel et est encapsulé par l'ajout de l'en-tête IP externe, en une sortie où le trafic sort du tunnel et est désencapsulé par le retrait de l'en-tête IP externe, et des nœuds intermédiaires à travers lesquels le trafic tunnelé passe entre l'entrée et la sortie. Le présent document ne fait aucune hypothèse sur l'acheminement et la transmission du trafic du tunnel, et en particulier ne suppose ni la présence ni l'absence d'aucune forme de marquage de chemin.

2.   Présentation de diffserv et des tunnels

La complexité des tunnels va des simples tunnels IP dans IP [RFC 2003] aux tunnels multi protocoles les plus complexes, comme IP dans PPP en L2TP en mode transport IPSec [RFC 1661, RFC 2401, RFC 2661]. La configuration de tunnel la plus générale est celle dans laquelle le tunnel n'est pas de bout en bout, c'est-à-dire, que les nœuds d'entrée et de sortie ne sont pas les nœuds de source et de destination pour le trafic porté par le tunnel ; un tel tunnel peut porter du trafic avec plusieurs sources et destinations. Si le nœud d'entrée est la source de bout en bout de tout le trafic dans le tunnel, le résultat est une configuration simplifiée à laquelle la plus grande partie de l'analyse et des lignes directrices du présent document sont applicables, et il en est de même si le nœud de sortie est la destination de bout en bout.

Un premier sujet de préoccupation pour les services différenciés est l'utilisation de la séquence codée de services différenciés (DSCP, Differentiated Services Code Point) dans l'en-tête IP [RFC 2474, RFC 2475]. L'architecture diffserv permet aux nœuds intermédiaires d'examiner et changer la valeur de la DSCP, dont il peut résulter que la valeur de la DSCP dans l'en-tête IP externe sera modifiée entre l'entrée et la sortie du tunnel. Lorsque un tunnel n'est pas de bout en bout, il y a des circonstances dans lesquelles il peut être désirable de propager la DSCP et/ou certaines des informations qu'elle contient à l'en-tête IP externe en entrée et/ou en retour à l'en-tête IP interne en sortie. La situation face à laquelle se trouvent actuellement les développeurs est que la [RFC 2475] offre des lignes directrices incomplètes. La ligne directrice G.7 à la Section 3 en est un exemple, car certaines spécifications de PHB (per hop behaviour, comportement bond par bond) l'ont suivie en spécifiant explicitement les PHB qui peuvent être utilisés dans l'en-tête IP externe pour le trafic tunnelé. Cela est trop restrictif ; par exemple, si une spécification exige que le même PHB soit utilisé dans les deux en-têtes IP externe et interne, le trafic se conformant à cette spécification ne peut pas être tunnelé à travers les domaines ou réseaux qui ne prennent pas en charge ce PHB.

Une approche plus souple qui devrait plutôt être utilisée consiste à décrire les propriétés comportementales d'un PHB qu'il est important de préserve lorsque le trafic est tunnelé et permet que l'en-tête IP externe soit marqué d'une façon suffisante pour préserver ces propriétés.

Le présent document propose une approche dans laquelle le conditionnement du trafic est effectué en série avec le traitement d'entrée ou sortie du tunnel, plutôt qu'en parallèle. Cette approche ne crée aucun chemin supplémentaire de transmission d'information à travers un point d'extrémité de tunnel, car toutes les informations diffserv sont contenues dans les DSCP dans les en-têtes IP. L'architecture IPSec [RFC 2401] exige que ce soit le cas pour préserver les propriétés de sécurité à la sortie des tunnels IPSec, mais cette approche évite aussi de compliquer les blocs de conditionnement du trafic diffserv en introduisant des données hors bande. Une conséquence de cette approche est que la dernière phrase de la ligne directrice G.7 de la Section 3 de [RFC 2475] devient douteuse parce qu'il n'y a pas de composant de sortie de tunnel diffserv qui ait accès aux deux DSCP interne et externe.

Un avantage supplémentaire de cette approche de conditionnement du trafic est qu'elle ne fait pas peser d'autre restriction sur le positionnement des frontières de domaine diffserv par rapport au conditionnement du trafic et aux composants d'encapsulation/désencapsulation de tunnel. Une classe de configurations intéressante concerne la frontière de domaine diffserv qui passe à travers (c'est-à-dire, divise) un nœud de réseau ; un telle frontière peut être fendue pour créer une région de style réseau intermédiaire entre les domaines qui contiennent le processus d'encapsulation ou désencapsulation de tunnel. Le conditionnement du trafic Diffserv n'est pas approprié pour de telles régions de style réseau intermédiaire, car le conditionnement du trafic fait partie du fonctionnement et de la gestion des domaines diffserv.

3.   Modèles conceptuels pour les tunnels Diffserv

Cette analyse introduit deux modèles conceptuels de conditionnement du trafic pour les tunnels IP sur la base d'un exposé initial qui suppose un réseau à pleine capacité diffserv. Les configurations dans lesquelles ce n'est pas le cas sont examinées au paragraphe 3.2.

3.1   Modèles conceptuels pour configurations à pleine capacité DS

Le premier modèle conceptuel est un modèle uniforme qui voit les tunnels IP comme des artifices de chemin de bout en bout du point de vue du conditionnement du trafic ; les tunnels peuvent être des mécanismes nécessaires pour amener le trafic à sa ou ses destinations, mais ils n'ont pas d'impact significatif sur le conditionnement du trafic. Dans ce modèle, tout paquet a exactement un champ DS qui est utilisé pour le conditionnement du trafic en tout point, à savoir le champ DS dans l'en-tête IP le plus externe ; tous les autres sont ignorés. Les mises en œuvre de ce modèle copient la valeur de la DSCP dans l'en-tête IP externe à l'encapsulation et copient la valeur de la DSCP de l'en-tête externe dans l'en-tête IP interne à la désencapsulation. L'utilisation de ce modèle permet aux tunnels IP d'être configurés sans considération des frontières de domaine diffserv parce que la fonction de conditionnement du trafic diffserv n'est pas impactée par la présence des tunnels IP.

Le second modèle conceptuel est un modèle de tuyau qui voit un tunnel IP comme cachant les nœuds entre son entrée et sa sortie de telle sorte qu'ils ne participent pas pleinement au conditionnement du trafic. Dans ce modèle, un nœud de sortie de tunnel utilise les informations de conditionnement du trafic convoyées depuis l'entrée du tunnel par la valeur de DSCP dans l'en-tête interne, et ignore (c'est-à-dire, élimine) la valeur DSCP dans l'en-tête externe. Le modèle du tuyau ne peut pas cacher complètement le conditionnement du trafic au sein du tunnel, car les effets de l'abandon et du reformatage aux nœuds intermédiaires du tunnel peuvent être visibles à la sortie du tunnel et au delà.

Le modèle du tuyau a des conséquences sur le conditionnement du trafic lorsque les nœuds d'entrée et de sortie sont dans des domaines diffserv différents. Dans une telle situation, le nœud d'entrée doit effectuer du conditionnement de trafic pour s'assurer que le trafic qui sort du tunnel a des valeurs de DSCP acceptables pour le domaine diffserv de sortie (voir la Section 6 de l'architecture diffserv [RFC 2475]). On peut utiliser un accord de conditionnement de trafic (TCA, Traffic Conditioning Agreement) inter domaine entre les domaines diffserv qui contiennent les nœuds d'entrée et de sortie du tunnel pour réduire ou éliminer le conditionnement de trafic de sortie. L'élimination complète du conditionnement du trafic de sortie exige que les domaines diffserv à l'entrée et à la sortie aient des politiques d'approvisionnement de service compatibles pour le trafic tunnelé et prennent en charge tous les groupes de PHB et les valeurs DSCP utilisées pour ce trafic d'une manière cohérente. Des exemples de cette situation sont fournis par certains tunnels de réseaux virtuels privés ; il peut être utile de voir de tels tunnels comme reliant les domaines diffserv à leurs points d'extrémité dans une région diffserv en rendant les points d'extrémité de tunnel virtuellement contigus même si ils peuvent être physiquement séparés par des nœuds réseau intermédiaires.

Le modèle du tuyau est aussi approprié pour les situations dans lesquelles la DSCP porte elle-même les informations à travers le tunnel. Par exemple, si le transit entre deux domaines est obtenu via un chemin qui utilise le PHB EF [RFC2598], les informations de préséance d'abandon dans les valeurs de DSCP de PHB AF [RFC 2597] seront perdues à moins que quelque chose ne soit fait pour les préserver ; un tunnel IP est un des mécanismes de préservation possibles. Un chemin qui traverse un ou plusieurs domaines non diffserv entre ses points d'extrémité à capacité DS peut rencontrer un phénomène similaire de perte d'informations si un tunnel n'est pas utilisé à cause de l'ensemble limité de codets DSCP qui sont compatibles avec de tels domaines.

3.2   Considérations sur les configurations à capacité DS partielle

Si seul le nœud de sortie du tunnel a lé capacité DS, la [RFC2475] exige que le nœud de sortie effectue tout conditionnement de trafic de bordure nécessité par le domaine diffserv pour le trafic tunnelé entrant de l'extérieur du domaine. Si le nœud de sortie n'était pas par ailleurs un nœud de bordure DS, une façon de satisfaire cette exigence est d'effectuer le conditionnement du trafic bordure à un nœud bordure DS amont approprié au sein du tunnel, et de copier la valeur DSCP de l'en-tête IP externe dans l'en-tête IP interne au titre du traitement de désencapsulation du tunnel ; ceci applique le modèle uniforme à la portion du tunnel au sein du domaine diffserv du nœud de sortie. Une solution de remplacement est d'éliminer la valeur DSCP externe au titre du traitement de désencapsulation, ce qui réduit le problème et les exigences du conditionnement de trafic résultant à celui d'un nœud d'entrée DS ordinaire. Ceci applique le modèle du tuyau à la portion du tunnel au sein du domaine diffserv du nœud de sortie et donc le nœud amont adjacent pour les besoins du marquage DSCP est le nœud d'entrée du tunnel, plutôt que le nœud intermédiaire du tunnel immédiatement en amont.

Si seul le nœud d'entrée du tunnel a la capacité DS, la [RFC2475] exige que le trafic émergeant du tunnel soit compatible avec le réseau à la sortie du tunnel. Si le traitement de désencapsulation du tunnel élimine la valeur DSCP de l'en-tête externe sans changer la valeur DSCP de l'en-tête interne, le nœud d'entrée de tunnel à capacité DS est obligé de régler le DSCP d'en-tête interne à une valeur compatible avec le réseau à la sortie du tunnel. La valeur 0 (DSCP de 000000) est utilisée à cette fin par un certain nombre de mises en œuvre de tunnel existantes. Si le réseau de sortie met en œuvre la préséance IP comme spécifié dans la [RFC0791], certains ou tous les codes DSCP des huit classes de sélecteur définies dans la [RFC2474] peuvent être utilisables. Les codes DSCP autres que les sélecteurs de classe ne conviennent généralement pas pour cela, car un fonctionnement correct exigera normalement la fonction diffserv au nœud de sortie du tunnel sans capacité DS.

4.   Fonctionnalité d'entrée

Comme décrit à la Section 3 ci-dessus, cette analyse se fonde sur une approche dans laquelle la fonction diffserv et/ou les chemins de communication hors bande ne sont pas placés en parallèle avec le traitement d'encapsulation de tunnel. Cela permet trois localisations possibles pour le conditionnement du trafic par rapport au processus d'encapsulation du tunnel, comme le montre le diagramme suivant qui décrit les flux d'en-têtes IP à travers l'encapsulation de tunnel :

                                      +--------- [2 - Externe] -->>

                                     /

                                    /

  >>---- [1 - Avant] -------- Encapsule ------ [3 - Interne] -->>

Le conditionnement du trafic à [1 - Avant] est logiquement séparé du tunnel, car il n'est pas impacté par la présence de l'encapsulation de tunnel, et devrait donc être permis par les concepts et spécifications de tunnel. Le conditionnement du trafic en [2 - Externe] peut interagir avec les protocoles de tunnel qui sont sensibles à la réorganisation de paquet ; de tels tunnels peuvent avoir besoin de limiter la fonctionnalité en [2 - Externe] comme il sera expliqué au paragraphe 5.1. En l'absence de sensibilité à la réorganisation, aucune restriction supplémentaire ne devrait être nécessaire, bien que le conditionnement du trafic en [2 - Externe] puisse entraîner un re-marquage du trafic pour être compatible avec le prochain domaine diffserv dans lequel entre le trafic tunnelé.

À l'opposé, la localisation [3 - Interne] est difficile à utiliser pour le conditionnement du trafic parce qu'elle exige une fonction qui atteigne l'intérieur du paquet pour fonctionner sur l'en-tête IP interne. Cela est impossible pour les tunnels IPSec et pour tous les autres tunnels qui sont cryptés ou emploient des vérifications d'intégrité cryptographiques. Et donc, le conditionnement du trafic en [3 - Interne] ne peut souvent être effectué qu'au titre du processus d'encapsulation du tunnel, ce qui complique la mise en œuvre aussi bien de l'encapsulation que du conditionnement du trafic. Dans de nombreux cas, la fonction désirée peut être obtenue via une combinaison de conditionneurs de trafic dans les deux autres localisations, qui peuvent toutes deux être spécifiées et mises en œuvre indépendamment de l'encapsulation du tunnel.

Une exception pour laquelle la fonction de conditionnement de trafic est nécessaire en [3 - Interne] survient lorsque la sortie du tunnel sans capacité DS élimine l'en-tête IP externe au titre du traitement de désencapsulation, et donc le DSCP dans l'en-tête IP interne doit être compatible avec le réseau de sortie. Régler le DSCP interne à 0 au titre de l'encapsulation répond à la plupart de ces cas, et les valeurs de code DCSP de sélecteur de classe sont aussi utiles à cette fin, car elles sont valides pour les réseaux qui prennent en charge la préséance IP [RFC0791].

Le tableau suivant résume les relations réalisables entre les valeurs de DSCP Avant (A), Externe (E), et Interne (I) et les localisations correspondantes de la logique de conditionnement du trafic.

Une combinaison de [1 - Avant] et [2 - Externe] est applicable à de nombreux cas couverts par les deux dernières lignes du tableau, et peuvent être préférables au déploiement de la fonction en [3 - Interne]. Le conditionnement du trafic peut encore être requis pour des besoins tels que le contrôle de débit et de salves même si les valeurs DSCP ne sont pas changées.

4.1   Choix du DSCP d'entrée et réarrangement

Il peut être nécessaire ou désirable de limiter les agrégats de comportement DS qui utilisent un tunnel IP sensible au réarrangement de paquet au sein du tunnel. L'architecture diffserv permet le réarrangement de paquets lorsque ils appartiennent à des agrégats de comportement auxquels le réarrangement est permis ; par exemple, le réarrangement est permis aux agrégats de comportement marqués avec différents sélecteurs de classe DSCP [RFC 2474]. IPSec [RFC 2401] et L2TP [RFC 2661] donnent des exemples de tunnels qui sont sensibles au réarrangement de paquet. Si la prise en charge de l'anti-répétition d'IPSec est configurée, des événements d'audit sont générés en réponse aux réarrangements de paquets qui dépassent certains niveaux, les événements d'audit indiquant d'éventuels problèmes de sécurité. L2TP peut être configuré pour restaurer l'arrangement d'entrée des paquets à la sortie du tunnel, défaisant non seulement toute différenciation fondée sur le réarrangement au sein du tunnel, mais aussi avec un impact négatif sur le trafic (par exemple, en accroissant la latence). Le modèle uniforme ne peut pas être appliqué complètement à de tels tunnels, car des mélanges arbitraires de trafic provenant de différents agrégats de comportement peuvent causer des interactions indésirables.

La plus simple méthode pour éviter des interactions indésirables de réarrangement avec des protocoles et caractéristique de tunnel sensibles au réarrangement est de ne pas employer les protocoles ou caractéristiques sensibles au réarrangement, mais cela est souvent non désirable ou même impossible. Lorsque de tels protocoles ou caractéristiques sont utilisés, les interactions peuvent être évitées en s'assurant que les flux agrégés à travers le tunnel sont marqués à [2 - Externe] pour constituer un seul agrégat d'arrangement (c'est-à-dire que les PHB utilisés partagent une contrainte d'arrangement qui empêche le réarrangement des paquets). Les spécifications de protocole de tunnel devraient indiquer à la fois si et dans quelles circonstances un tunnel devrait être restreint à un seul agrégat de rangement ainsi que les conséquences de la violation de cette restriction. Pour les exemples d'IPSec et L2TP exposés plus haut, les spécifications devraient restreindre chaque tunnel à un seul agrégat de rangement lorsque des caractéristiques de protocole sensibles au réarrangement sont configurées, et elles peuvent adopter l'approche de restreindre tous les tunnels afin d'éviter les conséquences inattendues de changements des caractéristiques du protocole ou de la composition du trafic tunnelé. Les mises en œuvre de Diffserv ne devraient pas essayer de regarder au sein de tels tunnels pour y fournir une différenciation fondée sur le réarrangement aux micro flux encapsulés. Si une différenciation fondée sur le réarrangement est désirée au sein de tels tunnels, plusieurs tunnels en parallèle entre les mêmes points d'extrémité devraient être utilisés. Cela permet au réarrangement entre paquets dans les différents tunnels de coexister avec une absence de réarrangement des paquets au sein de chaque tunnel individuel. Pour IPSec et les protocoles de sécurité qui s'y rapportent, il n'y a pas d'avantage cryptographique à utiliser un seul tunnel pour plusieurs agrégats d'arrangement plutôt que plusieurs tunnels parce que toute analyse de trafic rendue possible par l'utilisation de plusieurs tunnels peut aussi être effectuée sur la base des DSCP dans les en-têtes externes du trafic dans un seul tunnel. En général, les ressources supplémentaires requises pour prendre en charge plusieurs tunnels (par exemple, des contextes cryptographiques) et l'impact de plusieurs tunnels sur la gestion de réseau devraient être pris en considération pour déterminer si et où les déployer.

4.2   Choix du tunnel

Les caractéristiques du comportement d'un tunnel sont une considération importante pour déterminer quel trafic devrait utiliser le tunnel. Cela implique les politiques d'approvisionnement de service de tous les domaines participants, et pas seulement les PHB et les DSCP marqués sur le trafic à [2 - Externe]. Par exemple, alors qu'en général c'est une mauvaise idée de tunneler le trafic de PHB EF via un tunnel de PHB par défaut, cela peut être acceptable si le trafic EF est le seul trafic qui utilise le tunnel, et si le tunnel est provisionné de façon adéquate pour préserver les caractéristiques comportementales requise par le PHB EF.

Les politiques d'approvisionnement de service sont chargées d'empêcher des discordances comme de transmettre le trafic EF via un tunnel par défaut inadéquatement provisionné. Lorsque plusieurs tunnels parallèles avec des caractéristiques comportementales différentes sont disponibles, les politiques d'approvisionnement de service sont chargées de déterminer quels flux devraient utiliser quels tunnels. Parmi les possibilités il y a une version grossière du modèle de tunnel uniforme dans laquelle la valeur DSCP interne est utilisée pour choisir un tunnel qui va transmettre le trafic en utilisant un agrégat comportemental qui est compatible avec le PHB du trafic.

5.   Fonctionnalité de sortie

Comme décrit à la Section 3 ci-dessus, cette analyse se fonde sur une approche dans laquelle la fonction diffserv et/ou les chemins de communication hors bande ne sont pas placés en parallèle avec le processus d'encapsulation du tunnel. Cela permet trois localisations possibles des conditionneurs de trafic par rapport au processus de désencapsulation du tunnel, comme le montre le diagramme suivant qui décrit le flux des en-têtes IP à travers la désencapsulation du tunnel :

  >>----[5 - Externe]-----------+

                                 \

                                  \

  >>----[4 - Interne] --------- Désencapsule ---- [6 - Après] -->>

Le conditionnent du trafic en [5 - Externe] et [6 - Après] est séparé logiquement du tunnel, car il n'est pas impacté par la présence de la désencapsulation du tunnel. Les conceptions et spécifications de tunnel devraient permettre le conditionnement du trafic diffserv à ces localisations. Un tel conditionnement peut être vu comme indépendant du tunnel, c'est-à-dire, [5 - Externe] est du conditionnement de trafic qui a lieu avant la sortie du tunnel, et [6 - Après] est du conditionnement de trafic qui prend place après la désencapsulation de sortie. Une importante exception est que la configuration d'un tunnel (par exemple, l'absence de conditionnement du trafic à l'entrée du tunnel) et/ou les domaines diffserv impliqués peuvent requérir que tout le trafic sortant d'un tunnel passe à travers le conditionnement de trafic diffserv pour satisfaire aux responsabilités de conditionnement du trafic de nœud bordure diffserv du nœud de sortie du tunnel. Les concepteurs de tunnel sont vivement invités à inclure la capacité d'exiger que tout le trafic sortant d'un tunnel passe à travers le conditionnement de trafic diffserv afin de s'assurer que le trafic sortant du nœud est compatible avec le domaine diffserv du nœud de sortie.

À l'opposé, la localisation [4 - Interne] est difficile à employer pour le conditionnement du trafic parce qu'elle exige d'atteindre l'intérieur du paquet pour travailler sur l'en-tête IP interne. À la différence du cas [3 - Interne] pour l'encapsulation, il n'est pas nécessaire que la fonction soit effectuée à [4- Interne], car le conditionnement du trafic diffserv peut être ajouté à la désencapsulation du tunnel (c'est-à-dire, effectué à [6 - Après]).

5.1   Choix du DSCP de sortie

L'élimination de la fonction parallèle et des chemins de données de la désencapsulation cause une perte d'informations potentielle. Comme le montre le diagramme ci-dessus, la désencapsulation combine et réduit deux valeurs DSCP en une valeur DSCP, perdant des informations dans la plupart des cas, même si une fonction arbitraire est permise. Au delà de cela, permettre une fonction arbitraire pose un problème structurel, à savoir que la valeur DSCP provenant de l'en-tête IP externe devrait être présentée comme une entrée hors bande au bloc de conditionnement de trafic à [6 - Après], compliquant le modèle de conditionnement du trafic.

Pour éviter une telle complication, l'approche plus simple d'un choix statique de la valeur DSCP interne ou externe à la désencapsulation est recommandée, laissant l'entière généralité de la fonction de conditionnement du trafic être mise en œuvre en [5 - Externe] et/ou [6 - Après]. Les tunnels devraient prendre en charge le choix statique de l'une ou l'autre des valeurs DSCP à la sortie du tunnel. La raison de cette approche est qu'habituellement une seule des deux valeurs DSCP contient des informations utiles. Le modèle conceptuel pour le tunnel donne une forte indication de celle qui contient les informations utiles ; la valeur DSCP externe contient habituellement les informations utiles pour les tunnels sur la base du modèle uniforme, et la valeur DSCP interne contient normalement les informations utiles pour les tunnels sur la base du modèle de tuyau. Les tunnels IPSec sont habituellement fondés sur le modèle du tuyau, et pour des raisons de sécurité ils sont actuellement obligés de choisir la valeur DSCP interne ; ils ne devraient pas être configurés pour choisir la valeur DSCP externe en l'absence d'une analyse de sécurité adéquate des risques et implications résultants.

5.2   Étude de cas du choix du DSCP de sortie

À titre d'examen de santé de l'approche du choix du DSCP de sortie proposée ci-dessus, ce paragraphe considère une situation dans laquelle une approche plus complexe pourrait être requise. Le choix statique d'une seule valeur de DSCP peut ne pas très bien fonctionner lorsque les deux DSCP portent des informations qui se rapportent au conditionnement du trafic.

Par exemple, considérons une situation dans laquelle différents groupes AF [RFC 2597] sont utilisés par les deux domaines aux points d'extrémité de tunnel, et où il y a un domaine intermédiaire le long du tunnel qui utilise la préséances IP de la RFC 791 et dont le transit est assuré en réglant le DSCP à zéro. Cette situation est montrée dans le diagramme de flux d'en-tête IP suivant, où E est le nœud d'entrée du tunnel, S est le nœud de sortie du tunnel et les lignes verticales sont les frontières de domaines. Le nœud à la ligne verticale gauche règle le DSCP à zéro dans l'en-tête externe afin d'obtenir la compatibilité avec le domaine du milieu :

                        |                   |

                  +-----|-------------------|------+

                 /      |                   |       \

   >>-----------E-------|-------------------|--------S---------->>

  Domaine DS d'entrée   |    Domaine de     | Domaine DS de sortie

                            préséance IP

                            de la RFC 791

Dans cette situation, le nœud bordure DS pour le domaine de sortie (c'est-à-dire, le nœud à la ligne verticale droite) peut choisir le groupe AF approprié (par exemple, via un classeur MF), mais ne peut pas reconstruire les informations de préséance d'abandon qui ont été retirées de l'en-tête externe lors du transit dans le domaine de la RFC 791 (bien qu'il puisse construire de nouvelles informations par mesure et marquage). Les informations originales de préséance d'abandon sont préservées dans le DSCP de l'en-tête IP interne, et pourraient être combinées à la sortie du tunnel avec le choix de classe AF communiqué via le DSCP de l'en-tête IP externe. Le bénéfice marginal de la capacité à réutiliser les informations originales de préséance d'abandon par opposition à la construction de nouveaux marquages de préséance d'abandon ne justifie pas la complexité supplémentaire introduite dans les conditionneurs de trafic de sortie du tunnel par la mise à disposition du conditionnement du trafic des deux valeurs de DSCP en [6 - Après].

6.   Diffserv et les traducteurs de protocole

Un problème connexe concerne les traducteurs de protocole, y compris ceux qui emploient l'algorithme de traduction IP/ICMP sans état [RFC 2765]. Ces traducteurs ne sont pas des tunnels parce qu'ils n'ajoutent ni ne retirent un second en-tête IP des/aux paquets (par exemple, à l'opposé de IPv6 sur les tunnels IPv4 [RFC 1933]) et ne soulèvent donc pas de problème de propagation d'informations entre en-têtes IP internes et externes. La principale interaction entre traducteurs et diffserv est que la frontière de traduction sera vraisemblablement aussi une frontière de domaine diffserv (par exemple, les domaines IPv4 et IPv6 peuvent avoir des politiques différentes pour le conditionnement du trafic et l'usage de DSCP) et donc de tels traducteurs devraient permettre l'insertion du traitement de nœud bordure diffserv (y compris le conditionnement du trafic) à la fois avant et après le processus de traduction.

7.   Considérations pour la sécurité

Les considérations pour la sécurité de l'architecture diffserv exposées dans les [RFC 2474, RFC 2475] s'appliquent lorsque les tunnels sont présents. Une des exigences est qu'un nœud de sortie de tunnel dans l'intérieur d'un domaine diffserv soit le nœud d'entrée DS pour le trafic qui sort du tunnel, et qu'il soit chargé d'effectuer le conditionnement approprié du trafic. La principale implication pour la sécurité est que le conditionnement du trafic est responsable du traitement des menaces de vol et de déni de service posées au domaine diffserv par le trafic qui sort du tunnel. L'architecture IPSec [RFC 2401] met une restriction supplémentaire au traitement de sortie du tunnel ; l'en-tête externe doit être éliminé sauf si les propriétés du conditionnement du trafic à appliquer sont connues et ont été analysées de façon adéquate du point de vue de la sécurité. Cela inclut les deux blocs de conditionnement du trafic en [5 - Externe] et [6 - Après] sur le nœud de sortie du tunnel, s'ils sont présents, et peut impliquer le conditionnement du trafic effectué par un nœud de bordure DS amont qui est le nœud d'entrée du domaine DS pour le trafic tunnelé encapsulé.

8.   Références

(Les liens sur les numéros pointent sur la version anglaise, ceux dans le titre sur la traduction française)

[RFC0791]   J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981.

[RFC1661]   W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC 2153)

[RFC1933]   R. Gilligan, E. Nordmark, "Mécanismes de transition pour hôtes et routeurs IPv6", avril 1996. (Obsolète, voirRFC2893) (P.S.)

[RFC2003]   C. Perkins, "Encapsulation de IP dans IP", RFC 2003, octobre 1996.

[RFC2401]   S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", novembre 1998. (Obsolète, voirRFC4301)

[RFC2474]   K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ parRFC3168, RFC3260) (P.S.)

[RFC2475]   S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang et W. Weiss, "Architecture pour services différenciés", décembre 1998. (MàJ par RFC3260)

[RFC2597]   J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Groupe PHB Transmission assurée", juin 1999. (MàJ parRFC3260) (P.S.)

[RFC2598]   V. Jacobson, K. Nichols, K. Poduri, "PHB Transmission expédiée", juin 1999. (Obsolète, voirRFC3246) (P.S.)

[RFC2661]   W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn et B. Palter, "Protocole de tunnelage de couche 2 "L2TP"", (P.S.)

[RFC2765]   E. Nordmark, "Algorithme de traduction IP/ICMP sans état (SIIT)", février 2000. (P.S.)

9.   Remerciements

Certains des éléments du présent mémoire se fondent sur des discussions avec Brian Carpenter, et en particulier sa présentation du sujet au groupe de travail diffserv durant la réunion de l'été 1999 de l'IETF à Oslo. On doit aussi rendre hommage à un certain nombre de personne qui travaillent sur les spécifications de tunnel et qui ont découvert les limites de l'architecture diffserv [RFC 2475] dans le domaine des tunnels. Leur patience à l'égard du temps qu'il a fallu pour régler cet ensemble de problème est apprécié à sa juste valeur. Enfin, ces éléments ont bénéficié des discussions au sein du groupe de travail diffserv, à la fois dans les réunions et sur la liste de diffusion – les participants sont chaleureusement remerciés de leurs contributions à ces discussions.

10.   Adresse de l'auteur

David L. Black

EMC Corporation

42 South St.

Hopkinton, MA 01748

téléphone : +1 (508) 435-1000 x75140

mél : black_david@emc.com

11   Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.