Groupe de travail Réseau

B. Carpenter, IBM

Request for Comments : 2775

février 2000

Catégorie : Information

Traduction Claude Brière de L'Isle

 

 

Transparence de l'Internet

 

 

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é

Ce document décrit l'état actuel de l'Internet du point de vue de l'architecture, se concentrant sur les questions de connexité et de transparence de bout en bout. Il se conclut par un résumé des choix architecturaux majeurs qui s'offrent à la couche réseau de l'Internet.

 

Le présent document a été utilisé comme contribution à l'atelier de l'IAB sur l'avenir de la couche réseau, qui s'est tenu en juillet 1999. Pour cette raison, il ne prétend pas être complet et définitif, et il s'abstient de toute recommandation.

 

Table des Matières

1.   Introduction

2.   Aspects de la connexité de bout en bout

2.1   L'argument de bout en bout

2.2   Performances de bout en bout

2.3   Transparence d'adresse de bout en bout

3.   Multiples causes de la perte de la transparence

3.1   Le modèle Intranet

3.2   L'allocation dynamique d'adresse

3.2.1   SLIP et PPP

3.2.2   DHCP

3.3   Les pare-feu

3.3.1    Pare-feu de base

3.3.2   SOCKS

3.4   Adresses privées

3.5   Traducteurs d'adresses réseau

3.6   Passerelles de niveau application, relais, mandataires et antémémoires

3.7   Isolement volontaire et réseaux homologues

3.8   Partage du DNS

3.9   Divers trucs de partage de charge

4.   Résumé et impact de l'état actuel

5.   Futures directions possibles

5.1   Migration réussie vers IPv6

5.2   Échec complet de IPv6

5.2.1   Réallocation de l'espace d'adresse IPv4

5.2.2   Extinxion

5.3   Déploiement partiel de IPv6

6.   Conclusion

7.   Considérations pour la sécurité

Remerciements

Références

Adresse de l'auteur

Déclaration complète de droits de reproduction

1.   Introduction

 

"L'Internet offre une liberté : pour autant qu'on accepte les règles d'envoi des paquets, on peut envoyer des paquets contenant n'importe quoi partout." [Berners-Lee]

 

L'Internet souffre d'un mal croissant qu'on appelle souvent "le problème du bout en bout". Le présent document tente d'analyser ce mal croissant en passant en revue l'état actuel de la couche réseau, en particulier sa perte progressive de transparence. Pour les besoins de ce document, "transparence" se réfère au concept original de l'Internet d'un seul schéma logique d'adressage logique universel, et au mécanisme par lequel les paquets peuvent s'écouler essentiellement inaltérés de leur source à leur destination.

 

Les causes de cette perte de transparence sont en partie l'artifice de l'allocation parcimonieuse de l'espace d'adresse limité disponible dans IPv4, et en partie le résultat de plus graves problèmes résultant de la large utilisation de la technologie de TCP/IP par les milieux d'affaires et les consommateurs. Par exemple, la traduction d'adresse réseau est un artifice, mais les intranets ne le sont pas.

 

Donc, pour aller de l'avant, on doit reconnaître les changements fondamentaux dans l'utilisation de TCP/IP qui conduisent la croissance actuelle de l'Internet. Dans un scénario, une migration complète vers IPv6 pourrait permettre la restauration de la transparence globale des adresses, mais sans retirer du tableau les pare-feu et les mandataires. À l'autre extrême, un échec total de IPv6 conduit à une fragmentation complète de la couche réseau, avec la connexité mondiale dépendant d'un assemblage sans fin de morceaux disparates.

 

Le présent document ne discute pas des implications sur l'acheminement de l'espace d'adresses, ni des implications de la gestion de la qualité de service sur l'état des routeurs, bien que ces deux questions interagissent dans une certaine mesure avec la transparence. Il ne discute pas non plus de façon substantielle des questions d'espace de noms.

 

2.   Aspects de la connexité de bout en bout

 

La phrase "de bout en bout", souvent abrégée en "e2e", est largement utilisée dans les discussions architecturales de l'Internet. Pour les besoins de cet article, nous présentons d'abord trois aspects distincts de la notion de bout en bout.

 

2.1   L'argument de bout en bout

 

Cet argument a été décrit pour la première fois dans [Saltzer] et révisé dans la [RFC1958], d'où est tirée cette longue citation :

 

L'argument de base est que, comme premier principe, certaines fonctions de bout en bout exigées ne peuvent être effectuées correctement que par les systèmes d'extrémité eux-mêmes. Un cas spécifique est que tout réseau, quel que soit le soin de sa conception, sera sujet à des défaillances de transmission à un taux statistiquement déterminé. La meilleure façon de s'en accommoder est de l'accepter, et de donner la responsabilité de l'intégrité de la communication aux systèmes d'extrémité. Un autres cas spécifique est la sécurité de bout en bout.

 

