Groupe de travail Réseau |
G. Dommety, Cisco Systems |
Request for Comments : 2890 |
septembre 2000 |
Catégorie : En cours de normalisation |
Traduction Claude Brière de L'Isle |
Extensions Clé et Numéro de séquence à GRE
Statut du présent Mémo La présente RFC spécifie un protocole de normalisation pour la communauté Internet et appelle à des discussions et suggestions pour son amélioration. Prière de se reporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restriction.
Déclaration de Copyright
Copyright (C) The Internet Society (2000). Tous droits réservés.
Résumé
GRE (Encapsulation d'acheminement générique) spécifie un protocole d'encapsulation d'un protocole arbitraire sur un autre protocole arbitraire de couche réseau. Le présent document décrit les extensions par lesquelles deux champs, Clé et Numéro de séquence, peuvent facultativement être portés dans l'en-tête GRE [1].
Table des Matières
2.2. Numéro de séquence (4 octets)
3. Considérations pour la sécurité
4. Considerations relatives à l'IANA
La spécification actuelle de l'encapsulation d'acheminement générique (GRE, Generic Routing Encapsulation) [1] spécifie un protocole pour l'encapsulation d'un protocole arbitraire sur un autre protocole arbitraire de couche réseau. Le présent document décrit les améliorations par lesquelles deux champs, Clé et Numéro de séquence, peuvent être facultativement portés dans l'en-tête GRE [1]. Le champ Clé est destiné à être utilisés pour identifier un flux de trafic individuel au sein d'un tunnel. Le champ Numéro de séquence est utilisé pour conserver la séquence des paquets au sein du tunnel GRE.
Dans le présent document, les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRAIT" NE DEVRAIT PAS", "RECOMMANDE", "NON RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans la RFC 2119 [3].
De plus, les mots suivants sont utilisés pour exprimer les exigences de la présente spécification.
Éliminer en silence
La mise en œuvre élimine le datagramme sans autre traitement, et sans indiquer d'erreur à l'envoyeur. La mise en œuvre DEVRAIT fournir la capacité d'enregistrer l'erreur, y compris le contenu du datagramme supprimé, et DEVRAIT enregistrer l'événement dans un compteur statistique.
L'en-tête de paquet GRE [1] a le format suivant :
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
|||||
C |
Reserved0 |
Ver |
Type de protocole |
|||||||||||||||||||||||||||||||||
Somme de contrôle (facultatif) |
Reserved1 (facultatif) |
|||||||||||||||||||||||||||||||||||
L'en-tête GRE proposé aura le format suivant :
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
|||||||
C |
K |
S |
Reserved0 |
Ver |
Type de protocole |
|||||||||||||||||||||||||||||||||
Somme de contrôle (facultatif) |
Reserved1 (facultatif) |
|||||||||||||||||||||||||||||||||||||
Clé (facultatif) |
||||||||||||||||||||||||||||||||||||||
Numéro de séquence (facultatif) |
||||||||||||||||||||||||||||||||||||||
Clé présente (bit 2)
Si le bit Clé présente est mis à 1, il indique alors que le champ Clé est présent dans l'en-tête GRE. Autrement, le champ Clé n'est pas présent dans l'en-tête GRE.
Numéro de séquence présent (bit 3)
Si le bit Numéro de séquence présent est mis à 1, il indique alors que le champ d'en-tête Numéro de séquence est présent. Autrement, le champ Numéro de séquence n'est pas présent dans l'en-tête GRE.
Les bits Clé et Numéro de séquence sont choisis pour être compatibles avec la RFC 1701 [2].
Le champ Clé contient un nombre de quatre octets qui a été inséré par l'encapsuleur. La méthode réelle d'obtention de cette clé sort du domaine d'application du présent document. Le champ Clé est destiné à être utilisé pour identifier un flux de trafic individuel au sein d'un tunnel. Par exemple, les paquets peuvent avoir besoin d'être acheminés sur la base d'informations de contexte qui ne sont pas présentes dans les données encapsulées. Le champ Clé fournit ce contexte et définit un flux de trafic logique entre l'encapsuleur et le décapsuleur. Les paquets qui appartiennent à un flux de trafic sont encapsulés en utilisant la même valeur de Clé, et le point d'extrémité du tunnel qui désencapsule identifie les paquets qui appartiennent à un flux de trafic sur la base de la valeur du champ Clé.
2.2 Numéro de séquence (4 octets)
Le champ Numéro de séquence est un champ de quatre octets et il est inséré par l'encapsuleur lorsque le bit Numéro de séquence présent est mis. Le numéro de séquence DOIT être utilisé par le receveur pour établir l'ordre dans lequel les paquets ont été transmis de l'encapsuleur au receveur. L'utilisation prévue du champ Numéro de séquence est de fournir une livraison non fiable mais ordonnée. Si le bit Clé présente (bit 2) est mis, le numéro de séquence est spécifique du flux de trafic identifié par le champ Clé. Noter que les paquets où le bit de séquence n'est pas mis peuvent être interpolés avec des paquets avec le bit de séquence mis.
Les valeurs de numéro de séquence sont dans la gamme de 0 à (2**32)-1. Le premier datagramme est envoyé avec un numéro de séquence de 0. Le numéro de séquence est donc un compteur de fonctionnement libre représenté modulo 2**32. Le receveur conserve la valeur du numéro de séquence du dernier paquet bien désencapsulé. À l'établissement du tunnel GRE, cette valeur devrait être réglée à (2**32)-1.
Lorsque le désencapsuleur reçoit un paquet hors séquence, il DEVRAIT l'éliminer en silence. Un paquet est considéré hors séquence si le numéro de séquence du paquet reçu est inférieur ou égal au numéro de séquence du dernier paquet bien désencapsulé. Le numéro de séquence d'un message reçu est considéré comme inférieur ou égal au dernier numéro de séquence bien reçu si sa valeur est dans la gamme du dernier numéro de séquence reçu et des 2**31-1 valeurs reçues, incluses.
Si le paquet reçu est un paquet en séquence, il est désencapsulé avec succès. Un paquet en séquence est celui dont le numéro de séquence est supérieur d'exactement 1 (modulo 2**32) au dernier paquet bien désencapsulé, ou un dans lequel le champ Numéro de séquence n'est pas présent (bit S non mis).
Si le paquet reçu n'est ni un paquet en séquence ni un paquet hors séquence cela indique un trou dans les numéros de séquence. Le receveur peut effectuer une petite quantité de mise en mémoire tampon pour essayer de retrouver la séquence originale des paquets transmis. Dans ce cas, le paquet peut être placé dans une mémoire tampon triée par numéro de séquence. Si un paquet en séquence est reçu et désencapsulé avec succès, le receveur devra consulter la tête de la mémoire tampon pour voir si le prochain paquet en séquence a déjà été reçu. Si c'est le cas, le receveur devrait aussi le désencapsuler comme les prochains paquets en séquence qui pourraient être présents dans la mémoire tampon. Le "dernier numéro de séquence désencapsulé avec succès" devrait alors être mis comme dernier paquet désencapsulé de la mémoire tampon.
Un paquet ne devrait en aucun cas attendre plus que OUTOFORDER_TIMER millisecondes dans la mémoire tampon. Si un paquet attend depuis ce temps, le receveur DOIT immédiatement traverser la mémoire tampon dans l'ordre du tri, désencapsuler les paquets (en ignorant tous les trous des numéros de séquence) jusqu'à ce qu'il n'y ait plus de paquet dans la mémoire tampon qui attendent plus de OUTOFORDER_TIMER millisecondes. Le "dernier numéro de séquence désencapsulé avec succès" devrait alors être le dernier paquet ainsi désencapsulé.
Le receveur peut mettre une limite au nombre de paquets à toute mémoire tampon par flux (les paquets qui ont la même valeur du champ Clé appartiennent à un même flux). Si un paquet arrive qui causerait un dépassement de MAX_PERFLOW_BUFFER dans une mémoire tampon donnée chez le receveur, le paquet en tête de la mémoire tampon sera immédiatement désencapsulé, sans considération de son numéro de séquence, et le "dernier numéro de séquence désencapsulé avec succès" sera mis à ce numéro de séquence. Le paquet nouvellement arrivé sera alors placé dans la mémoire tampon.
Noter que le numéro de séquence est utilisé pour détecter les paquets perdus et/ou restaurer la séquence originale des paquets (avec la mémoire tampon) qui pourrait avoir changé d'ordre durant le transport. L'utilisation de l'option Numéro de séquence devrait être utilisées de façon appropriée ; en particulier, c'est une bonne idée d'éviter de l'utiliser avec des protocoles de tunnelage qui ont des mécanismes de livraison dans l'ordre de couche supérieure, ou qui sont tolérants à la livraison en désordre. Si le protocole porté dans le tunnel GRE n'exige la livraison en ordre que sur certaines instances, seuls les paquets correspondants encapsulés dans un en-tête GRE peuvent être envoyés avec le bit Numéro de séquence mis.
La remise en ordre des paquets hors séquence PEUT être effectuée par le désencapsuleur pour des performances et une tolérance améliorées de réorganisation dans le réseau. Une petite quantité de mémoire tampon de réorganisation (MAX_PERFLOW_BUFFER) peut aider à améliorer les performances lorsque la couche supérieure emploie la compression ou le chiffrement à état plein. Comme l'état de la compression ou chiffrement à à état plein est rétabli par la perte de paquet, cela peut aider les performances de tolérer une petite quantité de remise en ordre de paquet dans le réseau par la mise en mémoire tampon.
3. Considérations pour la sécurité
Le présent document décrit les extensions par lesquelles deux champs, Clé et Numéro de séquence, peuvent être facultativement portés dans l'en-tête GRE (Encapsulation d'acheminement générique) [1]. Lorsqu'on utilise le champ Numéro de séquence, il est possible d'injecter des paquets avec un numéro de séquence arbitraire et de lancer une attaque de déni de service. Afin de se protéger contre de telles attaques, les protocoles de sécurité IP [4] DOIVENT être utilisés pour protéger l'en-tête GRE et la charge utile mise dans le tunnel. ESP (Encapsulation de charge utile de sécurité IP) [5] ou AH (En-tête d'authentification IP)[6] DOIVENT être utilisés pour protéger l'en-tête GRE. Si ESP est utilisé, il protège la charge utile IP qui inclut l'en-tête GRE. Si AH est utilisé, le paquet entier sauf les champs modifiables, est authentifié.
Noter que le champ Clé n'est impliqué dans aucune sorte de sécurité (en dépit de son nom).
4. Considérations relatives à l'IANA
Le présent document n'exige aucune allocation de la part de l'IANA et n'a donc aucune nouvelles considérations relatives à l'IANA.
Le présent document découle des idées originales des auteurs de la RFC 1701. Kent Leung, Pete McCann, Mark Townsley, David Meyer, Yingchun Xu, Ajoy Singh et de nombreux autres ont fourni une discussion utile. L'auteur tient à remercier toutes les personnes ci-dessus.
[1] D. Farinacci, T. Li, S. Hanks, D. Meyer et P. Traina, "Encapsulation d'acheminement générique (GRE)", RFC 2784, mars 2000.
[2] S. Hanks, T. Li, D. Farinacci et P. Traina, "Encapsulation générique d'acheminement", RFC 1701, octobre 1994.
[3] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.
[4] S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", RFC 2401, novembre 1998.
[5] S. Kent et R. Atkinson, "Encapsulation de charge utile de sécurité IP (ESP)", RFC 2406, novembre 1998.
[6] S. Kent et R. Atkinson, "En-tête d'authentification IP", RFC 2402, novembre 1998.
Adresse de l'auteur
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
mél : gdommety@cisco.com
Copyright (C) The Internet Society (2000). Tous droits réservés.
Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent et paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais. Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.
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.