Format de l'objet RSVP DCLASS

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. 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é

La signalisation du protocole de réservation de ressource (RSVP, Resource Reservation Protocol) peut être utilisée pour demander des services de qualité de service (QS) et améliorer la gérabilité de la QS de trafic d'application dans un réseau à services différenciés (diff-serv ou DS). Lors de l'utilisation de RSVP dans des réseaux DS, il est utile d'être capable de porter les codets de services différenciés (DSCP, Differentiated Services Code Point) dans les objets de message RSVP. Un exemple en est l'utilisation de RSVP pour effectuer le marquage des paquets avec un DSCP particulier en amont à partir du point d'entrée du réseau DS, au routeur de sortie de l'envoyeur ou du précédent réseau.

L'objet DCLASS est utilisé pour représenter et porter les DSCP au sein des messages RSVP. Le présent document spécifie le format de l'objet DCLASS et expose brièvement son utilisation.

1.   Introduction

La présente section décrit les mécanismes d'utilisation de la signalisation de RSVP [RFC2205] et de l'objet DCLASS pour effectuer le contrôle d'admission et appliquer la politique de QS (qualité de service) au sein d'un réseau à services différenciés [RFC2475]. On suppose des envoyeurs et receveurs RSVP standard, et un réseau diff-serv quelque part sur le chemin entre envoyeur et receveur. Au moins un élément de réseau à capacité RSVP réside dans le réseau diff-serv. Cet élément de réseau peut être un point de mise en application de politique (PEP, policy enforcement point) [RFC2753] ou peut simplement agir comme un agent de contrôle d'admission pour le réseau, admettant ou refusant les demandes de ressource sur la base de la disponibilité des ressources. Dans l'un ou l'autre cas, cet élément de réseau interagit avec les messages RSVP qui arrivent de l'extérieur du réseau DS, acceptant les demandes de ressource provenant des envoyeurs et receveurs à capacité RSVP, et convoyant les décisions de contrôle d'admission et d'allocation de ressources du réseau DS au niveau RSVP supérieur. L'élément de réseau est normalement un routeur et sera considéré comme tel pour les besoins du présent document. Ce modèle est entièrement décrit dans la [RFC2998].

1.1   Utilisation de l'objet DCLASS pour porter vers l'amont les informations de marquage de paquet

La principale utilisation de l'objet DCLASS est de porter les informations de DSCP entre un réseau DS et les nœuds en amont qui peuvent souhaiter marquer les paquets avec des valeurs de DSCP. En bref, l'envoyeur compose un message standard PATH RSVP et l'envoie vers le receveur. À un certain point, le message PATH atteint le réseau DS. Le message PATH traverse un ou plusieurs éléments de réseau qui sont des PEP et/ou des agents de contrôle d'admission pour le réseau diff-serv. Ces éléments installent l'état approprié et transmettent le message PATH vers le receveur. Si le contrôle d'admission est réussi en aval du réseau diff-serv, un message RESV va alors arriver de la direction du receveur. Comme ce message arrive aux PEP et/ou aux agents de contrôle d'admission qui sont à capacité RSVP, chacun de ces éléments de réseau doit prendre une décision en ce qui concerne l'admissibilité du flux signalé au réseau diff-serv.

Si l'élément de réseau détermine que la demande représentée par les messages PATH et RESV est admissible pour le réseau diff-serv, le niveau approprié de service diff-serv (ou un agrégat de comportements) pour le trafic représenté dans la demande RSVP est déterminé. Ensuite est prise une décision de marquer localement les paquets de données arrivant pour ce trafic en utilisant la classification MF, ou de demander un marquage des paquets en amont avec le ou les DSCP appropriés. Ce marquage en amont pourrait survenir n'importe où avant le point d'entrée du réseau DS. Deux candidats vraisemblables sont l'envoyeur d'origine et le routeur frontière de sortie d'un réseau amont (DS ou non DS). La décision sur l'endroit où les paquets de demande RSVP devraient être marqués peut être prise par accord mutuel ou à travers un protocole de négociation ; les détails de ce processus sortent du domaine d'application du présent document.

Si les paquets pour cette demande RSVP sont à marquer en amont, les informations sur le ou les DSCP à utiliser doivent être convoyées de l'élément de réseau à capacité RSVP au point de marquage amont. Ces informations sont convoyées avec l'objet DCLASS. Pour le faire, l'élément de réseau ajoute au message RESV un objet DCLASS contenant un ou plusieurs DSCP correspondants à l'agrégat de comportements. Ce message RESV est alors envoyé en amont vers l'envoyeur RSVP.

Si l'élément de réseau détermine que la demande RSVP n'est pas admissible pour le réseau diff-serv, il envoie un message d'erreur RESV vers le receveur. Aucun objet DCLASS n'est alors nécessaire.

1.1   Utilisations supplémentaires de l'objet DCLASS

L'objet DCLASS est destiné à être un outil général pour le transport des informations de DSCP dans les messages RSVP. Cela peut être utile dans un certain nombre de situations. On en donne ici un exemple à titre de motivation.