Pour citer [Saltzer], "La fonction en question ne peut être mise en œuvre complètement et correctement qu'avec la connaissance et l'aide de l'application qui se tient aux points d'extrémité du système de communications. Donc, fournir la fonction en question comme caractéristique du système de communication lui-même n'est pas possible. (Parfois une version incomplète de la fonction fournie par le système de communication peut être utile au titre de l'amélioration des performances.")

 

Ce principe a des conséquences importantes si on exige des applications qu'elles survivent à des défaillances partielles du réseau. Une conception de protocole de bout en bout ne devrait pas s'appuyer sur la maintenance d'état (c'est-à-dire, des informations sur l'état de la communication de bout en bout) à l'intérieur du réseau. Un tel état devrait n'être maintenu que dans les points d'extrémité, d'une façon telle que l'état ne puisse être détruit que lorsque le point d'extrémité a lui-même une défaillance (appelée partage de sort (fate-sharing)). Une conséquence immédiate en est que les datagrammes sont mieux que des circuits virtuels classiques. Le travail du réseau est de transmettre les datagrammes aussi efficacement et souplement que possible.

 

Donc ce premier aspect de la notion de bout en bout limite ce que l'on attend du réseau, et précise ce que le système d'extrémité est censé accomplir. L'argument de bout en bout est en toile de fond du reste de ce document.

 

2.2   Performances de bout en bout

 

Un autre aspect, dans lequel le comportement du réseau et celui des systèmes d'extrémité interagissent de façon complexe, est celui des performances, au sens général du terme. Ce n'est pas la préoccupation principale du présent document, mais il est mentionné brièvement car on s'y réfère souvent lorsque on discute des questions de bout en bout.

 

Beaucoup de travaux ont été accomplis depuis de nombreuses années pour améliorer et optimiser les performances de TCP. Curieusement, cela n'a conduit qu'à des changements relativement mineurs de TCP lui-même; La [RFC0793] est toujours valide à part quelques ajouts mineurs des [RFC1323], [RFC2581], [RFC2018]. Cependant une grande quantité de connaissances sur les bonnes pratiques de mise en œuvre de TCP a été édifiée, et les mécanismes de mise en file d'attente et d'élimination de paquets dans les routeurs ont été affinés pour améliorer les performances des systèmes dans des conditions d'encombrement.

 

Malheureusement, toute cette expérience des performances dans TCP ne nous aide pas dans les protocoles de transport qui n'affichent pas de réponses du genre de celles de TCP à l'encombrement [RFC2309]. Par conséquent, les exigences pour la qualité de service spécifiée pour les différentes applications et/ou consommateurs ont conduit à beaucoup de nouveaux développements, en particulier les modèles de services intégrés [RFC1633], [RFC2210] et de services différenciés [RFC2475]. En même temps sont apparus de nouveaux protocoles en relation avec le transport [RFC1889}, [RFC2326] ou sont en cours de discussion au sein de l'IETF. On devrait aussi noter que dans la mesure où la vitesse de la lumière n'est pas fixée par une norme de l'IETF, nos notions actuelles des performances de bout en bout seront sans aucune pertinence dans le réseautage interplanétaire.

 

Donc, en dépit du fait que les questions de performances et d'encombrement avec TCP sont maintenant assez bien comprises, l'arrivée des mécanismes de qualité de service et de nouveaux protocoles de transport soulève de nouvelles questions sur les performances de bout en bout, mais elles ne seront pas discutées plus avant ici.

 

2.3   Transparence d'adresse de bout en bout

 

Lorsque le concept de catenet (un réseau de réseaux) a été pour la première fois décrit par V. Cerf en 1978 [IEN 48] à la suite d'une suggestion antérieure de Pouzin en 1974 [CATENET], une hypothèse claire était qu'un seul espace d'adresses logique couvrirait le catenet entier (ou l'Internet comme nous l'appelons maintenant). Ceci s'appliquait non seulement à l'Internet TCP/IP précoce, mais aussi au concept PUP de Xerox, au concept OSI de réseau sans connexion, à XNS, et aux nombreuses autres architectures de réseau propriétaires.

 

Ce concept avait deux conséquences claires — les paquets pouvaient s'écouler essentiellement non altérés à travers le réseau, et leurs adresses de source et de destination pouvaient être utilisées comme étiquettes uniques pour les systèmes d'extrémité.

 

La première de ces conséquences n'est pas absolue. En pratique, des changements peuvent être faits aux paquets en transit. Certains d'entre eux sont réversibles à la destination (comme la fragmentation et la compression). D'autres peuvent être irréversibles (comme de changer les bits de type de service ou de décrémenter une limite de bonds) mais ils ne constituent pas un obstacle sérieux au principe de bout en bout du paragraphe 2.1. Cependant, tout changement fait à un paquet en transit qui exige de conserver des informations d'état par flux à un point intermédiaire violerait l'aspect du sort commun du principe de bout en bout.

 

