Extensions à l’architecture de l’Internet pour les supports partagés

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.

Résumé

L’architecture originale de l’Internet supposait que chaque réseau soit étiqueté avec un seul numéro de réseau IP. Cette hypothèse peut être violée pour les supports partagés, y compris de "grands réseaux publics de données" (les LPDN). L’architecture fonctionne toujours si cette hypothèse est violée, mais il n’y a pas de moyen d’empêcher les bonds multiples hôte-routeur et routeur-routeur à travers le support partagé. Le présent mémoire expose des approches de remplacement à l’extension de l’architecture de l’Internet pour éliminer certains ou tous les bonds inutiles.

Table des Matières

1.   Introduction

2.   Architecture de l’Internet original

3.   Problèmes introduits par les supports partagés

4.   Quelques solutions aux problèmes du partage de support

4.1   Redirection bond par bond

4.2   Acheminement élargi

4.3   Mandataire ARP étendu

4.4   Messages d’interrogation d’acheminement

4.5   Informations d’acheminement périmées

4.6   Implications du filtrage (pare-feu)

5.   Considérations pour la sécurité

6.   Conclusions

7.   Remerciements

8.   Références

1.   Introduction

Le présent mémoire concerne les implications des réseaux à support partagé sur l’architecture de la suite des protocoles TCP/IP. Sa compréhension suppose une certaine familiarité avec l’architecture de TCP/IP et le protocole IP.