Dans cet exemple, on suppose que la décision sur l'agrégat de comportements approprié pour un flus de trafic à support RSVP est prise au routeur de sortie du réseau DS (ou au point de décision de politique qui s'y rapporte) en observant les messages RSVP PATH et RESV et les autres informations nécessaires. Cependant, le marquage de paquet réel doit être effectué à l'entrée du réseau. L'objet DCLASS peut être utilisé pour porter les informations de marquage nécessaires entre les routeurs d'entrée et de sortie.

2.   Format de l'objet DCLASS

L'objet DCLASS a le format suivant :

        0       |       1       |       2       |       3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|       Longueur (≥ 8)          |   C-Num (225) |       1       |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|               Non utilisé                     | 1er DSCP  |   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|               Non utilisé                     | 2nd DSCP  |   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|               Non utilisé                     | . . . .   |   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le premier mot contient l'en-tête standard d'objet RSVP (le numéro de classe pour l'objet DCLASS est 225). Le champ Longueur indique en octets la longueur totale de l'objet. L'en-tête de l'objet est suivi par un ou plusieurs mots de 32 bits, contenant chacun un DSCP dans les six bits de poids fort de l'octet de moindre poids. Le champ Longueur dans l'en-tête de l'objet indique le nombre de DSCP inclus dans l'objet. Précisément, le nombre d'objets DCLASS présents est égal à (Longueur - 4) / 4.

Le réseau peut retourner plusieurs DSCP dans l'objet DCLASS afin de permettre à l'hôte de distinguer des sous-flux au sein d'un agrégat de comportements. Par exemple, dans le cas du groupe PHB AF [RFC2597], le réseau peut retourner les DSCP 001010, 001100, et 001110, correspondants à des niveaux croissants de préséance d'abandon au sein de la classe 1 du groupe PHB AF. Noter que le présent document ne prend aucune position sur la signification de l'ordre des DSCP retournés. Une interprétation plus élaborée des DSCP établis dépend du service demandé par l'hôte et sort du domaine d'application du présent document.

Noter que le numéro de classe (Class-Num) pour l'objet DCLASS est choisi dans l'espace des objets de classe inconnue qui devraient être ignorés et transmis par les nœuds qui ne les reconnaissent pas. Cela devrai assurer la rétro compatibilité maximale.

3.   Fonction de contrôle d'admission

Du point de vue d'une boîte noire, les fonctions de contrôle d'admission et de régulation reviennent à la décision d'accepter ou rejeter une demande et à la détermination des DSCP qui devraient être utilisés pour le trafic correspondant. Les détails spécifiques du contrôle d'admission sortent du domaine d'application du présent document. La décision de contrôle d'admission est en général fondée à la fois sur la disponibilité des ressources et sur les politiques concernant l'utilisation des ressources dans le réseau diff-serv. La décision de contrôle d'admission prise par les éléments de réseau à capacité RSVP représente les deux considérations.

Pour décider si la demande RSVP est admissible en termes de disponibilité de ressource, un ou plusieurs éléments de réseau au sein ou à la frontière du réseau diff-serv doivent comprendre l'impact que l'admission aurait sur les ressources diff-serv spécifiques, ainsi que sur la disponibilité de ces ressources le long du chemin de données pertinent dans le réseau diff-serv.

Pour décider si la demande RSVP est admissible en termes de politique, l'élément de réseau peut utiliser des objets d'identité qui décrivent les utilisateurs et/ou les applications qui peuvent être inclus dans la demande. Le routeur peut agir comme un PEP/PDP et utiliser des données provenant d'une base de données ou d'un répertoire de politiques pour aider cette décision.

Voir à l'Appendice A un mécanisme simple de contrôle d'admission fondé sur la configuration de ressource.

4.   Considérations pour la sécurité

L'objet DCLASS porte des informations qui peuvent être utilisées pour demander une qualité de service améliorée à un réseau DS, de sorte qu'une modification inappropriée de l'objet pourrait permettre à des flux de trafic d'obtenir un niveau de QS supérieur ou inférieur à celui qui est approprié. En particulier, la modification d'un objet DCLASS par un tiers inséré entre le nœud d'entrée du réseau DS et le marqueur amont constitue une attaque possible de déni de service. Cette attaque est subtile parce qu'il est possible de réduire la QS reçue à un niveau inacceptablement bas sans couper complètement le flux de données, ce qui rend l'attaque plus difficile à déceler.

La possibilité d'augmenter le niveau de QS reçue par une modification inappropriée de l'objet DCLASS est moins significative parce qu'elle est une sous-classe d'une classe d'attaques plus large qui doit déjà être détectée par le système. La protection doit déjà être en place pour empêcher qu'un hôte augmente son niveau de QS reçue en devinant simplement les "bons" DSCP et en marquant les paquets en conséquence. Si cette protection est à la frontière du réseau DS, elle va détecter les marquages inappropriés de paquets arrivants causés aussi bien par des objets DCLASS modifiés. Si, cependant, la fonction de protection et la fonction de marquage ont été repoussées vers l'amont (éventuellemùent à un tiers de confiance ou à un nœud intermédiaire) la transmission correcte de l'objet DCLASS doit être assurée pour empêcher une attaque possible de vol de service.

La simple observation de l'objet DCLASS dans un message RSVP soulève plusieurs problèmes qui peuvent être vus comme des problèmes de sécurité. La corrélation des valeurs d'objets DCLASS observés avec des paramètres de demandes RSVP ou de classification MF permet à l'observateur de déterminer que différents flux reçoivent des niveaux de QS différents, ce qui peut être une information qui devrait être protégée dans certains environnements. De même, l'observation des objets DCLASS peut permettre à l'observateur de déterminer que la QS d'un seul flux a été augmentée ou diminuée, ce qui peut signaler des événements significatifs dans la vie de l'application ou de l'utilisateur de ce flux. Finalement, l'observation de l'objet DCLASS peut révéler des informations sur le fonctionnement interne d'un réseau DS qui pourraient être utiles à des observateurs intéressés à des attaques de vol de service.

5.   Références

[RFC2998]   Y. Bernet et autres, "Cadre de fonctionnement de services intégrés sur réseaux Diffserv", novembre 2000. (Information)

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

[RFC2205]   R. Braden, éd., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocole de réservation de ressource (RSVP) -- version 1, spécification fonctionnelle", septembre 1997. (MàJ parRFC2750, RFC3936, RFC4495) (P.S.)

[RFC2753]   R. Yavatkar, D. Pendarakis, R. Guerin, "Cadre pour le contrôle d'admission fondé sur la politique", janvier 2000. (Information)

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

6.   Remerciements

Merci à Fred Baker et à Carol Iturralde pour la relecture de ce document. Merci de leurs apports à Ramesh Pabbati, Tim Moore, Bruce Davie et Kam Lee.

7.   Adresse de l'auteur

Yoram Bernet

Microsoft

One Microsoft Way,

Redmond, WA 98052

téléphone : (425) 936-9568

mél : yoramb@microsoft.com

Appendice A – Contrôle d'admission fondé sur de simples ressources configurables

Les routeurs peuvent utiliser des mécanismes assez sophistiqués pour prendre la décision de contrôle d'admission, y compris des considérations de politique, divers protocoles de signalisation intra-domaine, des résultats de surveillance du trafic, et ainsi de suite. Il est recommandé que les fonctionnalités de base suivantes soient fournies pour permettre un simple contrôle d'admission fondé sur la ressource en l'absence de mécanismes plus sophistiqués. Cette fonctionnalité peut être utilisée avec des routeurs configurables autonomes. Elle s'applique aux demandes RSVP/Intserv standard. Cette fonctionnalité minimale suppose seulement qu'un seul DSCP soit inclus dans l'objet DCLASS, mais peut directement être étendue pour la prise en charge de plusieurs DSCP.

Il doit être possible de configurer deux tableaux dans le routeur, qui sont décrits ci-dessous.

A.1   Transposition du type de service en DSCP

Un tableau donne la transposition du type de service intserv spécifié dans la demande RSVP en un DSCP qui peut être utilisé pour obtenir un service correspondant dans le réseau diff-serv. Ce tableau contient une rangée pour chaque type de service intserv pour lequel une transposition est disponible. Chaque rangée a le format suivant :

Type de service Intserv : DSCP

Le tableau va normalement contenir au moins trois rangées, une pour le service garanti, une pour le service à charge contrôlée et une pour le service au mieux. (Le service au mieux va normalement être transposé au DSCP 000000, mais peut être outrepassé). Il devrait être possible d'ajouter des rangées pour des types de service encore non définis.

Ce tableau permet à l'administrateur du réseau de configurer de façon statique un DSCP que le routeur va retourner dans l'objet DCLASS pour une demande RSVP admisee. En général, des mécanismes plus sophistiqués et vraisemblablement plus dynamiques peuvent être utilisés pour déterminer le DSCP à retourner dans l'objet DCLASS. Aussi, il est vraisemblable qu'une transposition réelle pour certains services va utiliser plus d'un DSCP, celui-ci dépendant des paramètres d'invocation d'une demande de service spécifique. Dans ce cas, ces mécanismés peuvent outrepasser ou remplacer la transposition fondée sur le tableau statique décrite ici.

A.2   Disponibilité quantitative de ressource

Les demandes intserv standard sont quantitatives par nature. Elles comportent des paramètres de baquet de jetons qui décrivent les ressources demandées par le trafic dont l'admission est requise. Le second tableau permet à l'administrateur de réseau de configurer statiquement les paramètres quantitatifs qu'utilise le routeur pour prendre une décision de contrôle d'admission sur des demandes de service quantitatives. Chaque rangée de ce tableau a la forme suivante :

DSCP : profil de baquet de jetons

La première colonne spécifie les DSCP pour lesquels le contrôle d'admission quantitatif est appliqué. La seconde colonne spécifie les paramètres de baquet de jetons qui représentent les ressources totales disponibles dans le réseau diff-serv pour traiter le trafic dans la classe de service spécifiée par le DSCP.

Déclaration complète de droits de reproduction

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

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement assuré par la Internet Society.