La seconde conséquence de l'utilisation des adresses comme étiquettes uniques était dans un sens un effet collatéral du concept de catenet. C'est cependant un effet collatéral qui a eu des conséquences très significatives. L'unicité et la durabilité des adresses ont été exploitées de nombreuses façons, en particulier en les incorporant dans des identifiants de transport. Donc, elles ont été incorporées dans des sommes de contrôle de transport, dans des signatures cryptographiques, des documents de la Toile, et des serveurs avec des logiciels protégés par des licences. La [RFC2101] explore assez en détails cette question. Sa principale conclusion est que les adresses IPv4 ne peuvent plus être considérées comme uniques au monde ou invariantes, et toute conception de protocole ou d'applications qui suppose ces propriétés va subir des défaillances imprévisibles. Des travaux au sein de l'IAB et du groupe de travail NAT [RFC2993] ont analysé l'impact d'une cause spécifique de la non unicité et de la non invariance, c'est à dire, les traducteurs d'adresse réseau. La conclusion est là encore que de nombreuses applications vont connaître l'échec, sauf si elles sont spécifiquement adaptées pour éviter l'hypothèse de la transparence de l'adresse. Une forme d'adaptation est l'insertion d'une certaine forme de passerelle de niveau d'application, et une autre forme est que le NAT modifie les charges utiles au vol, mais dans les deux cas, l'adaptation est spécifique de l'application.

 

La non transparence des adresses fait partie d'un phénomène plus général. Nous devons reconnaître que l'Internet a perdu la transparence de bout en bout, et cela mérite une analyse plus poussée..

 

3.   Multiples causes de la perte de la transparence

 

Cette section décrit diverses inventions récentes qui ont conduit à la perte de la transparence de bout en bout dans l'Internet.

 

3.1   Le modèle Intranet

 

Sous-jacent à un certain nombre des développements spécifiques mentionnés ci-dessous est le concept d'un "intranet", vaguement défini comme un réseau privé d'entreprise utilisant la technologie TCP/IP, et connecté à l'Internet mondial d'une façon très contrôlée. L'intranet est présumé utilisé par les employés d'une entreprise pour les besoins de leur travail, et pour interconnecter des hôtes qui portent des informations sensibles ou confidentielles. Il est aussi tenu à un standard de disponibilité opérationnelle supérieur à celui de l'Internet mondial. Son usage peut être surveillé et contrôlé, et ses ressources peuvent être mieux planifiées et gérées que celles du réseau public. Ces arguments de gestion de la sécurité et des ressources ont assuré la domination du modèle intranet dans la plupart des entreprises et des campus.

 

L'émergence du modèle de l'intranet a eu un profond effet sur la notion de transparence d'application. De nombreux gestionnaires de réseau d'entreprise estiment que c'est à eux seuls de déterminer quelles applications peuvent traverser la frontière Internet/intranet. Dans cette vision du monde, la transparence de l'adresse peut sembler une considération sans importance.

 

3.2   L'allocation dynamique d'adresse

3.2.1   SLIP et PPP

On notera qu'avec l'arrivés sur l'Internet de grands nombres d'utilisateurs accédant par la numérotation téléphonique, dont les adresses sont allouées au moment de la numérotation, et dont le trafic peut être tunnelé en retour à leur FAI de rattachement, les adresses IP réelles de tels utilisateurs sont purement transitoires. Durant leur période de validité, elles peuvent compter sur le bout en bout, mais elles peuvent être oubliées à la fin de chaque session. En particulier elles peuvent n'avoir aucune association permanente avec le nom de domaine de l'hôte qui les emprunte.

 

3.2.2   DHCP

De la même façon, les utilisateurs de l'Internet dont la base est un LAN utilisent aujourd'hui fréquemment DHCP pour acquérir une nouvelle adresse au redémarrage du système, de sorte qu'ici aussi la valeur réelle de l'adresse est potentiellement transitoire et ne doit pas être mémorisée entre les sessions.

 

3.3   Les pare-feu

3.3.1    Pare-feu de base