L’architecture de l’Internet se fonde sur ce qui était à l’origine appelé le "modèle Catenet" [PSC81]. Selon ce modèle, l’Internet (baptisé à l’origine "le Catenet") est formé en utilisant des routeurs (appelés à l’origine des "passerelles") pour interconnecter des réseaux distincts et peut-être divers. Une adresse d’hôte IP (plus correctement caractérisée comme adresse d’interface réseau) est formée d’une paire (réseau#,hôte#). Ici, "réseau#" est un numéro IP unique alloué au réseau (ou sous-réseau) auquel l’hôte est rattaché, et "hôte#" identifie l’hôte sur ce réseau (ou sous-réseau).

Le modèle d’origine de l’Internet faisait les hypothèses implicites que chaque réseau avait un seul numéro de réseau IP et que les réseaux avec des numéros différents ne pouvaient échanger de paquets que par l’intermédiaire des routeurs. Ces hypothèses peuvent être violées pour des réseaux qui sont mis en œuvre en utilisant un "support partagé" (SM, shared medium) commun à la couche liaison (LL, link layer). Par exemple, les gestionnaires de réseau configurent parfois plusieurs numéros de réseau IP (en général des numéros de sous-réseau) sur un seul LAN de type diffusion comme un Ethernet. Les grands réseaux (commutés) publics de données (les LPDN), tels que SMDS et le RNIS-LB, forment un exemple potentiellement plus important de réseaux à support partagé. Toute paire de systèmes connectés au même réseau à support partagé est capable de communiquer directement à la couche liaison, sans commutation à la couche IP par les routeurs. Cela présente une opportunité d’optimiser les performances et peut-être de diminuer les coûts en éliminant de nombreux bonds inutiles à la couche Liaison à travers le support.

Le présent mémoire expose comment les bonds inutiles peuvent être éliminés dans un support partagé, tout en conservant la cohérence de l’architecture Internet existante. Cette question s’est posée dans un certain nombre de groupes de travail de l’IETF concernés par les LPDN, y compris IPLPDN, IP sur ATM, IDRP pour IP, et BGP. Il est temps de porter un œil critique sur les questions d’architecture à résoudre. Le présent mémoire commence par résumer les aspects pertinents de l’architecture d’origine de l’Internet (Section 2), puis explique le problème des bonds supplémentaires dans les réseaux à support partagé (Section 3). Enfin, il expose certaines solutions possibles (Section 4).

2.   Architecture de l’Internet original

On fait un bref tour d’horizon de l’architecture originale, pour introduire la terminologie et les concepts. La Figure 1 illustre un ensemble typique de quatre réseaux de A, à D, représentés traditionnellement comme des nuages, interconnectés par les routeurs R2, R3, et R4. Les routeurs R1 et R5 connectent avec les autres parties de l’Internet. Ha, à Hd représentent les hôtes connectés à ces réseaux.

Il n’est pas nécessaire de distinguer entre réseau et sous-réseau dans ce mémoire. On peut supposer qu’il y a un gabarit d’adresse associé à chaque "réseau" dans la Figure 1, ce qui permet à un hôte ou routeur de diviser les 32 bits d’une adresse IP en une adresse pour le nuage et un numéro d’hôte qui est défini de façon univoque au sein de ce nuage.

         Ha           Hb           Hc          Hd

         |            |            |            |

         |            |            |            |

        _|_          _|_          _|_          _|_

       (   )        (   )        (   )        (   )

       (Net)        (Net)        (Net)        (Net)

       ( A )        ( B )        ( C )        ( D )

- R1 --(   )-- R2 --(   )-- R3 --(   )-- R4 --(   )-- R5 --

       (   )        (   )        (   )        (   )

       (___)        (___)        (___)        (___)

Figure 1 : Exemple de fragment de l’Internet

Un routeur Internet est connecté au ou aux réseaux locaux comme un hôte d’une espèce particulière. Bien sûr, pour les besoins de la gestion du réseau, un routeur joue le rôle d’un hôte en générant et en recevant les datagrammes. Cependant, il y a une importante différence entre un hôte et un routeur : la fonction d’acheminement est essentiellement centralisée dans les routeurs, ce qui permet aux hôtes d’être "muets" sur l’acheminement. Les hôtes Internet sont obligés par la [RFC1122] de ne prendre qu’une seule décision d’acheminement : l’adresse de destination est-elle locale sur le réseau où on va se connecter ? Si l’adresse n’est pas locale, on dit qu’elle est "étrangère" (par rapport au réseau connecté ou à l’hôte).

Un hôte envoie un datagramme directement à une adresse de destination locale ou (pour une destination étrangère) à un routeur de premier bond. L’hôte utilise initialement un routeur "par défaut" pour toute nouvelle adresse de destination. Si ce routeur par défaut n’est pas le bon choix, ce routeur retourne un message Redirection et transmet le datagramme. Le message Redirection spécifie le routeur de premier bond préféré pour l’adresse de destination donnée. L’hôte utilise cette information, qu’il va conserver dans une "antémémoire d’acheminement" [RFC1122], pour déterminer l’adresse de premier bond pour les datagrammes suivants pour la même destination.

Pour réellement transmettre un datagramme IP à travers un bond de réseau, l’envoyeur doit avoir l’adresse de couche liaison (LL, link layer) de la cible. Donc, chaque hôte et routeur doit avoir une procédure de "résolution d’adresse" pour transposer une adresse IP en adresse LL. ARP (protocole de résolution d’adresse), utilisé pour les réseaux à capacité de diffusion, est le plus courant procédé de résolution d’adresse [Plummer82]. Si il n’y a pas de capacité de diffusion LL (ou si elle est trop coûteuse) il y a alors deux autres approches de la résolution d’adresse : le tableau local de configuration et le "serveur de résolution d’adresse" (serveurs AR).

Si les serveurs AR sont utilisés pour la résolution d’adresse, les hôtes doivent être configurés avec la ou les adresses LL d’un ou plusieurs serveurs du voisinage. Les informations de transposition fournies par les serveurs AR peuvent elles-mêmes être collectées en utilisant un protocole qui permette aux systèmes d’enregistrer leurs adresses LL, ou à partir de tableaux de configuration statiques. Le format de paquet ARP et la structure globale du protocole ARP (demande ARP/réponse ARP) peuvent convenir pour les communications entre un hôte et un serveur AR, même en l’absence de capacités de diffusion LL; ce qui facilitera la conversion des hôtes à l’utilisation des serveurs AR.

Les exemples fournis dans le présent mémoire utilisent ARP pour la résolution d’adresse. Au moins quelques uns des LPDN qui sont prévus vont fournir des capacités de diffusion suffisantes pour prendre en charge ARP. Il est important de noter que ARP fonctionne à la couche liaison, alors que les mécanismes Redirection et d’antémémoire d’acheminement fonctionnent à la couche IP de la pile de protocoles.

3.   Problèmes introduits par les supports partagés

La Figure 2 montre la même configuration que la Figure 1, mais maintenant, les réseaux A, B, C, et D sont tous au sein du même support partagé (SM), indiqué par la boîte en pointillés qui englobe les nuages. Les réseaux A, ... D sont maintenant des réseaux IP logiques (appelés des LIS dans [Laubach93]) plutôt que des réseaux physiques. Chacun de ces réseaux logiques peut (ou peut ne pas) être administrativement distinct. Le SM permet une connexité directe entre deux hôtes ou routeurs quelconques qui lui sont connectés. Par exemple, l’hôte Ha peut échanger des datagrammes directement avec l’hôte Hd ou avec le routeur R4. Un routeur qui a certaines de ses interfaces, mais pas toutes, connectées au support partagé est appelé un "routeur frontière" ; R1 et R5 en sont des exemples.

La Figure 2 illustre le modèle "classique" [Laubach93] à utiliser dans l’architecture Internet au sein d’un support partagé, c’est-à-dire, en appliquant simplement l’architecture originale de l’Internet décrite précédemment. Cela va donner un fonctionnement correct mais non optimal. Par exemple, dans le cas de deux hôtes sur le même réseau logique (non montré à la Figure 2), les règles d’origine vont clairement fonctionner ; l’hôte de source va transmettre un datagramme directement en un seul bond à un hôte sur le même réseau logique. Les règles de l’architecture d’origine vont aussi fonctionner pour les communications entre toute paire d’hôtes montrée à la Figure 2 ; par exemple, l’hôte Ha enverrait un datagramme à l’hôte Hd via le chemin à quatre bonds Ha -> R2 -> R3 -> R4 -> Hd. Cependant, le modèle classique ne tire pas parti de la connexité directe Ha -> Hd permise par le support partagé.

      Ha           Hb           Hc           Hd

      |            |            |            |

 ---- | ---------- | ---------- | ---------- | ----

|   __|__        __|__        __|__        __|__   |

   (     )      (     )      (     )      (     )

|  (     )      (     )      (     )      (     )  |

   ( Net )      ( Net )      ( Net )      ( Net )

|  (  A  )      (  B  )      (  C  )      (  D  )  |

   (     )      (     )      (     )      (     )

|  (     )      (     )      (     )      (     )  |

   (_____)      (_____)      (_____)      ( ____)

|    | |          | |          | |          | |    |

 --- | | -------- | | -------- | | -------- | | ---

     | |          | |          | |          | |

 R1 -   --- R2 ---   --- R3 ---   --- R4 ---   --- R5 ---

Figure 2 : Réseaux IP logiques en support partagé

Le présent mémoire concerne les mécanismes pour réaliser la connexité au minimum de bond quand elle est désirée. On devrait noter qu’il n’est pas toujours désirable de réaliser la connexité au minimum de bonds sur un support partagé. Par exemple, les bonds "supplémentaires" peuvent être nécessaires pour permettre aux routeurs d’agir comme des pare-feu administratifs. Par ailleurs, lorsque une telle protection de pare-feu n’est pas exigée, il devrait être possible de tirer parti du support partagé pour permettre à ce datagramme d’utiliser des chemins plus courts. En général, il devrait être possible de choisir entre la sécurité du pare-feu et une connexité efficace. Ceci est discuté plus en détails au paragraphe 4.6 ci-dessous.

On note aussi que les mécanismes décrits ici peuvent seulement optimiser le chemin au sein du SM local. Lorsque le SM est seulement un segment du chemin entre la source et le receveur, retirer des bonds localement peut limiter la capacité à passer à des chemins globalement meilleurs qui peuvent devenir disponibles par suite de changements d’acheminement. Donc, considérons Ha- >...Hx, où l’hôte Hx est en dehors du SM auquel est rattaché l’hôte Ha. Supposons que le chemin globalement plus court pour Hx soit via un routeur frontière Rb1. L’optimisation locale qui utilise les techniques décrites plus loin va retirer les bonds supplémentaires dans le SM et permettre Ha->Rb1->...Hx. Supposons maintenant qu’un changement de chemin ultérieur en dehors du SM rende le chemin Ha->Rb2- >...Hx globalement meilleur, où Rb2 est un autre routeur frontière. Comme Ha ne participe pas au protocole d’acheminement, il ne sait pas qu’il devrait passer sur Rb2. Il est possible que Rb2 ne le réalise pas non plus ; voilà la situation :

GC(Ha->Rb2->...Hx) < GC(Ha->Rb1->Rb2->...Hx) < GC(Ha->Rb1->...Hx)

où GC() représente une fonction de coût global du chemin spécifié.

Noter que ARP exige la diffusion LL. Même si le SM prend en charge la diffusion, il est vraisemblable que les administrateurs vont ériger des pare-feu pour garder la diffusion locale à leur LIS.

Il y a trois cas à optimiser. Supposons que H et H' sont des hôtes et que Rb et Rb' sont des routeurs frontières connectés au même SM. Les chemins à un seul bond suivants devraient être possibles :

H -> H' : d’hôte à hôte au sein du SM

H -> Rb : de l’hôte au routeur de sortie

Rb -> Rb' : du routeur frontière d’entrée au routeur frontière de sortie, pour le trafic de transit.

On peut être ou non capable de retirer le bond supplémentaire implicite dans Rb -> R -> H, où Rb, R, et H sont au sein du même SM, mais la source ultime est en dehors du SM. Pour retirer ce bond, il faudrait une distribution des chemins d’hôtes, et pas seulement des chemins de réseau, entre les deux routeurs R et Rb ; cela aurait un impact négatif sur l’adaptabilité de l’acheminement.

Un certain nombre d’importantes exigences s’imposent pour toute solution architecturale de ces problèmes.

*   Interopérabilité

Des hôtes et routeurs modifiés doivent interopérer avec des nœuds non modifiés.

*   Praticabilité

Des changements logiciels minimum seraient exigés.

*   Robustesse

Le nouveau schéma doit être au moins aussi robuste contre les erreurs de logiciel, de configuration, ou de transmission que l’architecture existante.

*   Sécurité

Le nouveau schéma doit être au moins aussi sûr contre la subversion que l’architecture existante.

La distinction entre hôte et routeur est très significative du point de vue de l’ingénierie. Il est considéré qu’il est beaucoup plus difficile de faire un changement global dans le logiciel d’hôte que dans le logiciel de routeur, parce que il y a beaucoup plus d’hôtes et de fabricants d’hôtes que de routeurs et de fabricants de routeurs, et parce que les hôtes sont moins centralisés administrativement que les routeurs. Si il est nécessaire de changer la spécification de ce que fait un hôte (ce qui est le cas) on doit alors minimiser l’étendue de ce changement.

4.   Quelques solutions aux problèmes du partage de support

Quatre différentes approches ont été suggérées pour résoudre ces problèmes de SM.

(1)   Redirection bond par bond

Dans cette approche, le mécanisme de redirection d’hôte est étendu pour concentrer des chemins à bonds multiples au sein du même support partagé, bond par bond. Un routeur sera admis à envoyer, et un hôte admis à accepter, un message Redirection qui spécifie une adresse IP étrangère au sein du même SM. On appelle cela une "Redirection étrangère". Le paragraphe 4.1 analyse cette approche plus en détail.

(2)   Acheminement élargi

Les protocoles d’acheminement peuvent être modifiés pour connaître le SM et pour fournir des adresses de LL.

(3)   Mandataire ARP étendu

C’est une forme de l’approche du mandataire ARP, dans laquelle le problème de l’acheminement est résolu implicitement par un mécanisme étendu de résolution d’adresse à la couche liaison. Cette approche a été décrite par Heinanen [Heinanen93] et par Garrett et autres [Garrett93].

(4)   Messages d’interrogation de chemin

Cette approche a été suggérée par Halpern [Halpern93]. Plutôt que d’ajouter des informations supplémentaires à l’acheminement, cette approche ajouterait un nouveau mécanisme de couche liaison utilisant des datagrammes d’interrogation et de réponse de bout en bout.

Toutes les quatre sont discutées dans les quatre paragraphes suivants.

4.1   Redirection bond par bond

Le premier schéma que nous considérons fonctionnerait à la couche IP. Il couperait les bonds supplémentaires un par un, chaque routeur du chemin ne fonctionnant que sur les informations locales. Cette approche exige que l’hôte et le routeur changent tous deux, mais pas de changement du protocole d’acheminement.

L’idée de base est que le routeur du premier bond, en observant que le prochain bond est au sein du même SM, envoie une redirection étrangère à la source, la redirigeant sur le prochain bond. L’application successive de cet algorithme à chaque routeur intermédiaire va finalement résulter en un chemin direct de l’hôte de source à l’hôte de destination, si tous deux sont au sein du même SM.

Supposons que Ha veuille envoyer un datagramme à Hd. On utilise la notation IP.a pour l’adresse IP de l’entité a, et LL.a pour l’adresse LL correspondante. Chaque ligne du schéma suivant montre un datagramme IP et le chemin de ce datagramme suit, séparé par deux points. La notation "Redirect( h, IP.a)" signifie une Redirection qui spécifie IP.a comme meilleur prochain bond pour atteindre l’hôte h.

(1)   Datagramme 1 : Ha -> R2 -> R3 -> R4 -> Hd

(2)   Redirect(Hd, IP.R3): R2 -> Ha

(3)   Datagramme 2 : Ha -> R3 -> R4 -> Hd

(4)   Redirect(Hd, IP.R4): R3 -> Ha

(5)   Datagramme 3 : Ha -> R4 -> Hd

(6)   Redirect(Hd, IP.Hd): R4 -> Ha

(7)   Datagramme 4 : Ha -> Hd

Il y a trois problèmes à résoudre pour faire fonctionner la redirection bond par bond ; on les marque HH1, HH2, et HH3.

HH1 : Chaque routeur doit être capable de résoudre l’adresse LL de la source Ha, pour envoyer une redirection (étrangère).

Supposons que la couche liaison fournisse l’adresse LL de source lorsque un datagramme IP arrive. Si le routeur détermine qu’une Redirection devrait être envoyée, elle va alors être envoyée à l’adresse LL de source du datagramme reçu.

HH2 : Un hôte de source doit être capable d’effectuer la résolution d’adresse pour obtenir l’adresse LL de chaque routeur sur lequel il est redirigé.

Il serait possible à chaque routeur R, lors de l’envoi d’une Redirection à Ha, d’envoyer aussi une réponse ARP non sollicitée en point à point à LL.Ha, qui mette à jour l’entrée d’antémémoire ARP de Ha avec LL.R. Cependant, il n’y a pas de garantie que cette réponse ARP non sollicitée soit livrée. Si elle est perdue, ce sera un trou noir de transmission. L’hôte pourrait se récupérer en redémarrant du routeur par défaut d’origine ; cependant, cette solution peut être trop inefficace.

Une solution plus directe et efficace serait d’introduire un message ICMP Redirection étendu (appelons le XRedirect) qui porte l’adresse LL ainsi que l’adresse IP de la cible. Cela supprimerait le problème de la livraison fiable de l’ARP non sollicité décrit ci-dessus, parce que le sort de l’adresse LL serait partagé par celui de l’adresse IP de cible, qui seraient livrées toutes deux ou pas du tout. (Un XRedirect est essentiellement la même chose qu’une Redirection dans le protocole OSI ES-IS).

En utilisant XRedirect, l’exemple précédent devient :

(1)   Datagramme 1 : Ha -> R2 -> R3 -> R4 -> Hd

(2)   XRedirect(Hd, IP.R3, LL.R3): R2 -> Ha

(3)   Datagramme 2 : Ha -> R3 -> R4 -> Hd

(4)   XRedirect(Hd, IP.R4, LL.R4): R3 -> Ha

(5)   Datagramme 3 : Ha -> R4 -> Hd

(6)   XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha

(7)   Datagramme 4 : Ha -> Hd

HH3 : Chaque routeur devrait être capable de reconnaître quand il est le premier bond sur le chemin, car une Redirection ne devrait être envoyée que par le routeur de premier bond. Malheureusement ceci ne sera possible que si l’adresse LL correspondant à l’adresse IP de source a été mise en antémémoire à partir d’un événement précédent ; un routeur dans cette chaîne détermine l’adresse LL de la source à partir des datagrammes qui arrivent (voir HH1 ci-dessus). Si il ne peut pas déterminer si il est le premier bond, un routeur doit toujours envoyer un [X]Redirect, qui sera parasite si le routeur n’est pas le premier bond.

De tels [X]Redirect parasites seront envoyés à l’adresse IP de l’hôte de source ; mais en utilisant l’adresse LL du routeur du bond précédent. La portée de propagation des [X]Redirect peut être limitée à un seul bond IP (voir ci-dessous) afin qu’ils n’aillent pas plus loin que le routeur du bond précédent, où ils seront éliminés.

Cependant, il y aura quelque surcharge pour les routeurs à traiter ces [X]Redirect inutiles.

Ensuite, nous discutons des changements dans les hôtes et les routeurs, nécessaires pour la redirection bond par bond.

o   Changements chez l’hôte

La [RFC1122] sur les exigences pour les hôtes spécifie en son paragraphe 3.3.1 le mécanisme des hôtes pour acheminer un datagramme sortant en termes d’envoi du datagramme directement à une destination locale ou autrement au routeur de premier bond (pour atteindre une destination étrangère). Bien que ce mécanisme suppose une adresse locale, une adresse étrangère pour un routeur de premier bond devrait aussi bien fonctionner.

L’adresse cible contenue dans l’antémémoire d’acheminement est mise à jour par les messages Redirection. Il y a actuellement une restriction sur les adresses cibles qui peuvent être acceptées dans les messages Redirection au paragraphe 3.2.2.2 de la [RFC1122], qui empêcherait les redirections étrangères de fonctionner.

Un message Redirection DEVRAIT être éliminé en silence si la nouvelle adresse de routeur qu’il spécifie n’est pas sur le même (sous-) réseau connecté à travers lequel la redirection est arrivée, ou si la source de la redirection n’est pas le routeur de premier bond actuel pour la destination spécifiée.

La prise en charge des redirections étrangères exige simplement de retirer la première vérification de validité. La seconde vérification, qui exige qu’une redirection acceptable vienne du nœud auquel était envoyé le datagramme qui a déclanché la redirection, est conservée. La même vérification de validité serait utilisée pour les XRedirect.

Afin d’envoyer un datagramme à l’adresse cible trouvée dans l’antémémoire d’acheminement, un hôte doit résoudre l’adresse IP en adresse LL. Aucun changement ne devrait être nécessaire dans le mécanisme de résolution IP en LL de l’hôte pour traiter une adresse étrangère plutôt que locale.

La redirection bond par bond exige des changements à la sémantique de l’adresse IP qu’il est permis à une redirection ICMP de porter. Avec la présente définition [Postel81b], un message ICMP Redirection ne peut porter qu’une adresse IP de routeur. Pour que le mécanisme de redirection bond par bond élimine tous les bonds de routeur, en permettant à deux hôtes connectés au même SM de communiquer directement, un message [X]Redirect doit être capable de porter l’adresse IP de l’hôte de destination.

o   Changements chez le routeur

Chez les routeurs, les changements exigés pour la redirection bond par bond sont beaucoup plus étendus que ceux des hôtes. Les exemples donnés précédemment montraient les fonctions supplémentaires qui seraient nécessaires au routeur.

Considérons un routeur connecté à un SM. Lorsque il reçoit un datagramme provenant du SM, il vérifie si le prochain bond est sur le même SM, et s’il en est ainsi, il envoie un XRedirect étranger à l’hôte de source, en utilisant l’adresse de couche liaison avec laquelle le datagramme est arrivé.

Un routeur devrait éviter d’envoyer plus qu’un nombre limité de redirections étrangères successives au même hôte. Cela est nécessaire parce que un hôte non modifié peut légitimement ignorer un Redirection d’un réseau étranger et continuer de transmettre les datagrammes au même routeur. Un routeur peut réaliser cette limitation en entretenant une antémémoire des redirections étrangères envoyées.

Noter que les Redirections étrangers générés par les routeurs conformément à ces règles, comme les redirections locales courantes, peuvent voyager exactement sur un bond de couche liaison. Il est donc raisonnable et souhaitable de régler leur TTL à 1, pour s’assurer qu’il ne peuvent pas s’égarer hors du SM.

La vérification supplémentaire nécessaire pour déterminer si il faut générer un redirection peut impliquer du traitement supplémentaire et résulter donc en une dégradation des performances ; pour éviter cela, un routeur peut ne pas effectuer du tout la vérification et juste transmettre le paquet. Le schéma avec [X]Redirect ne s’applique pas à un tel routeur.

Finalement, on note que le schéma de redirection bond par bond n’est applicable que lorsque l’hôte de source est connecté à un SM, car les routeurs n’écoutent pas les Redirections. Pour optimise la transmission du trafic de transit entre le routeur frontière d’entrée et celui de sortie, une extension de l’acheminement est nécessaire, comme exposé au paragraphe suivant. À l’inverse, une extension au protocole d’acheminement ne peut pas être utilisée pour optimiser la transmission du trafic provenant d’un hôte connecté au SM, car un hôte ne devrait pas écouter les protocoles d’acheminement.

4.2   Acheminement élargi

Les protocoles d’acheminement peuvent être modifiés pour porter des informations supplémentaires spécifiques du SM. Le routeur pourrait utiliser l’attribut "SameSM" pour un chemin pour déduire le plus court chemin à rapporter à ses voisins. Il pourrait aussi porter les adresses LL avec chaque adresse IP de routeur.

Par exemple, le protocole d’acheminement élargi permettrait à R2 de savoir que R4 est le meilleur prochain bond pour atteindre le réseau de destination dans le même SM, et de savoir à la fois IP.R4 et LL.R4, qui conduisent au chemin Ha->R2->R4->Hb. On ne peut pas faire une optimisation plus poussée avec le seul acheminement élargi, car l’hôte ne participe pas à l’acheminement, et parce que on veut que le protocole d’acheminement ne traite que les informations par réseau, et non les informations par hôte. La redirection bond par bond pourrait alors être utilisée pour éliminer tous les bonds de routeur, comme dans la séquence suivante :

(1)   Datagramme 1 : Ha -> R2 -> R4 -> Hd

(2)   XRedirect(Hd, IP.R4, LL.R4): R2 -> Ha

(3)   Datagramme 2 : Ha -> R4 -> Hd

(4)   XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha

(5)   Datagramme 3 : Ha -> Hd

Il y a trois aspects dans l’élargissement du protocole d’acheminement :

(1)   la capacité à passer des informations de "tiers" -- un routeur devrait être capable de spécifier l’adresse (adresse IP et peut-être adresse LL) de quelque autre routeur comme prochain bond ;

(2)   connaître l’attribut "SameSM" pour les chemins ;

(3)   connaître les adresses LL correspondant aux adresses IP des routeurs au sein du même SM.

Un routeur doit être capable de déterminer qu’une adresse IP particulière IP (par exemple, l’adresse de source) est dans le même SM. Il y a plusieurs façons possibles de rendre cette information disponible à un routeur dans le SM.

(1)   Un routeur peut utiliser une seule interface physique vers un SM ; cela implique que toutes ses interfaces logiques résident au sein du même SM.

(2)   Il peut y avoir une structure administrative dans les adresses IP, par exemple, toutes les adresses IP au sein d’un SM national particulier peuvent avoir une chaîne de préfixe commune.

(3)   Il peut y avoir des informations de configuration, locales pour le routeur ou disponibles à partir d’un serveur centralisé (par exemple, le DNS). Noter qu’un routeur pourrait consulter ce serveur en arrière plan tout en continuant de transmettre sans délai les datagrammes. La seule conséquence du délai pour obtenir les informations sur "SameSM" serait quelques bonds inutiles (mais temporaires).

4.3   Mandataires ARP étendus

L’approche de Heinanen [Heinanen93] était destinée à résoudre le problème de la résolution d’adresse dans un support partagé sans mécanisme de diffusion (NBMA, Non-Broadcast, MultiAccess). Imaginons que le support partagé a un seul numéro de réseau, c’est-à-dire, soit un "nuage" de réseau. Heinanen envisage un ensemble de serveurs AR au sein de ce support. Ces serveurs AR utilisent entre eux certains protocoles d’acheminement. Un hôte source produit une demande ARP (via une transmission LL en point à point) auprès d’un serveur AR auquel il est associé. Cette demande ARP est transmise bond par bond à la couche liaison à travers les serveurs AR, vers le serveur AR associé à l’hôte de destination. Ce serveur AR résout l’adresse (en utilisant les informations apprises d’une annonce d’hôte ou d’un fichier de configuration) et retourne une réponse ARP à travers les serveurs AR à l’hôte de source.

       Ha            Hb            Hc            Hd

       |             |             |             |

  ---- | ----------  | ----------  | ----------  | ----

 (                                                     )

 (         Support partagé (un réseau logique)         )

 (                                                     )

  ----|--|---------|------------|----------|----|---

      |  |         |            |          |    |

- R1 -   |         |            |          |     --- R5 ---

     ____|__     __|____      __|____     _|_____

    | AR Sa |   | AR Sb |    | AR Sc |    | AR Sd |

    |_______|   |_______|    |_______|    |_______|

Figure 3 : Support partagé à un seul nuage

La Figure 3 suggère que chacun des hôtes Ha, ... Hd est associé à un serveur AR correspondant "AR Sa", ..."AR Sd".

Ce même schéma pourrait s’appliquer au modèle LIS de la Figure 2. Les serveurs AR seraient mis en œuvre dans les routeurs, et si le support prend en charge la diffusion, les hôtes seraient alors configurés comme mandataires ARP. À savoir qu’il serait dit à l’hôte que toutes les destinations sont locales, de sorte qu’il produise toujours une demande ARP pour la destination finale. C’est l’ensemble des serveurs AR qui va résoudre cette demande.

Comme les boucles d’acheminement sont une possibilité constante, la proposition de Heinanen comporte de plus un compte de bonds pour les demandes et réponses ARP.

Comme tous les schémas de mandataire ARP, celui-ci a une simplicité séduisante. Cependant, la résolution du problème du SM à la couche liaison induit plusieurs coûts. Elle exige un délai d’aller-retour complet avant l’écoulement du premier datagramme. Elle requiert un compte de bonds dans le paquet ARP. Cela semble un indice de ce que la couche liaison pourrait n’être pas l’endroit le plus approprié pour résoudre le problème du SM.

4.4   Messages d’interrogation d’acheminement

Ce schéma [Halpern93] introduit un nouveau mécanisme de niveau IP : des messages SM de demande et réponse d’acheminement. Ces messages sont transmis bond par bond comme datagrammes IP dans la direction de l’adresse de destination. Le routeur de sortie peut retourner une réponse, à nouveau bond par bond, qui atteint finalement l’hôte de source comme un XRedirect. Il serait aussi possible (mais pas nécessaire) de modifier les hôtes pour qu’ils génèrent ces interrogations.

La paire interrogation/réponse fournit les mêmes informations que l’on ajouterait aux protocoles d’acheminement avec l’acheminement élargi. Cependant, les messages interrogation/réponse nous permettraient de garder inchangés les protocoles d’acheminement actuels, et aussi ne fourniraient les informations supplémentaires que pour les chemins qui sont réellement nécessaires, réduisant donc les redondances dans l’acheminement. Noter que la séquence interrogation/réponse peut se faire en parallèle à la transmission du datagramme initial bond par bond, de sorte que cela n’ajoute pas un délai d’aller-retour supplémentaire.

4.5   Informations d’acheminement périmées

On doit examiner de qui se passe lorsque change la topologie du réseau. La technique de l’acheminement élargi (paragraphe 4.2) est capable de donner des assurances suffisantes que les informations périmées seront purgées du système durant le temps de convergence associé à l’utilisation d’un protocole d’acheminement particulier.

Cependant, on peut s’attendre à ce que les trois autres techniques (redirection bond par bond, mandataire ARP étendu, et messages d’interrogation d’acheminement) ne fournissent une transmission au minimum de bond que pour autant que la topologie du réseau reste inchangée depuis le moment de l’acquisition des informations. Les changements de la topologie peuvent résulter en changements du chemin à minimum de bonds, de sorte que le routeur de premier bond peut n’être plus le choix correct. Si l’hôte qui utilise ce routeur de premier bond n’est pas informé des changements, au lieu d’un chemin au minimum de bonds, l’hôte pourrait alors se trouver utiliser un chemin devenu sous optimal, et peut-être très sous optimal par rapport au nombre de bonds.

De plus, l’utilisation des informations acquises via un mandataire ARP étendu ou des messages d’interrogation d’acheminement pour optimiser l’acheminement entre les routeurs rattachés au même SM est très problématique, parce que la présence d’informations périmées dans les routeurs pourrait entraîner des transmissions en boucle qui pourraient perdurer tant que les informations ne sont pas purgées ; aucune de ces approches ne donne un traitement idoine des informations périmées

4.6   Implications du filtrage (pare-feu)

Pour diverses raisons, un administrateur de LIS peut ériger des pare-feu de couche IP (effectuer un filtrage de couche IP) pour restreindre la connexité LL entre les hôtes/routeurs au sein du LIS et entre les hôtes/routeurs dans les autres LIS au sein du même SM. Pour éviter des interruptions dans la transmission, les mécanismes décrits dans le présent document doivent prendre en compte de tels pare-feu.

L’utilisation des [X]Redirect exige d’un routeur qui génère un [X]Redirect qu’il soit informé des possibles contraintes de connexité de couche liaison entre le routeur qui est spécifié comme prochain bond dans le message Redirection et l’hôte qui est la cible de la redirection.

L’utilisation de l’acheminement élargi exige d’un routeur qui génère et/ou propage des informations "de tiers" qu’il soit informé des contraintes possibles de connexité de couche liaison. Précisément, un routeur ne devrait pas propager d’informations "de tiers" lorsque il y a un manque de connexité de couche liaison entre le routeur décrit par les informations et le routeur qui est le receveur immédiat de ces informations.

L’utilisation du mandataire ARP étendu exige d’un serveur ARP qu’il ne propage pas une demande ARP à un autre serveur ARP si il y a des contraintes de connexité de couche liaison entre l’origine de la demande ARP et l’autre serveur ARP.

L’utilisation des messages d’interrogation et réponse d’acheminement de SM exige des routeurs qu’ils passent les messages pour connaître les possibles contraintes de connexité de couche liaison. Le flux des messages doit refléter ces contraintes.

5.   Considérations pour la sécurité

On devrait discuter les problèmes de sécurité soulevés par les changements que nous suggérons. Il faut noter que nous ne parlons pas de sécurité "réelle" ; la sécurité réelle de l’Internet exige des techniques cryptographiques de bout en bout. Cependant, il ne devrait pas être facile de subvertir le mécanisme de base de livraison de IP pour qu’il cause l’écoulement des datagrammes vers des endroits inattendus.

Cela entendu, les problèmes de sécurité se posent dans deux endroits : les messages ICMP Redirection et les réponses ARP.

*   Sécurité de la redirection ICMP

On peut raisonnablement exiger que les routeurs soient sûrs. Ils sont généralement soumis à un contrôle administratif centralisé, et on peut supposer que les protocoles d’acheminement vont contenir des mécanismes d’authentification suffisants (même si ne n’est pas vrai actuellement). Donc, un hôte sera raisonnablement capable de se fier à une Redirection qui vient d’un routeur.

Cependant, il ne sera PAS raisonnable qu’un hôte se fie à un autre hôte. Supposons que l’hôte cible dans les exemples du paragraphe 4.1 soit douteux ; il n’y a aucun moyen de l’empêcher de produire un nouveau message Redirection pour une autre destination, n’importe où dans l’Internet. Par ailleurs, ce risque n’est pas pire que ce qu’il était avant ; l’hôte cible, une fois subverti, peut toujours agir comme un routeur caché pour transmettre le trafic ailleurs.

*   Sécurité de ARP

Actuellement, une réponse ARP ne peut venir que du réseau local, et un réseau isolé physiquement peut être sécurisé administrativement contre la subversion d’ARP. Cependant, une réponse ARP peut venir de n’importe où au sein du SM, et un malveillant peut utiliser ce fait pour détourner le flux de trafic de tout hôte au sein du SM [Bellovin89].

Le XRedirect bouche ce trou dans la sécurité. La validation du XRedirect (comme venant du nœud auquel le dernier datagramme était envoyé) va aussi valider l’adresse LL.

Une autre approche est de valider l’adresse de source d’où a été reçue la réponse ARP (en supposant que le protocole de couche liaison porte l’adresse de source et que le pilote la fournisse). Une réponse ARP acceptable pour l’adresse IP de destination D ne peut venir que de l’adresse LL x, où l’antémémoire d’acheminement transpose D -> E et l’antémémoire ARP donne x comme traduction de E. Cette validation, qui implique les deux antémémoires d’acheminement et d’ARP, peut être assez inélégante dans une stricte mise en œuvre en couches. Il serait naturel que la mise en couche soit d’ores et déjà violée par la combinaison de l’antémémoire ARP et d’acheminement. Il est possible à la couche liaison d’avoir des mécanismes de sécurité qui pourraient interférer avec la connexité de couche IP. En particulier, il pourrait y avoir une non transitivité de l’interconnexion logique au sein d’un support partagé. Plus précisément, certains grands réseaux publics de données peuvent inclure des options de configuration qui permettraient au réseau A de parler au réseau B et au réseau B de parler au réseau C, mais empêcherait A de parler directement à C. Dans ce cas, les protocoles d’acheminement doivent être assez sophistiqués pour traiter de telles anomalies.

6.   Conclusions

Nous avons discuté de quatre extensions possibles à l’architecture de l’Internet pour permettre une transmission efficace en termes de bonds des datagrammes IP au sein d’un support partagé, lorsque cette optimisation est permise par les pare-feu de couche IP. Nous ne tirons aucune conclusion dans le présent document sur le mécanisme qui serait le meilleur.

Les extensions suggérées sont évolutives, laissant intactes les idées de base de l’architecture actuelle de l’Internet. Il serait possible de faire (et certains l’ont suggéré) des changements beaucoup plus radicaux pour s’accommoder des supports partagés. À l’extrême, on pourrait abolir entièrement les nuages internes dans la Figure 2, de sorte qu’il n’y aurait aucune structure de réseau logique au sein du SM. Les adresses IP seraient alors logiques, et certains mécanismes de serveurs répartis seraient nécessaires pour trouver des chemins au sein de ce labyrinthe aléatoire. Nous pensons que cette approche ignore tout des exigences de gestion et de sécurité de l’Internet d’aujourd’hui. Cela peut faire un bon article de recherche, mais ce ne serait pas une bonne stratégie pour la conception de l’Internet.

7.   Remerciements

Nous sommes reconnaissants à Keith McGloghrie, Joel Halpern, et aux autres qui nous ont fourré le nez dans ce problème. Tous nos remerciements aussi à Tony Li (cisco), Greg Minshall (Novell), et John Garrett (AT&T) pour leur relecture et leurs commentaires constructifs. Nous remercions aussi Gerri Gilliland qui nous a fourni les nappes, les crayons de couleur et de la bonne nourriture qui ont permis que ces idées soient initialement assemblées.

8.   Références

[Bellovin89   S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM CCR, v. 19. n° 2, avril 1989.

[Garrett93]   J. Garrett, J. Hagan et J. Wong, "ARP dirigé", RFC1433, mars 1993. (Expérimentale)

[Plummer82]   D. Plummer, "Protocole de résolution d’adresses Ethernet : conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour transmission sur un matériel Ethernet", RFC0826, STD 37, novembre 1982.

[Halpern93]   J. Halpern, Communication privée, juillet 1993.

[Heinanen93]   J. Heinanen, R. Govindan, "Protocole de résolution d'adresse NBMA (NARP)", RFC1735, décembre 1994. (Exp)

[Laubach93]   M. Laubach, "IP classique et ARP sur ATM", RFC1577, janvier 1994. (Obsolète, voir la RFC2225)

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

[Postel81b]   J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", RFC0792, STD 5, septembre 1981.

[PSC81] Postel, J., Sunshine, C., and D. Cohen, "The ARPA Internet Protocol", Computer Networks 5, pp. 261-271, 1983.

[RFC1122]   R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, octobre 1989.

Adresse des auteurs