Les gestionnaires d'intranet ont un souci majeur avec la sécurité : le trafic non autorisé doit être écarté à tout prix de l'intranet. Ce souci conduit directement au concept de pare-feu (un système qui intercepte tout le trafic entre l'Internet et l'Intranet, et ne laisse passer que le trafic choisi, qui appartient généralement à un ensemble très limité d'applications). Les pare-feu, par nature, limitent fondamentalement la transparence.

 

3.3.2   SOCKS

Une note de bas de page sur les effets des pare-feu est le mécanisme SOCKS dans la [RFC1928] par lequel les applications qui ne sont pas de confiance, comme telnet et ftp, peuvent passer à travers un pare-feu. SOCKS exige une bibliothèque de compensation dans le client intranet, et un serveur dans le pare-feu qui soit essentiellement un relais au niveau application. Par conséquent, le serveur distant ne voit pas le client réel ; il croit que le pare-feu est le client.

 

3.4   Adresses privées

 

Lorsque est apparue pour la première fois la menace de l'épuisement des adresses IPv4, et que dans certains cas des sites sont connus pour "pirater" des adresses pour une utilisation privée, un ensemble d'adresses privées officielles fut dans l'urgence alloué par la [RFC1597] puis ultérieurement défini avec plus de soins par la [RFC1918]. L'existence légitime d'une telle allocation d'adresses s'est révélée très attractive, de sorte que les intranets avec de grands nombres d'adresses non mondiales ont vu le jour. Malheureusement, de telles adresses ne peuvent pas, de par leur nature, être utilisées pour la communication à travers l'Internet public ; sans mesures particulières, les hôtes qui utilisent des adresses privées sont coupés du monde.

 

Noter que l'espace d'adresse privé est parfois affirmé comme un dispositif de sécurité, sur la base de la notion que la connaissance à l'extérieur des adresses internes pourrait aider à des intrusions. Ceci est un faux argument, car il est trivial de cacher des adresses à l'aide de listes de contrôle d'accès convenables, même si elles sont uniques au monde — ce qui est un dispositif de base d'un routeur filtrant, la forme la plus simple de pare feu. Un système avec une adresse cachée n'est pas plus privé qu'un système avec une adresse privée. Il n'est bien sûr absolument pas possible de cacher les adresses des serveurs dont ont demande l'accès à l'extérieur.

 

Il vaut aussi de noter que l'équivalent IPv6 des adresses privées, c'est-à-dire, les adresses de site local, ont des caractéristiques similaires à celles des adresses de la RFC1918, mais leur utilisation ne sera pas forcée par un manque d'adresse IPv6 uniques au monde.

 

3.5   Traducteurs d'adresses réseau

 

Les traducteurs d'adresse réseau (NAT, Network Address Translator) sont une conséquence presque inévitable de l'existence d'intranets utilisant des adresses privées et qui ont besoin de communiquer avec l'Internet mondial. Leurs implications architecturales sont exposées en détails dans la [RFC2993], le point fondamental étant que la traduction au vol de l'adresse détruit la transparence de bout en bout de l'adresse et casse tout appareil de médiation ou toutes applications qui en dépendent. De nombreux protocoles, par exemple H.323, portent des adresses au niveau application et ne réussissent pas à traverser correctement une simple boîte de NAT. Si la gamme complète des applications Internet doit être utilisée, les NAT doivent être couplés à des passerelles de niveau application (ALG, application level gateway) ou à des mandataires. De plus, l'ALG ou mandataire doit être mis à jour chaque fois qu'une nouvelle application dépendante de l'adresse apparaît. En pratique, la fonctionnalité de NAT est incorporée dans de nombreux produits de pare-feu, et tous les NAT utiles ont des ALG associées, de sorte qu'il est difficile de dissocier les divers impacts.

 

3.6   Passerelles de niveau application, relais, mandataires et antémémoires

 

Il est raisonnable de positionner les passerelles de niveau application, les relais, mandataires, et antémémoires à certains points topologiques critiques, en particulier à la frontière intranet/Internet. Par exemple, si un intranet n'utilise pas SMTP comme protocole de messagerie, une passerelle SMTP est nécessaire. Même dans le cas normal, un relais SMTP est chose courante, et peut effectuer d'utiles fonctions d'acheminement de messagerie, filtrage de pourriels, etc. (On peut observer que le filtrage des pourriels est d'une certaine façon une fonction de pare-feu, mais la nature à livraison différée de la messagerie électronique et la disponibilité des enregistrements MX lui permet d'être une fonction distincte et séparée.)

 

De la même façon, pour un protocole tel que HTTP avec un mécanisme de mandataire volontaire bien défini, les mandataires d'application qui servent aussi d'antémémoire sont très utiles. Bien que ces appareils interfèrent avec la transparence, il le font d'une manière précise, terminant correctement les protocoles réseau, transport et application des deux côtés. Ils peuvent cependant présenter des inconvénients dans les cas de configuration et de reprise sur défaillance.

 

Cependant, c'est le cas d'appareils de niveau application "involontaires" comme des mandataires qui se saisissent du trafic HTTP et le modifient sans utiliser les mécanismes appropriés, parfois appelés des "antémémoires transparentes", ou des relais de messagerie qui prétendent retirer des mots indésirables. Ces appareils sont par définition non transparents, et peuvent avoir des effets collatéraux totalement imprévisibles. (Une conclusion possible est que même pour des protocoles qui ne sont pas à livraison différée, un mécanisme générique de dérivation analogue à l'enregistrement MX présenterait quelques avantages. L'enregistrement SRV de la [RFC2052] est une étape dans cette direction.)

 

3.7   Isolement volontaire et réseaux homologues

 

Il y a des communautés qui se trouvent si différentes des autres qu'elles exigent l'isolement via un mandataire explicite, et même en utilisant des protocoles et des schémas d'adressage propriétaires au sein de leur réseau. Un exemple est celui du Forum WAP qui vise de très petits appareils semblables à des téléphones qui ont des capacité de connexité à l'Internet. Cependant, ce n'est pas à l'Internet qu'ils se connectent directement. Ils doivent passer par un mandataire. Cela pourrait vouloir dire que des millions d'appareils ne connaîtront jamais les avantages de la connexité de bout en bout sur l'Internet.

 

Un effet similaire survient lorsque des applications telles que la téléphonie s'étendent à la fois sur un réseau IP et sur une couche réseau homologue utilisant une technologie différente. Bien que l'application puisse fonctionner de bout en bout, il n'y a pas de possibilité de transmission de paquet de bout en bout.

 

3.8   Partage du DNS

 

Une autre conséquence de la séparation intranet/Internet est le "DNS partagé" ou le "DNS à deux faces", où un réseau d'entreprise dessert un DNS partiellement ou complètement différent à l'intérieur et à l'extérieur de son pare-feu. Il y a de nombreuses variantes possibles sur ce thème ; le point de base est que la correspondance entre un FQDN (nom de domaine pleinement qualifié) et une adresse IPv4 donnée n'est plus universelle et stable sur de longues périodes.

 

3.9   Divers trucs de partage de charge

 

IPv4 n'a pas été conçu pour prendre en charge la diffusion à la cantonade [RFC 1546], de sorte qu'il n'y a pas d'approche naturelle du partage de charge lorsque un serveur ne peut pas accomplir cette tâche. Divers trucs ont été utilisés pour résoudre ce problème (la diffusion groupée pour trouver un serveur libre, le DNS retourne différentes adresses pour le même FQDN dans un round-robin, un routeur achemine en fait les paquets envoyés à la même adresse automatiquement à différents serveurs, etc.). Bien que ces trucs ne soient pas particulièrement dommageables dans le tableau global, ils peuvent être mis en œuvre d'une façon telle qu'ils interfèrent avec la transparence de nom ou d'adresse.

 

4.   Résumé et impact de l'état actuel

 

Il est impossible de faire une estimation numérique fiable de l'étendue du déploiement des inventions ci-dessus. Comme beaucoup d'entre elles préservent l'illusion de la transparence alors qu'en réalité elles la brouillent, c'est extrêmement difficile à mesurer.

 

Cependant, il est certain que tous les mécanismes qui viennent d'être décrits sont très largement utilisés ; ils ne sont pas des phénomènes marginaux. Dans les réseaux d'entreprise, beaucoup d'entre eux sont la norme. Certains d'entre eux (pare-feu, relais, mandataires et antémémoires) ont clairement une valeur intrinsèque dans le concept d'Intranet. Les autres sont largement des artifices et des réponses pragmatiques aux diverses pressions du fonctionnement de l'Internet, et ils doivent être très coûteux pour l'industrie en termes d'administration constante et de diagnostics complexes de fautes.

 

En particulier, le déclin de la transparence a un effet sévère sur le déploiement de la sécurité IP de bout en bout. Le modèle de sécurité de l'Internet [RFC3631] invite à une sécurité à plusieurs niveaux (en gros, les niveaux réseau, applications, et objet). Le modèle actuel de sécurité au niveau réseau [RFC2401] a été construit avant la reconnaissance que la transparence de l'adresse de bout en bout subissait une menace sévère. Bien que des propositions de remplacement aient commencé d'émerger [HIP] la réalité actuelle est que IPSEC ne peut pas être déployé de bout en bout dans le cas général. IPSEC en mode tunnel peut être déployé entre des passerelles ou des pare-feu d'entreprises. IPSEC en mode transport peut être déployé au sein d'un réseau d'entreprise dans certains cas, mais il ne peut pas s'étendre d'un intranet à l'Internet puis à un autre intranet si il y a le moindre NAT sur le chemin.

Bien sûr, les NAT cassent aussi d'autres mécanismes de sécurité, comme DNSSEC et Kerberos, car ils s'appuient sur les valeurs d'adresses.

 

La perte de la transparence véhiculée par les adresses privées et les NAT affecte de nombreux protocoles d'application dans une mesure plus ou moins grande. Ceci est examiné en détails dans la [RFC3027]. Un effet plus subtil est que la prévalence des adresses dynamiques (depuis DHCP, SLIP et PPP) a nourri la tendance en faveur du calcul client/serveur. Il est largement vrai aujourd'hui que les serveurs ont des adresses fixes, que les clients ont des adresses dynamiques, et que les serveurs ne peuvent en aucune façon faire que l'adresse IP d'un client identifie le client. D'un autre côté, les clients s'appuient sur des serveurs qui ont des adresses stables car une recherche auprès du DNS est le seul mécanisme universellement déployé par lequel un client puisse trouver un serveur et en solliciter le service. Dans cet environnement, il y a peu de place pour les vrais protocoles d'applications d'homologue à homologue, et pas de solution facile pour les serveurs mobiles. Bien sûr, la demande très limitée de IP mobile peut être partiellement attribuée à la domination du marché par les applications client/serveur dans lesquelles l'adresse du client n'a qu'une signification transitoire. On voit aussi une tendance à aller vers un seul point de défaillance comme les passerelles de supports, qui résultent là encore de la difficulté de mettre en œuvre des solutions d'homologue à homologue directement entre des clients sans adresse fixe.

 

La notion selon laquelle les serveurs peuvent utiliser les précieuses adresses uniques au monde d'une petite réserve mise en commun, parce qu'il y aura toujours moins de serveurs que de clients, peut paraître anachronique lorsque la plupart des appareils électriques deviennent gérables par le réseau, et deviennent donc des serveurs pour un protocole de gestion. De même, si chaque PC devient un téléphone (ou l'inverse) capable de recevoir des appels entrants non sollicités, le manque d'adresses IP stables pour les ordinateurs personnels sera un problème. Un autre glissement imminent de paradigme est quand les abonnés domestiques et des travailleurs indépendants vont passer de la connexion par numérotage téléphonique à la connexion permanente à l'Internet, l'allocation d'adresses transitoires prise dans une réserve commune deviendra beaucoup moins appropriée.

 

Beaucoup des inventions décrites dans la section précédente conduisent à ce qu'au moins un autre hôte s'interpose directement ou indirectement entre le trafic de datagrammes échangé entre deux hôtes. Par exemple, un client peut dépendre d'un serveur DHCP, un serveur peut dépendre d'un NAT, et tout hôte peut dépendre d'un pare-feu. Cela viole le principe du sort partagé de [Saltzer] et introduit des points de défaillance uniques. Pire, la plupart de ces points de défaillance exigent des données de configuration, ce qui est une autre source de risque de fonctionnement. La notion originale selon laquelle les datagrammes trouveraient leur chemin en contournant les défaillances, en particulier les routeurs défaillants, a été perdue ; bien sûr, la surcharge des routeurs frontières avec des fonctions supplémentaires en a fait des composants critiques plutôt que redondants, même pour les sites à rattachements multiples.

 

La perte de la transparence de l'adresse a d'autres effets négatifs. Par exemple, les serveurs de grandes dimensions peuvent utiliser une heuristique ou même des politiques formelles qui allouent des priorités différentes au service pou les différents clients, sur la base de leurs adresses. Comme les adresses perdent leur signification mondiale, ce mécanisme va échouer. De même, toutes les techniques anti-pourriels ou anti-mystification qui s'appuient sur une recherche de DNS inverse des valeurs d'adresse peuvent être trompées par des adresses traduites. (Le dénumérotage non coordonné peut avoir des inconvénients similaires.)

 

Les questions ci-dessus ne sont pas académiques. Elles ajoutent à la complexité de la conception des applications, la complexité de la configuration du réseau, la complexité des mécanismes de sécurité, et la complexité de la gestion du réseau, elles rendent le diagnostic des fautes plus difficile, et en introduisant plus de points de défaillance uniques, elles rendent la survenance des fautes plus probables.

 

5.   Futures directions possibles

5.1   Migration réussie vers IPv6

 

Dans ce scénario, IPv6 devient pleinement mis en œuvre sur tous les hôtes et routeurs, y compris l'adaptation des matériels de médiation, les applications, et les systèmes de gestion. Comme l'espace d'adresses devient alors assez grand pour tous les besoins concevables, la transparence des adresses peut être restaurée. IPSEC en mode transport peut en principe être déployé, avec des outils de politique de sécurité adéquats et une infrastructure de clés. Cependant, nous pensons fortement que le modèle intranet/pare-feu va certainement persister.

 

Noter qu'il y a une hypothèse de base d'IPv6 qu'aucune contrainte artificielle ne sera imposée à la fourniture des adresses, étant donné qu'il y en a tant. Les pratiques actuelles par lesquelles certains FAI limitent fortement le nombre d'adresses IPv4 par client n'auront aucune raison d'exister pour IPv6. (Cependant, les adresses seront toujours allouées avec prudence, conformément aux lignes directrices conçues pour favoriser l'acheminement hiérarchique.)

 

Ceci est évidemment dans tous les cas un scénario à très long terme, car il suppose que IPv4 a décliné au point que IPv6 soit nécessaire pour assurer la connexité universelle. Donc, une version viable du scénario du paragraphe 5.3 est un pré-requis pour le scénario du 5.1.

 

5.2   Échec complet de IPv6

 

Dans ce scénario, IPv6 échoue à atteindre un niveau significatif de déploiement opérationnel, l'adressage IPv4 est le seul mécanisme disponible, et la transparence de l'adresse ne peut pas être restaurée. IPSEC ne peut pas être déployé mondialement sous sa forme actuelle. À très long terme, le pot d'adresses IPv4 uniques au monde sera presque totalement alloué, et de nouvelles adresses ne seront généralement disponibles pour aucun objet.

 

On ne sait pas exactement ce qui va se passer si l'Internet continue de s'appuyer exclusivement sur IPv4, parce que dans cette éventualité divers schémas ont des chances de prendre le dessus, avec une possibilité de fournir un chemin d'évolution acceptable pour le réseau. Cependant, on peut examiner des sous scénarios possibles parmi les plus simplistes, tout en sachant bien que l'avenir ne correspondra vraisemblablement pas exactement à l'un ou à l'autre :

 

5.2.1   Réallocation de l'espace d'adresse IPv4

Supposons que soit créé un mécanisme pour continuellement récupérer et réallouer les adresses IPv4. Un seul espace d'adresses mondial est conservé, et tous les sites passent progressivement à un modèle d'adresse d'intranet privé, les adresses mondiales étant allouées temporairement à partir d'un pôle de plusieurs milliards.

 

5.2.1.1   Un sous-sous-scénario est l'utilisation généralisée de NAT et de NAPT (un NAT avec traduction du numéro d'accès). Cela a l'inconvénient que l'hôte ne connaît pas l'adresse unique qui est utilisée pour son trafic, ne connaissant que son adresse privée ambiguë, avec tous les problèmes que cela génère. Voir la [RFC2993].

 

5.2.1.2   Un autre sous-sous-scénario est l'utilisation de l'adressage IP spécifique par domaine mis en œuvre chez l'hôte plutôt que par une boîte de NAT. Voir [RSIP]. Dans ce cas, l'hôte connaît son adresse unique, ce qui permet une restauration substantielle de l'utilité de bout en bout des adresses, par exemple, pour TCP ou pour les sommes de contrôle cryptographiques.

 

5.2.1.3   Un dernier sous-sous-scénario est le modèle "transposer et encapsuler" dans lequel la traduction d'adresse est remplacée par l'encapsulation systématique de tous les paquets pour le transport à grande distance. Ce modèle n'a jamais été pleinement développé, bien qu'il soit complètement compatible avec l'adressage de bout en bout.

 

5.2.2   Extinction

Supposons qu'aucun mécanisme ne soit créé pour récupérer les adresses (excepté peut-être un commerce au marché noir ou ouvert). Les sites avec de gros blocs d'adresses les gardent. Tous les scénarios du 5.2.1 apparaissent mais ne suffisent pas. Finalement l'espace mondial d'adresses n'est plus adéquat. C'est un scénario de cauchemar – les NAT apparaissent au sein de l'espace d'adresses "mondial", par exemple aux frontières entre les FAI. Il n'est pas évident qu'un système mondial d'acheminement et un système DNS mondial puissent être conservés ; l'Internet est fragmenté de façon permanente.

 

5.3   Déploiement partiel de IPv6

 

Dans ce scénario, IPv6 est complètement mis en œuvre mais n'est déployé que dans certains segments du réseau (par exemple dans certains pays, ou dans certaines zones d'application telles que les appareils mobile portables). Au lieu d'être transitoires par nature, certaines des techniques de transition vers IPv6 deviennent des caractéristiques permanentes du paysage. Parfois les adresses font 32 bits, parfois elles sont de 128 bits. Les recherches sur le DNS peuvent retourner soit l'une ou l'autre, soit les deux. Dans le monde à 32 bits, les scénarios 5.2.1 et 5.2.2 peuvent survenir. IPSEC peut seulement se déployer partiellement.

 

6.   Conclusion

 

Aucun des scénarios ci-dessus n'est clair, simple et direct. Bien que le pur scénario IPv6 soit le plus net et le plus simple, il ne s'atteint pas directement. Les divers scénarios sans utilisation d'IPv6 sont tous confus et semblent finalement conduire d'une façon ou d'une autre à des impasses. Le déploiement partiel de IPv6, qui est une étape exigée sur le chemin du déploiement complet, est tout aussi confus mais évite les impasses.

 

7.   Considérations pour la sécurité

 

La perte de transparence est à la fois une faute et une caractéristique du point de vue de la sécurité. Dans la mesure où elle empêche le déploiement de bout en bout de IPSEC, elle met en danger la sécurité et crée des faiblesses. Par exemple, si une boîte NAT standard est sur le chemin, le mieux qu'on puisse faire est de déchiffrer et rechiffrer le trafic IP dans le NAT. Le trafic sera donc momentanément en clair et potentiellement vulnérable. De plus, le NAT possèdera de nombreuses clés et sera une cible principale d'attaque. Dans des environnements où c'est inacceptable, le chiffrement doit plutôt être appliqué au dessus de la couche réseau, bien sûr sans aucune utilisation des adresses IP quelles qu'elles soient dans les données qui sont protégées cryptographiquement. Voir les précisions à la section 4.

 

Dans certains scénarios, c'est-à-dire, 5.1 (IPv6 plein) et 5.2.1.2 (RSIP), IPSEC de bout en bout deviendrait possible, en particulier en utilisant le modèle du "pare-feu réparti" dont [Bellovin] s'est fait l'avocat.

 

La perte de transparence à la frontière intranet/Internet peut être considérée comme un dispositif de sécurité, dans la mesure où il fournit un point bien défini auquel on peut appliquer des restrictions. Cette forme de sécurité est sujette au risque "dur à l'extérieur, mou à l'intérieur", par lequel toute pénétration réussie de la frontière expose l'intranet entier à des attaques triviales. L'absence de sécurité de bout en bout appliquée au sein de l'intranet ignore aussi les menaces de l'intérieur.

 

On devrait noter que la sécurité appliquée au-dessus du niveau transport, tel que SSL, SSH, PGP ou S/MIME, n'est pas affectée par les questions de transparence de la couche réseau.

 

Remerciements

 

Le présent document et les questions qui s'y rapportent ont fait l'objet de larges discussions au sein de l'IAB. Des remerciements particuliers à Steve Deering pour sa révision détaillée ainsi qu'à Noel Chiappa. Des commentaires ou idées utiles ont aussi été reçues de Rob Austein, John Bartas, Jim Bound, Scott Bradner, Vint Cerf, Spencer Dawkins, Anoop Ghanwani, Erik Guttmann, Eric A. Hall, Graham Klyne, Dan Kohn, Gabriel Montenegro, Thomas Narten, Erik Nordmark, Vern Paxson, Michael Quinlan, Eric Rosen, Daniel Senie, Henning Schulzrinne, Bill Sommerfeld, et George Tsirtsis.

 

Références

(Les liens sur les numéros des RFC pointent sur l'original anglais ; ceux dans le titre sur la traduction française)

[Bellovin]   S. Bellovin, "Distributed Firewalls", disponible à http://www.research.att.com/~smb/papers/distfw.pdf ou http://www.research.att.com/~smb/papers/distfw.ps (Travail en cours).

[Berners-Lee]   T. Berners-Lee, M. Fischetti, HarperCollins, "Weaving the Web", 1999, p 208.

[Saltzer]   J.H. Saltzer, D.P.Reed, D.D.Clark, "End-To-End Arguments in System Design", ACM TOCS, Vol 2, n° 4, novembre 1984, pp 277-288.

[IEN 48]   Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, juillet 1978.

[CATENET]   Pouzin, L., "A Proposal for Interconnecting Packet Switching Networks," Proceedings of EUROCOMP, Brunel University, mai 1974, pp. 1023-36.

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

[RFC1546]   C. Partridge, T. Mendez, W. Milliken, "Service d'envoi à la cantonade pour les hôtes", novembre 1993. (Information)

[RFC1597]   Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot, "Allocation d'adresse pour les Internets privés" mars 1994. (Information, remplacée par la RFC1918)

[RFC1633]   R. Braden, D. Clark et S. Shenker, "Intégration de services dans l'architecture de l'Internet : généralités", juin 1994. (Info.)

[RFC1889]   H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voirRFC3550 STD64)

[RFC1918]   Y. Rekhter et autres, "Allocation d'adresse pour les internets privés", février 1996.

[RFC1928]   M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas et L. Jones, "Protocole SOCKS version 5", mars 1996.

[RFC1958]   B. Carpenter, éd., "Principes de l'architecture de l'Internet", juin 1996. (MàJ parRFC3439) (Information)

[RFC2018]   M. Mathis et autres, "Options d'accusé de réception sélectif sur TCP", octobre 1996. (Remplace RFC1072) (P.S.)

[RFC2052]   A. Gulbrandsen, P. Vixie, "Enregistrement DNS pour spécifier la localisation de services (DNS SRV)", octobre 1996. (Obsolète, voirRFC2782) (Expérimentale)

[RFC2101]   B. Carpenter, J. Crowcroft, Y. Rekhter, "Comportement actuel des adresses IPv4", février 1997. (Information)

[RFC2210]   J. Wroclawski, "Utilisation de RSVP avec les services intégrés de l'IETF", septembre 1997. (P.S.)

[RFC2309]   B. Braden et autres, "Recommandations sur la gestion de file d'attente et l'évitement d'encombrement dans l'Internet", avril 1998.

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

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

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

[RFC2581]   M. Alman, V. Paxson et W. Stevens, "Contrôle d'encombrement avec TCP", avril 1999. (Remplacée par RFC5681)

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

[RFC3027]   M. Holdrege, P. Srisuresh, "Complications de protocole avec le traducteur d'adresse réseau IP", janvier 2001. (Info.)

[RFC3631]   S. Bellovin, J. Schiller et C. Kaufman, éd., "Mécanismes de sécurité pour l'Internet", décembre 2003. (Information)

[RSIP]   Lo, J., Borella, M. and D. Grabelsky, "Realm Specific IP: A Framework", Travail en cours.

[HIP]   Moskowitz, R., "The Host Identity Payload", Travail en cours.

 

Adresse de l'auteur

 

Brian E. Carpenter

IBM

c/o iCAIR

Suite 150

1890 Maple Avenue

Evanston, IL 60201

USA

mél : brian@icair.org

 

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 droits de reproduction ci-dessus et ce paragraphe soient 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 procédures des normes d' 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 ou 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 fourni par la Internet Society.