RFC(F) 3869

From RFC.Wiki
Jump to: navigation, search

Demande de commentaires du groupe de travail du réseau : 3869
Catégorie: Information
Internet Architecture Board

Août 2004

Préoccupations et recommandations de l'IAB

concernant la recherche et l'évolution sur Internet
R. Atkinson, Ed.
S. Floyd, éd.

Statut de ce mémo 
Ce mémo fournit des informations à la communauté Internet. Il ne spécifie aucune norme Internet d'aucune sorte. La distribution de ce mémo est illimitée.
Copyright 
Copyright (C) L'Internet Society (2004).
Abstrait 
Ce document discute des préoccupations de l'IAB selon lesquelles des recherches en cours sont nécessaires pour poursuivre l'évolution de l'infrastructure Internet et qu'un financement non commercial suffisant et cohérent est nécessaire pour permettre une telle recherche.


Contents


1. Introduction

Ce document traite de l'historique du financement de la recherche sur Internet, exprime des inquiétudes concernant l'état actuel de ce financement et décrit plusieurs domaines spécifiques qui, selon l'IAB, méritent des recherches supplémentaires. Les niveaux de financement actuels de la recherche sur Internet ne sont généralement pas adéquats et plusieurs domaines de recherche importants sont considérablement sous-financés. Cette situation doit être corrigée pour qu'Internet poursuive son évolution et son développement.

1.1. Organisation des documents

La première partie du document est une discussion de haut niveau sur l'historique du financement de la recherche sur Internet afin de fournir un contexte historique à ce document. Le financement initial de la recherche sur Internet provenait en grande partie du gouvernement américain, suivi par une période dans la seconde moitié des années 90 de financement commercial et de financement de plusieurs gouvernements. Cependant, le financement commercial de la recherche sur Internet a été réduit en raison du récent ralentissement économique.

La deuxième partie du document fournit un ensemble incomplet de sujets de recherche ouverts sur Internet. Ce ne sont que des exemples destinés à illustrer l'ampleur des sujets de recherche ouverts. Cette deuxième section soutient la thèse générale selon laquelle des recherches en cours sont nécessaires pour faire avancer l'évolution de l'infrastructure Internet. Cela comprend la recherche sur l'évolution à moyen terme de l'infrastructure Internet ainsi que la recherche sur les grands défis à plus long terme. Cela comprend également de nombreuses questions de recherche qui sont déjà activement étudiées dans la communauté de recherche Internet.

Les domaines abordés dans cette section sont les suivants: dénomination, routage, sécurité, gestion du réseau et transport. Les problèmes qui nécessitent plus de recherche comprennent également des problèmes d'architecture plus généraux tels que la superposition et la communication entre les couches. En outre, les sujets généraux abordés dans cette section comprennent la modélisation, la mesure, la simulation, les bancs d'essai, etc. Nous nous concentrons sur des sujets liés aux agendas de l'IETF et de l'IRTF (Internet Research Task Force). (Par exemple, les problèmes de Grid ne sont pas abordés dans ce document, car ils sont traités par le biais du Global Grid Forum et d'autres organisations spécifiques au Grid, pas dans l'IETF.)

Dans la mesure du possible, les exemples de ce document renvoient à des documents séparés sur ces questions et ne donnent qu'un résumé de haut niveau des questions soulevées dans ces documents.

1.2. Préoccupations de l'IAB

Au lendemain du 11 septembre 2001, les gouvernements semblent s'intéresser de nouveau au financement de la recherche sur les problèmes de sécurité liés à Internet. De [Jackson02]: "Il est généralement admis que la sécurité et la fiabilité des protocoles de base sous-jacents à Internet n'ont pas reçu suffisamment d'attention parce que personne n'y a un intérêt propriétaire".

Cette citation met en évidence un problème clé dans le financement de la recherche sur Internet, à savoir qu'aucune organisation unique (par exemple, aucun gouvernement, aucun éditeur de logiciels, aucun fournisseur d'équipement ou opérateur de réseau) n'a le sentiment de s'approprier l'infrastructure Internet mondiale, la recherche sur les problèmes généraux de l'infrastructure Internet n’est souvent pas suffisamment financée. Dans notre climat économique difficile actuel, il n'est pas surprenant que les sources de financement commerciales soient plus susceptibles de financer cette recherche qui mène à un avantage concurrentiel direct.

La thèse principale de ce document est que si le financement commercial est la principale source de financement des futures recherches sur Internet, l'avenir de l'infrastructure Internet pourrait être en difficulté. En plus des questions sur les projets financés, la source de financement peut également affecter le contenu de la recherche, par exemple, en faveur ou contre le développement de normes ouvertes, ou en se souciant à divers degrés de l'effet des protocoles développés sur les autres trafics sur Internet.

Dans le même temps, de nombreuses contributions importantes à la recherche dans le domaine du réseautage proviennent de financements commerciaux. Cependant, pour la plupart des sujets abordés dans ce document, se fier uniquement à la recherche financée commercialement ne serait pas suffisant. Une grande partie du financement commercial actuel est axée sur la transition technologique, en prenant les résultats de la recherche non commerciale et en les intégrant à l'expédition de produits commerciaux. Nous n'avons pas essayé d'approfondir chacune des questions de recherche ci-dessous pour discuter, pour chaque question, du potentiel et des limites du financement commercial de la recherche dans ce domaine.

Sur une note plus pratique, s'il n'y avait pas de financement commercial pour la recherche sur Internet, alors peu de projets de recherche seraient menés à terme avec des mises en œuvre, un déploiement et une évaluation de suivi.

S'il est théoriquement possible qu'il y ait trop de financement pour la recherche sur Internet, c'est loin d'être le problème actuel. Il y a aussi beaucoup à faire au sein de la communauté de recherche du réseau pour rendre la recherche Internet plus ciblée et plus productive, mais cela ferait partie d'un document distinct.

1.3. Contributions à ce document

Un certain nombre de personnes ont directement contribué au texte de ce document, même si, conformément aux conventions actuelles, la liste officielle des auteurs RFC ne comprend que les principaux éditeurs du document. La section Remerciements à la fin du document remercie les autres personnes qui ont contribué à ce document sous une forme ou une autre.

2. Historique de la recherche sur Internet et du financement de la recherche

2.1. Avant 1980

La plupart des premières recherches sur les réseaux à commutation de paquets ont été financées par la US Defense Advanced Research Projects Agency (DARPA) [CSTB99]. Cela comprend la conception initiale, la mise en œuvre et le déploiement de l'ARPAnet reliant plusieurs universités et autres entrepreneurs de la DARPA. L'ARPAnet a été mis en ligne à la fin des années 1960. Il a pris de l'ampleur au cours des années 1970, toujours principalement grâce au financement de la DARPA, et a démontré l'utilité du réseau à commutation de paquets.

Le financement de la DARPA pour la conception Internet a commencé en 1973, quatre ans seulement après le déploiement initial d'ARPAnet. Le soutien à la conception d’Internet était l’un des résultats du financement antérieur de la DARPA pour la recherche sur la radio par paquets et les satellites par paquets. L'existence de plusieurs réseaux (ARPAnet, radio par paquets et satellite par paquets) a conduit à la recherche d'interréseaux. Internet est né dans une large mesure à la suite du financement de la recherche DARPA pour ces trois réseaux - et ne résulte qu'incidemment des travaux financés par Xerox PARC sur Ethernet.

2.2. Années 1980 et début des années 1990

L'ARPAnet est passé au protocole Internet (IP) le 1er janvier 1983, environ 20 ans avant la rédaction de ce document. Tout au long des années 80, le gouvernement des États-Unis a continué de financer fortement la recherche et le développement pour la technologie Internet. La DARPA est restée la principale source de financement, mais a été complétée par d'autres financements du DoD (US Department of Defence) (par exemple, via le programme Defence Data Network (DDN) de la Defense Communication Agency (DCA)) et d'autres financements du gouvernement américain (par ex. , Financement du Département américain de l'énergie (DoE) pour les réseaux de recherche dans les laboratoires nationaux du DoE, financement de la National Science Foundation (NSF) (États-Unis) pour les établissements universitaires). Ce financement comprenait la recherche fondamentale, la recherche appliquée (y compris les prototypes librement distribuables), l'achat de produits compatibles IP,

Au cours des années 80, le Département de la Défense des États-Unis a souhaité abandonner la fourniture de services de réseau opérationnels aux établissements universitaires, de sorte que le financement de la plupart des activités universitaires a été transféré à la NSF au cours de la décennie. Le travail initial de NSF comprenait le parrainage de CSnet en 1981. En 1986, NSF parrainait également divers projets de recherche sur le réseautage (par exemple, le travail de Mills sur les Fuzzballs). À la fin des années 80, NSF a créé le backbone NSFnet et a parrainé la création de plusieurs réseaux régionaux NSF (par exemple, SURAnet) et des interconnexions avec plusieurs réseaux de recherche internationaux. NSF a également financé la recherche sur les réseaux gigabits, par le biais de la Corporation for National Research Initiatives (CNRI), à partir de la fin des années 1980. Il est important de noter que le parrainage de la NSF était axé sur la réalisation des objectifs fondamentaux de la NSF, comme la mise en relation de scientifiques de grandes universités avec des centres de calcul intensif NSF. Les besoins d'accès à distance hautes performances aux supercalculateurs ont conduit les performances globales de NSFnet. En tant qu'effet secondaire, cela signifiait que les étudiants et les professeurs de ces universités bénéficiaient d'un environnement Internet relativement performant. Au fur et à mesure que ces étudiants ont obtenu leur diplôme, ils ont favorisé à la fois l'utilisation commerciale d'Internet et le marché résidentiel naissant. Ce n’est pas un hasard si c’est dans cet environnement que le World Wide Web est né. ils ont conduit à la fois à l'utilisation commerciale d'Internet et au marché résidentiel naissant. Ce n’est pas un hasard si c’est dans cet environnement que le World Wide Web est né. ils ont conduit à la fois à l'utilisation commerciale d'Internet et au marché résidentiel naissant. Ce n’est pas un hasard si c’est dans cet environnement que le World Wide Web est né.

La plupart des financements de recherche en dehors des États-Unis au cours des années 1980 et au début des années 1990 étaient axés sur le projet de réseau ISO OSI ou sur les nouvelles formes de médias de réseau à l'époque (par exemple, l'accès sans fil à large bande). L'Union européenne a été une source importante de financement de la recherche pour la communauté des réseaux en Europe pendant cette période. Certains des meilleurs travaux préliminaires de mise en réseau gigabit ont été entrepris au Royaume-Uni et en Suède.

2.3. Milieu des années 1990 à 2003

À partir du milieu des années 90, le financement du gouvernement américain pour la recherche et le développement sur Internet a été considérablement réduit. La prémisse à cet égard était que l’industrie Internet en pleine croissance paierait pour la recherche et le développement nécessaires. Certains financements pour la recherche et le développement d'Internet ont continué pendant cette période de la part d'organisations européennes et asiatiques (par exemple, le projet WIDE au Japon [WIDE]). Réseaux IP Europeens [RIPE] est un exemple de recherche de réseau financée par le marché en Europe au cours de cette période.

L’expérience de cette période a montré que les entreprises commerciales se sont souvent concentrées sur le don d’équipement aux établissements universitaires et sur la promotion de projets éducatifs quelque peu professionnels. Bon nombre des projets de recherche et développement financés par le commerce semblent avoir été sélectionnés parce qu'ils semblaient susceptibles de donner à la source de financement un avantage économique spécifique à court terme par rapport à ses concurrents. Les propositions de recherche plus risquées et plus innovantes n'ont généralement pas été financées par l'industrie. Une opinion commune dans la Silicon Valley a été que les entreprises commerciales établies ne sont pas très douées pour la transition de la recherche de pointe vers les produits, mais étaient plutôt bonnes pour acheter de petites entreprises en démarrage qui avaient réussi la transition de ces recherches de pointe vers des produits. Malheureusement,

2.4. Statut actuel

Le résultat de la réduction du financement du gouvernement américain et du financement industriel à court terme et à faible risque axé sur le profit a été un déclin des activités de recherche plus risquées, mais plus innovantes. L'industrie s'est également moins intéressée à la recherche pour faire évoluer l'architecture globale d'Internet, car ce travail ne se traduit pas par un avantage concurrentiel pour l'entreprise qui finance ce travail.

Le CCI estime qu'il serait utile que les gouvernements et autres sponsors non commerciaux augmentent leur financement à la fois de la recherche fondamentale et de la recherche appliquée liées à Internet, et de maintenir ces niveaux de financement à l'avenir.

3. Ouvrir les sujets de recherche Internet

Cette section traite principalement de certains sujets spécifiques qui, selon l'IAB, méritent des recherches supplémentaires. La recherche, bien sûr, comprend non seulement la conception d'une théorie, d'un algorithme ou d'un mécanisme pour atteindre un objectif, mais également l'évaluation de l'efficacité générale de l'approche, puis les avantages par rapport aux coûts de déploiement de cet algorithme ou mécanisme. Des mises en garde importantes concernant cette discussion sont données dans la sous-section suivante. Cet ensemble particulier de sujets ne se veut pas exhaustif, mais vise plutôt à démontrer l'étendue des questions de recherche ouvertes sur Internet.

D'autres discussions sur les problèmes d'Internet qui méritent des recherches plus approfondies sont les suivantes: [CIPB02, Claffy03a, Floyd, NSF03a, NSF03b].

3.1. Portée et limites

Ce document n'est PAS conçu comme un guide pour les agences de financement public quant aux projets ou propositions qui devraient ou ne devraient pas être financés.

En particulier, ce document n'est PAS destiné à être une liste complète de * toutes * les questions de recherche qui sont importantes pour faire avancer l'évolution d'Internet; ce serait une tâche ardue et supposerait un effort plus large et plus intensif que celui que nous avons entrepris dans ce document.

De même, ce document ne vise pas à énumérer les questions de recherche jugées comme étant uniquement d'importance périphérique, ni à examiner les voies actuelles (mondiales, gouvernementales, commerciales et universitaires) de financement de la recherche sur Internet, ni à faire des recommandations spécifiques sur quels domaines nécessitent un financement supplémentaire. Le but du document est de persuader le lecteur que des recherches continues sont nécessaires pour l'évolution continue de l'infrastructure Internet; le but n'est pas de faire des déclarations contraignantes sur les domaines spécifiques qui méritent et ne méritent pas un financement futur.

Pour certaines recherches clairement pertinentes pour l'évolution future de l'Internet, il existe de grandes controverses entre des propositions concurrentes ou des écoles de pensée concurrentes; le but de ce document n'est pas de prendre position sur ces controverses, ni de prendre position sur la nature des solutions pour des domaines nécessitant des recherches plus poussées.

Tout cela soigneusement noté, le reste de cette section traite d'un large ensemble de domaines de recherche, en notant un sous-ensemble de sujets particuliers d'intérêt dans chacun de ces domaines de recherche. Encore une fois, cette liste n'est PAS exhaustive, mais vise plutôt à suggérer qu'un large éventail de recherches en cours est nécessaire et à proposer des sujets candidats.

3.1.1. Terminologie

Plusieurs endroits de ce document font référence aux «opérateurs de réseau». Par ce terme, nous avons l'intention d'inclure toute personne ou toute organisation qui exploite un réseau IP; nous n'utilisons pas ce terme au sens étroit des fournisseurs de services de réseau commerciaux.

3.2. Appellation

Internet a actuellement plusieurs espaces de noms différents, y compris les adresses IP, les sockets (spécifiés par l'adresse IP, le protocole de couche supérieure et le numéro de port de couche supérieure), le numéro de système autonome (AS) et le nom de domaine complet (FQDN) . De nombreux espaces de noms Internet sont pris en charge par le système de noms de domaine largement déployé [RFC-3467] ou par diverses applications Internet [RFC-2407, section 4.6.2.1]

3.2.1. Système de noms de domaine (DNS)

Le système DNS, s'il fonctionne bien compte tenu de ses contraintes actuelles, présente plusieurs points de stress.

Le système DNS actuel repose sur UDP pour le transport, plutôt que sur SCTP ou TCP. Étant donné le très grand nombre de clients utilisant un serveur DNS classique, il est souhaitable de minimiser l'état du côté serveur DNS de la connexion. UDP le fait bien, c'est donc un choix raisonnable, bien que cela ait d'autres implications, par exemple une dépendance à la fragmentation UDP. Avec IPv6, la fragmentation intermédiaire n'est pas autorisée et Path MTU Discovery est obligatoire. Cependant, la quantité d'états requise pour déployer Path MTU Discovery pour IPv6 sur un serveur DNS peut être un problème pratique important.

Une implication de ceci est que la recherche sur des protocoles de transport alternatifs, conçus davantage pour des applications de type DNS où de très nombreux clients utilisent chaque serveur, pourrait être utile. Les protocoles de transport avec peu de charges pour le serveur DNS seraient particulièrement intéressants, même si cela augmentait quelque peu la charge pour le client DNS.

Une étude supplémentaire de la mise en cache DNS, à la fois des techniques de mise en cache actuellement disponibles et des nouvelles techniques de mise en cache potentielles, pourrait être utile pour trouver des moyens de réduire la charge offerte pour un serveur DNS typique. En particulier, l'examen de la mise en cache DNS via des pare-feu commerciaux typiques pourrait être intéressant s'il conduisait à des implémentations de pare-feu alternatives qui constituaient moins un obstacle à la mise en cache DNS.

La communauté ne dispose pas d'un ensemble de mesures largement accepté pour mesurer les performances du serveur DNS. Il serait utile que les gens réfléchissent sérieusement aux caractéristiques du système DNS à mesurer.

Certains membres de la communauté préconiseraient de remplacer le système DNS actuel par quelque chose de mieux. Les tentatives passées pour concevoir une meilleure approche n'ont pas donné de résultats qui ont persuadé la communauté de changer. Les travaux proposés dans ce domaine pourraient être très utiles, mais pourraient nécessiter un examen attentif pour éviter de tomber dans des écueils de conception historiques.

En ce qui concerne la sécurité DNS, les principales préoccupations techniques concernent la recherche de méthodes pratiques pour signer de très grandes zones DNS (par exemple, et des outils pour faciliter la gestion d'une infrastructure DNS sécurisée.

La plupart des utilisateurs sont incapables de distinguer une panne liée au DNS d'une panne de réseau plus générale. Par conséquent, le maintien de l'intégrité et de la disponibilité du système de noms de domaine est très important pour la santé future de l'Internet.

3.2.2. Nouveaux espaces de noms

De plus, le groupe de recherche sur les espaces de noms (NSRG) de l'Internet Research Task Force (IRTF) a étudié l'ajout d'un ou plusieurs espaces de noms supplémentaires à l'architecture Internet [LD2002]. De nombreux membres du NSRG de l'IRTF estiment qu'il y aurait un avantage architectural significatif à ajouter un ou plusieurs espaces de noms supplémentaires à l'architecture Internet. Parce qu'un consensus sans heurts sur cette question ou sur les propriétés d'un nouvel espace de noms n'a pas été obtenu, l'IRTF NSRG n'a pas fait de recommandation formelle à la communauté IETF concernant les espaces de noms. L'IAB estime qu'il s'agit d'une question de recherche ouverte qui mérite d'être approfondie.

Enfin, nous pensons que les recherches futures sur l'évolution de l'informatique distribuée basée sur Internet pourraient bien bénéficier de l'étude de l'ajout d'espaces de noms supplémentaires dans le cadre d'une nouvelle approche de l'informatique distribuée.

3.3. Routage

Le système de routage unicast actuellement déployé fonctionne raisonnablement bien pour la plupart des utilisateurs. Cependant, l'architecture de routage unicast actuelle est sous-optimale dans plusieurs domaines, dont les suivants: temps de convergence de bout en bout dans des catenets à l'échelle mondiale (un système de réseaux interconnectés via des passerelles); la capacité de l'algorithme de vecteur de chemin interdomaine existant à évoluer bien au-delà de 200 000 préfixes; la capacité du routage intra-domaine et inter-domaine à utiliser simultanément plusieurs métriques et plusieurs types de métriques; et la capacité d'IPv4 et d'IPv6 à prendre en charge le multi-homing de site étendu sans impact négatif indu sur le système de routage interdomaine. L'intégration de la politique dans le routage est également une préoccupation générale, à la fois pour le routage intra-domaine et inter-domaine. Dans de nombreux cas, la politique de routage est directement liée à des enjeux économiques pour les opérateurs de réseau,

Il s'agit d'un problème pour lequel l'intérêt commercial est clair, mais il semble peu probable qu'il soit résolu par le financement commercial de la recherche, en l'absence d'un consortium d'un type quelconque.

3.3.1. Routage interdomaine

Le système de routage interdomaine opérationnel actuel a entre 150 000 et 200 000 préfixes de routage dans la zone sans défaut (DFZ) [RFC-3221]. La technologie ASIC évite les inquiétudes concernant la capacité de transmettre des paquets à des vitesses très élevées. La technologie ASIC évite également les préoccupations concernant le temps nécessaire pour effectuer les calculs de correspondance de préfixe le plus long. Cependant, certains membres expérimentés de la communauté du routage Internet craignent que les propriétés de convergence de bout en bout de l'Internet mondial n'atteignent des limitations algorithmiques fondamentales (c'est-à-dire pas des limitations matérielles) lorsque la DFZ se situe entre 200 000 et 300 000 préfixes. La recherche pour savoir si cette préoccupation est fondée en termes scientifiques semble très opportune.

Indépendamment de la préoccupation ci-dessus, des travaux récents ont montré qu'il peut y avoir des problèmes de convergence BGP importants aujourd'hui. À l'heure actuelle, il semble que les problèmes de convergence actuellement observés concernent la façon dont BGP a été configuré par les opérateurs de réseau, plutôt que d'être une sorte de limitation algorithmique fondamentale [MGVK02]. Ce problème de temps de convergence rend la durée de la panne apparente du réseau beaucoup plus longue qu'elle ne devrait l'être. Des recherches appliquées supplémentaires sur les aspects d'une configuration BGP qui ont le plus fort impact sur les temps de convergence contribueraient à atténuer les problèmes opérationnels actuellement observés.

En outre, le routage interdomaine nécessite actuellement une ingénierie humaine importante de chemins inter-AS spécifiques pour garantir que des chemins raisonnablement optimaux sont utilisés par le trafic réel. Idéalement, le système de routage interdomaine entraînerait automatiquement le choix de chemins raisonnablement optimaux. Des travaux récents indiquent que des mécanismes de politique BGP améliorés pourraient aider à garantir que des chemins raisonnablement optimaux sont normalement utilisés pour le trafic IP interdomaine. [SMA03] La poursuite de la recherche appliquée dans ce domaine pourrait conduire à des approches techniques nettement meilleures.

L'approche actuelle du multi-homing de site a pour effet secondaire hautement indésirable d'augmenter significativement le taux de croissance des entrées de préfixes dans la DFZ (en altérant le déploiement de l'agrégation de préfixes). Des recherches sont nécessaires sur de nouvelles architectures de routage qui peuvent prendre en charge le multi-homing de site à grande échelle sans les impacts indésirables sur le routage inter-domaine de la technique actuelle de multi-homing.

L'application originale de BGP était dans le routage inter-domaines, principalement dans les réseaux de fournisseurs de services, mais aussi avec une certaine utilisation par des sites multi-hébergés. Cependant, certains essaient maintenant d'utiliser BGP dans d'autres contextes, par exemple des environnements très mobiles, où il est évidemment moins bien adapté. La recherche sur le routage inter-domaine et / ou le routage de politique intra-domaine pourrait conduire à d'autres approches pour tous les environnements émergents où l'approche BGP actuelle n'est pas la meilleure.

3.3.2. Intégrité du routage

Récemment, on a pris conscience du problème de longue date du déploiement d'une authentification forte dans le système de routage interdomaine Internet. Les mécanismes actuellement déployés (par exemple, BGP TCP MD5 [RFC-2385], OSPF MD5, RIP MD5 [RFC-2082]) fournissent une authentification cryptographique des messages de protocole de routage, mais aucune authentification des données de routage réelles. Des propositions récentes (par exemple, S-BGP [KLMS2000]) pour améliorer cela dans le routage inter-domaine semblent difficiles à déployer sur Internet, en partie à cause de leur dépendance à une seule hiérarchie de confiance (par exemple, une seule PKI). Des propositions similaires (par exemple, OSPF avec signatures numériques, [RFC-2154]) pour le routage intra-domaine sont soutenues comme étant irréalisables sur le plan informatique à déployer dans un grand réseau.

Un défi récurrent avec toute forme d'authentification de routage inter-domaines est qu'il n'y a pas de source de vérité unique et complètement exacte sur les organisations qui ont le pouvoir d'annoncer quels blocs d'adresses. Des approches alternatives d'authentification des données dans le système de routage doivent être développées. En particulier, la possibilité d'effectuer une authentification partielle des données de routage faciliterait le déploiement incrémentiel des mécanismes d'authentification de routage. En outre, la possibilité d'utiliser des modèles de confiance non hiérarchiques (par exemple, le réseau de confiance utilisé dans l'application PGP) pourrait faciliter le déploiement incrémentiel et pourrait résoudre les problèmes existants concernant l'administration centralisée du système de routage, ce qui mérite donc une étude et une considération supplémentaires.

3.3.3. Algorithmes de routage

Le système de routage Internet actuel repose principalement sur deux algorithmes. Le routage à l'état des liens utilise l'algorithme de Dijkstra [Dijkstra59]. Le routage à distance-vecteur (par exemple, RIP) et le routage à vecteur de chemin (par exemple, BGP) utilisent l'algorithme de Bellman-Ford [Bellman1957, FF1962]. Des recherches de base supplémentaires en cours sur la théorie des graphes appliquée au routage en valent la peine et pourraient produire des algorithmes qui permettraient une nouvelle architecture de routage ou apporteraient des améliorations au système de routage.

Le routage multicast actuellement déployé repose sur l'algorithme Deering RPF [Deering1988]. Les recherches en cours sur les algorithmes et protocoles de routage multicast alternatifs pourraient contribuer à atténuer les préoccupations actuelles concernant l'évolutivité du routage multicast.

Le système de routage Internet déployé suppose que le chemin le plus court est toujours le meilleur chemin. Ceci est prouvé faux, mais il s'agit d'un compromis raisonnable étant donné les protocoles de routage actuellement disponibles. L'Internet manque d'approches déployables pour le routage basé sur des politiques ou le routage avec des métriques alternatives (c'est-à-dire, certaines métriques autres que le nombre de sauts vers la destination). Des exemples de politiques alternatives comprennent: la voie avec le plus faible coût monétaire; le chemin avec la plus faible probabilité de perte de paquets; le chemin avec une gigue minimisée; et le chemin avec une latence minimisée. Les mesures de politique doivent également prendre en compte les relations commerciales.

La transition du système de routage inter-domaines actuel vers tout nouveau système de routage inter-domaines ne sera probablement pas un exercice trivial. Toute proposition de nouveau système de routage doit donc examiner et documenter attentivement les stratégies de déploiement, les mécanismes de transition et d'autres considérations opérationnelles. En raison de l'aspect d'interopérabilité interdomaine du routage interdomaine, des transitions fluides à partir d'un système de routage interdomaine seront probablement difficiles à réaliser. Par ailleurs, le système de routage interdomaine manque de forces du marché fortes qui encourageraient la migration vers de meilleures approches techniques. Par conséquent, il semble peu probable que le secteur commercial soit à l'origine d'un système de routage interdomaine considérablement amélioré.

3.3.4. Routage mobile et ad-hoc

Alors que certaines des premières recherches sur les réseaux parrainées par la DARPA impliquaient des réseaux radio par paquets, le routage mobile [IM1993] et le routage mobile ad hoc [RFC-2501] sont des arrivées relativement récentes sur Internet et ne sont pas encore largement déployés. Les approches actuelles ne sont pas le dernier mot dans aucun de ces domaines. Nous pensons que des recherches supplémentaires sur la prise en charge du routage pour les hôtes mobiles et les réseaux mobiles sont nécessaires. Des recherches supplémentaires sur les hôtes mobiles ad hoc et les réseaux mobiles valent également la peine. Idéalement, les capacités de routage mobile et de routage ad hoc mobile devraient être des capacités natives inhérentes à l'architecture de routage Internet. Cela nécessitera probablement une évolution significative de l'architecture de routage Internet existante. (NB: le terme «mobilité» tel qu'utilisé ici ne se limite pas aux téléphones mobiles, mais est plutôt défini de manière très large,

Cette rubrique comprend une grande variété de problèmes. La nature plus distribuée et dynamique des systèmes de routage partiellement ou totalement auto-organisés (y compris les nœuds d'extrémité associés) crée des défis de sécurité uniques (en particulier en ce qui concerne l'autorisation, l'authentification et la comptabilité, et la gestion des clés). L'évolutivité des réseaux sans fil peut être difficile à mesurer ou à réaliser. La hiérarchie forcée est une approche, mais peut être très limitative. Des approches alternatives moins contraignantes de l'évolutivité sans fil sont souhaitées. Étant donné que les protocoles de couche liaison sans fil ont généralement une certaine connaissance des caractéristiques de liaison actuelles telles que la qualité de la liaison, les conditions d'encombrement des sous-couches ou le comportement des canaux transitoires, il est souhaitable de trouver des moyens de laisser le routage de couche réseau utiliser ces données.

3.4. Sécurité

Internet a la réputation de ne pas avoir une sécurité suffisante. En fait, Internet dispose d'un certain nombre de mécanismes de sécurité normalisés, dont certains sont largement déployés. Cependant, il existe un certain nombre de questions de recherche ouvertes relatives à la sécurité Internet. En particulier, les mécanismes de sécurité doivent être déployables de manière incrémentielle et faciles à utiliser. "La technologie [de sécurité] doit être facile à utiliser, sinon elle ne sera pas configurée correctement. Si elle est mal configurée, la sécurité sera perdue, mais les choses" fonctionneront "" [Schiller03].

3.4.1. Méthodes formelles

Il existe un besoin permanent de financement de la recherche fondamentale relative à la sécurité Internet, y compris le financement de la recherche sur les méthodes formelles liées aux algorithmes, protocoles et systèmes de sécurité.

Par exemple, il serait avantageux d'avoir une étude plus formelle des modèles de confiance non hiérarchiques (par exemple, le modèle Web-of-Trust de PGP). L'utilisation d'un modèle de confiance hiérarchique peut créer des limitations significatives dans la façon dont on pourrait aborder la sécurisation des composants d'Internet, par exemple le système de routage interdomaine. Ainsi, la recherche pour développer de nouveaux modèles de confiance adaptés à Internet ou sur l'applicabilité des modèles de confiance non hiérarchiques existants aux problèmes Internet existants en vaudrait la peine.

Bien qu'il y ait eu des travaux sur l'application de méthodes formelles aux algorithmes cryptographiques et aux protocoles cryptographiques, les techniques existantes d'évaluation formelle des algorithmes et des protocoles manquent d'automatisation suffisante. Ce manque d'automatisation signifie que de nombreux protocoles ne sont pas officiellement évalués en temps opportun. Ceci est problématique pour Internet, car une évaluation formelle a souvent révélé de graves anomalies dans les protocoles cryptographiques. La création d'outils automatisés pour appliquer des méthodes formelles aux algorithmes et / ou protocoles cryptographiques serait très utile.

3.4.2. Gestion des clés

Un défi récurrent pour la communauté Internet est de savoir comment concevoir, mettre en œuvre et déployer une gestion des clés appropriée à la myriade de contextes de sécurité existant dans l'Internet mondial. La plupart des travaux actuels dans le domaine de la gestion des clés monodiffusion se sont concentrés sur des modèles de confiance hiérarchiques, car une grande partie du travail existant a été conduit par des modèles d'exploitation «descendants» d'entreprise ou militaires.

La rareté des méthodes de gestion des clés applicables aux modèles de confiance non hiérarchiques (voir ci-dessus) est une contrainte importante sur les approches qui pourraient être adoptées pour sécuriser les composants d'Internet.

Une recherche axée sur l'élimination de ces contraintes en développant des méthodes pratiques de gestion des clés applicables aux modèles de confiance non hiérarchiques serait très utile.

Les sujets méritant une recherche supplémentaire incluent les techniques de gestion de clés, telles que les architectures de gestion de clés non hiérarchiques (par exemple, pour prendre en charge des modèles de confiance non hiérarchiques; voir ci-dessus), qui sont utiles par les groupes ad hoc dans les réseaux mobiles et / ou l'informatique distribuée.

Bien que certains progrès aient été réalisés ces dernières années, la gestion évolutive des clés multicast est loin d'être un problème résolu. Les approches existantes de la gestion évolutive des clés multicast ajoutent des contraintes importantes sur la portée du problème afin de proposer une solution technique déployable. Une approche plus générale de la gestion évolutive des clés de multidiffusion (c'est-à-dire une approche plus large et moins contraignante) améliorerait les capacités d'Internet.

Dans de nombreux cas, la négociation d'attributs est une capacité importante d'un protocole de gestion de clé. L'expérience acquise à ce jour avec Internet Key Exchange (IKE) a montré qu'il est excessivement complexe. Une grande partie de la complexité d'IKE provient de ses capacités de négociation d'attributs très générales. Une nouvelle approche de gestion des clés qui prendrait en charge la négociation d'attributs importants sans créer de niveaux de déploiement et de complexité des opérations difficiles serait utile.

3.4.3. Cryptographie

Il existe un besoin permanent de poursuivre le financement de la recherche dans le monde ouvert dans les domaines de la cryptographie et de la cryptanalyse. La plupart des gouvernements concentrent leurs recherches cryptographiques sur le secteur militaire. Bien que cela soit compréhensible, ces efforts ont souvent peu (ou pas) de publications dans la littérature ouverte. Puisque la communauté d'ingénierie Internet doit travailler à partir de la littérature ouverte, il est important que la recherche sur le monde ouvert se poursuive à l'avenir.

3.4.4. Sécurité pour le calcul distribué

Le projet Athena du MIT était un projet de recherche important et largement réussi sur l'informatique distribuée. Le projet Athena a développé le système de sécurité Kerberos [RFC-1510], qui a aujourd'hui un déploiement important dans les environnements de campus. Cependant, Kerberos inter-royaume n'est ni aussi largement déployé ni perçu comme un succès aussi répandu que Kerberos à domaine unique. Le besoin d'une authentification utilisateur interdomaine évolutive est de plus en plus aigu à mesure que l'informatique ad hoc et l'informatique mobile sont de plus en plus largement déployées. Ainsi, travailler sur des mécanismes évolutifs pour l'authentification interdomaine mobile, ad hoc et non hiérarchique serait très utile.

3.4.5. Considérations de déploiement dans la sécurité

Beaucoup de travail a été fait sur une sécurité théoriquement parfaite qui est impossible à déployer. Malheureusement, la proposition S-BGP est un exemple de bon produit de recherche qui présente d'importants défis de déploiement non résolus. Il est loin d'être évident de savoir comment déployer S-BGP à grande échelle sans déployer auparavant une infrastructure à clé publique interdomaine à grande échelle et centraliser également l'application de la politique de publicité d'itinéraire dans les registres d'informations de routage ou un organisme similaire. Historiquement, les infrastructures à clé publique ont été soit très difficiles, soit impossibles à déployer à grande échelle. Les mécanismes de sécurité qui nécessitent une infrastructure supplémentaire n'ont pas été bien déployés. Nous avons désespérément besoin d'une sécurité générale, facile à installer et à gérer.

3.4.6. Protection contre le déni de service

Historiquement, la communauté Internet a pour la plupart ignoré les attaques par déni de service (DoS). Cela était approprié à un moment donné, car de telles attaques étaient rares et difficiles à défendre. Cependant, l'une des tendances récentes des logiciels antagonistes (par exemple, les virus, les vers) a été l'incorporation de fonctionnalités qui transforment l'hôte infecté en un «zombie». Ces zombies peuvent être contrôlés à distance pour monter une attaque de déni de service distribuée sur une machine victime. Dans de nombreux cas, les opérateurs autorisés de systèmes ne savent pas que certains ou tous leurs systèmes sont devenus des zombies. Il semble que la présence d'un nombre non négligeable de zombies sur l'Internet mondial soit désormais endémique, ce qui rend les attaques par déni de service distribuées une préoccupation beaucoup plus grande. Les modèles de menaces Internet doivent donc supposer la présence de tels zombies en nombre significatif. Cela rend la conception de protocoles résiliente en présence d'attaques de déni de service distribuées très importantes pour la santé d'Internet. Un certain travail a été fait sur ce front [Savage00], [MBFIPS01], mais il en faut davantage.

3.5. La gestion du réseau

Internet a connu un succès précoce dans la surveillance des périphériques réseau avec le protocole SNMP (Simple Network Management Protocol) et sa base d'informations de gestion (MIB) associée. La gestion des réseaux a été comparativement moins réussie, contrairement à la surveillance des appareils individuels. En outre, il existe un certain nombre d'exigences des opérateurs qui ne sont pas bien prises en charge par le cadre de gestion Internet actuel. Il est souhaitable d'améliorer l'architecture actuelle de gestion du réseau Internet afin de mieux répondre aux besoins opérationnels.

Malheureusement, la recherche sur la gestion de réseau a toujours été très sous-financée. Les opérateurs se sont plaints de l'insuffisance des solutions existantes. Des recherches sont nécessaires pour trouver de meilleures solutions.

3.5.1. Gérer les réseaux, pas les appareils

À l'heure actuelle, il existe peu ou pas de bons outils pour gérer un réseau entier au lieu d'appareils isolés. Par exemple, le manque d'outils de gestion de réseau appropriés a été cité comme l'un des principaux obstacles au déploiement généralisé de la multidiffusion IP [Diot00, SM03]. Les protocoles de gestion de réseau actuels, tels que le protocole SNMP (Simple Network Management Protocol), conviennent pour la lecture de l'état d'objets bien définis à partir de boîtes individuelles. La gestion de réseaux au lieu de périphériques isolés nécessite la possibilité de voir le réseau comme un grand système distribué. Des recherches sont nécessaires sur les mécanismes d'agrégation de données distribués évolutifs, les mécanismes de corrélation d'événements distribués évolutifs et les mécanismes de contrôle distribués et fiables.

La recherche appliquée sur les méthodes de gestion des ensembles d'appareils en réseau semble utile. Idéalement, une telle approche de gestion prendrait en charge la gestion distribuée, plutôt que d'être strictement centralisée.

3.5.2. Capacités de surveillance améliorées

SNMP ne s'adapte pas toujours bien à la surveillance d'un grand nombre d'objets dans de nombreux périphériques dans différentes parties du réseau. Une approche alternative qui mérite d'être explorée est de savoir comment fournir une surveillance évolutive et distribuée, non pas sur des appareils individuels, mais plutôt sur des groupes d'appareils et sur le réseau dans son ensemble. Cela nécessite des techniques évolutives d'agrégation de données et de corrélation d'événements des données d'état du réseau provenant de nombreux emplacements du réseau.

3.5.3. Gestion du réseau client

Un problème ouvert lié à la gestion du réseau est d'aider les utilisateurs et d'autres personnes à identifier et à résoudre les problèmes du réseau. Si un utilisateur ne peut pas accéder à une page Web, il serait utile que l'utilisateur puisse savoir, facilement, sans avoir à exécuter un ping et un traceroute, si le problème était que le serveur Web était en panne, que le réseau a été partitionné en raison d’un échec de liaison, qu'il y avait une forte congestion le long du chemin, que le nom DNS n'a pas pu être résolu, que le pare-feu a interdit l'accès ou qu'un autre événement spécifique s'est produit.

3.5.4. Gestion de réseau autonome===

Des recherches supplémentaires sont nécessaires pour améliorer le degré d'automatisation atteint par les systèmes de gestion de réseau et localiser la gestion. La gestion de réseau autonome peut impliquer l'application de la théorie du contrôle, de l'intelligence artificielle ou des technologies de système expert à des problèmes de gestion de réseau.

3.6. Qualité de service

Il y a eu un corpus intensif de recherche et développement sur l'ajout de la qualité de service à l'architecture Internet depuis plus de dix ans maintenant [RFC-1633, RFC-2474, RFC-3260, RFC-2205, RFC-2210], mais nous ne 'pas de QoS de bout en bout sur Internet [RFC-2990, RFC-3387]. L'IETF est bon pour définir les mécanismes de QoS individuels, mais médiocre au travail sur les architectures QoS déployables. Ainsi, alors que les mécanismes de services différenciés (DiffServ) ont été normalisés en tant que comportements par saut, il reste encore beaucoup à apprendre sur le déploiement de ce mécanisme ou d'autres mécanismes de qualité de service pour la qualité de service de bout en bout. En plus de travailler sur des questions purement techniques, cela inclut une attention particulière aux modèles économiques et aux stratégies de déploiement qui permettraient un déploiement accru de la QoS dans le réseau.

Dans de nombreux cas, le déploiement de mécanismes de qualité de service augmenterait considérablement les risques de sécurité opérationnelle [RFC-2990], de sorte que toute nouvelle recherche sur les mécanismes ou architectures de qualité de service devrait spécifiquement discuter des problèmes de sécurité potentiels associés à la ou aux nouvelles propositions et comment les atténuer. problèmes de sécurité.

Dans certains cas, la demande de mécanismes de qualité de service a été diminuée par le développement de techniques de codage voix / vidéo plus résilientes, mieux adaptées à l'Internet au meilleur effort que les anciennes techniques de codage conçues à l'origine pour les réseaux à commutation de circuits.

L'un des facteurs qui a émoussé la demande de QoS a été la transition de l'infrastructure Internet d'une forte congestion au début des années 1990 à une surprovisionnement des dorsales et de nombreuses liaisons internationales aujourd'hui. Ainsi, la recherche sur les mécanismes de QoS doit également inclure une attention particulière aux coûts et avantages relatifs de la QoS à différents endroits du réseau. La recherche appliquée sur la qualité de service devrait inclure une considération explicite des problèmes économiques liés au déploiement et à l'exploitation d'un réseau IP compatible avec la qualité de service [Clark02].

3.6.1. Architecture QoS inter-domaines

En règle générale, un routeur dans l'Internet interdomaine déployé fournit une transmission au mieux des paquets IP, sans se soucier du fait que la source ou la destination du paquet est un client direct de l'opérateur du routeur. Cette propriété contribue de manière significative à l'évolutivité actuelle de l'Internet mondial et contribue à la difficulté de déployer des mécanismes de qualité de service (QoS) interdomaines.

Le déploiement de mécanismes de qualité de service (QoS) existants, par exemple des services différenciés ou des services intégrés, à travers une frontière interdomaine crée une vulnérabilité de déni de service importante et facilement exploitable pour tout réseau qui fournit une prise en charge de la qualité de service interdomaine. Cela a conduit les opérateurs de réseau à s'abstenir de prendre en charge la qualité de service interdomaine. Internet bénéficierait de recherches supplémentaires sur des approches alternatives de la qualité de service, en particulier sur des approches qui ne créent pas de telles vulnérabilités et peuvent être déployées de bout en bout [RFC-2990].

En outre, les modèles commerciaux actuels ne sont pas cohérents avec la qualité de service interdomaine, en grande partie parce qu'il est impossible ou impossible d'authentifier l'identité de l'expéditeur du trafic potentiel préféré tout en acheminant le trafic au débit de ligne. En l'absence d'une telle capacité, on ne sait pas comment un opérateur de réseau pourrait facturer ou recouvrer autrement les coûts associés à la fourniture de ce service préféré. Ainsi, tout nouveau travail sur les mécanismes et architectures de QoS interdomaines doit examiner attentivement les implications économiques et sécuritaires de telles propositions.

3.6.2. Nouvelles disciplines de mise en file d'attente

La qualité de service globale du trafic est en partie déterminée par les mécanismes de planification et de gestion des files d'attente au niveau des routeurs. Bien qu'il existe un certain nombre de mécanismes existants (par exemple, RED) qui fonctionnent bien, il est possible que des stratégies améliorées de mise en file d'attente active soient conçues. Les mécanismes qui réduisent le coût de mise en œuvre dans les routeurs IP peuvent aider à accroître le déploiement de la gestion active des files d'attente, par exemple.

3.7. Contrôle de la congestion.

Les mécanismes d'évitement de congestion et de contrôle de TCP, à partir de 1988 [Jacobson88], ont été un facteur clé dans le maintien de la stabilité d'Internet et sont utilisés par la majeure partie du trafic Internet. Cependant, les mécanismes de contrôle de la congestion d'Internet doivent être étendus et modifiés pour répondre à un large éventail de nouvelles exigences, des nouvelles applications telles que le streaming multimédia et la multidiffusion aux nouveaux environnements tels que les réseaux sans fil ou les chemins à très haut débit, et les nouvelles exigences pour minimiser le délai de mise en file d'attente. Bien qu'il existe des travaux importants sur plusieurs de ces questions, il reste encore beaucoup à faire.

Nous notons que la recherche sur le contrôle de la congestion TCP n'est pas encore "terminée", avec beaucoup à faire dans le TCP à haut débit, ou dans l'ajout de performances robustes sur des chemins avec une réorganisation significative, une connectivité intermittente, une perte de paquets non congestive, et le semblable.

Plusieurs de ces problèmes soulèvent des questions fondamentales difficiles sur les coûts et avantages potentiels d'une communication accrue entre les couches. Cela aiderait-il le transport à recevoir des indices ou d'autres informations du routage, des couches de liaison ou d'autres connexions de niveau transport? Dans l'affirmative, quel serait le coût d'un fonctionnement robuste dans divers environnements?

Pour les mécanismes de contrôle de congestion dans les routeurs, la gestion active des files d'attente et la notification explicite de congestion ne sont généralement pas encore déployées, et il existe une gamme de propositions, dans divers états de maturité, dans ce domaine. Dans le même temps, il y a beaucoup de choses que nous ne comprenons toujours pas sur les interactions des mécanismes de gestion des files d'attente avec d'autres facteurs du réseau. Des mécanismes de contrôle de la congestion basés sur les routeurs sont également nécessaires pour détecter et répondre à la congestion globale, comme dans les attaques de déni de service distribué et les foules flash.

Étant donné que de plus en plus d'applications ont besoin de transférer des fichiers très volumineux sur des chemins de produits à bande passante à fort retard, les contraintes sur les mécanismes actuels de contrôle de la congestion soulèvent la question de savoir si nous avons besoin d'un retour plus fin des routeurs. Cela inclut le défi de permettre aux connexions d'éviter les retards de démarrage lent et d'utiliser rapidement la bande passante nouvellement disponible. À un niveau plus général, nous ne comprenons pas le potentiel et les limites du trafic au mieux sur les chemins de produits à bande passante à haut retard, étant donné les commentaires actuels des routeurs, ou la gamme de possibilités pour des commentaires plus explicites des routeurs.

Il existe également un besoin de recherche à long terme sur le contrôle de la congestion, distincte des exigences fonctionnelles spécifiques telles que celles énumérées ci-dessus. Nous en savons très peu sur la dynamique du contrôle de la congestion ou la dynamique du trafic d'un grand réseau complexe comme l'Internet mondial, avec ses mélanges de trafic hétérogènes et changeants, ses technologies de niveau de liaison, ses protocoles de réseau et ses mécanismes de routeur, ses modèles de congestion, ses modèles de tarification et les comme. L'élargissement de nos connaissances dans ce domaine semble nécessiter un riche mélange de mesures, d'analyses, de simulations et d'expérimentation.

3.8. Étudier l'évolution de l'infrastructure Internet

L'évolution de l'infrastructure Internet a été extrêmement lente et difficile, avec de longues histoires sur les difficultés d'ajout d'IPv6, de QoS, de multidiffusion et d'autres fonctionnalités à Internet. Nous avons besoin d'une compréhension plus scientifique des potentiels d'évolution et des difficultés d'évolution de l'infrastructure Internet.

Ce potentiel évolutif est affecté non seulement par les problèmes techniques de l'architecture IP en couches, mais également par d'autres facteurs. Ces facteurs comprennent les changements dans l'environnement au fil du temps (par exemple, le surapprovisionnement récent des dorsales, le déploiement de pare-feu) et le rôle du processus de normalisation. Les facteurs économiques et de politique publique sont également critiques, y compris le fait central d'Internet en tant que système décentralisé, les principaux acteurs étant non seulement les individus, mais également les FAI, les entreprises et des industries entières. Les problèmes de déploiement sont également des facteurs clés de l'évolution d'Internet, y compris le problème continu de la poule et de l'œuf d'avoir suffisamment de clients pour mériter le déploiement d'un service dont l'utilité dépend en premier lieu de la taille de la clientèle.

Les réseaux de superposition peuvent servir de technologie de transition pour certaines nouvelles fonctionnalités, avec un déploiement initial dans des réseaux de superposition, et avec la nouvelle fonctionnalité se déplaçant plus tard dans le noyau si cela semble justifié.

Il y a aussi des obstacles accrus à l'évolution d'Internet sous la forme d'une complexité accrue [WD02], d'interactions de caractéristiques imprévues [Kruse00], d'interactions entre couches [CWWS92], d'interventions par des boîtiers de médiation [RFC-3424], etc. Parce qu'une complexité croissante semble inévitable, des recherches sont nécessaires pour comprendre les mécanismes architecturaux qui peuvent s'adapter à une complexité accrue sans diminuer la robustesse des performances dans des environnements inconnus, et sans fermer les futures possibilités d'évolution. Plus concrètement, des recherches sont nécessaires pour savoir comment faire évoluer Internet et conservera ses atouts fondamentaux, tels que le degré actuel d'adressabilité globale des hôtes, la transparence de bout en bout du transfert de paquets et de bonnes performances pour le trafic au mieux.

3.9. Boîtes médianes

Des recherches sont nécessaires pour relever les défis posés par la large gamme de boîtiers de médiation [RFC-3234]. Cela inclut les problèmes de sécurité, de contrôle, d'intégrité des données et de l'impact général des boîtiers de médiation sur l'architecture.

À bien des égards, les boîtiers de médiation sont une conséquence directe des intérêts commerciaux, mais il est nécessaire de regarder au-delà des besoins à court terme de la technologie, de rechercher ses implications plus larges et d'explorer des moyens d'améliorer la façon dont les boîtiers de médiation sont intégrés dans l'architecture.

3.10. Mesure Internet

Un défi récurrent consiste à mesurer Internet; il y a eu de nombreuses discussions sur la nécessité d'études de mesure comme partie intégrante de la recherche sur Internet [Claffy03]. Dans cette discussion, nous définissons la mesure de manière assez large. Par exemple, il existe de nombreux défis dans la mesure des performances le long d'un chemin Internet important, en particulier lorsque le chemin traverse les limites du domaine administratif. Il existe également des défis dans la mesure de l'utilisation des protocoles / applications sur toute liaison Internet à haut débit. Bon nombre des problèmes évoqués ci-dessus bénéficieraient d'une fréquence accrue de mesure ainsi que d'une meilleure qualité de mesure sur l'Internet déployé.

Un problème clé dans la mesure du réseau est que la plupart des fournisseurs de services Internet commerciaux considèrent les caractéristiques particulières de leur (s) réseau (s) IP de production comme des secrets commerciaux. Des moyens doivent être trouvés pour des études de mesure coopératives, par exemple, pour permettre aux chercheurs non commerciaux légitimes d'être en mesure de mesurer les paramètres de réseau pertinents tout en protégeant également les droits à la vie privée des FAI mesurés.

En l'absence de données mesurées, il existe peut-être une dépendance excessive aux simulations de réseau dans certaines parties de la communauté de recherche sur Internet et une validation probablement insuffisante du fait que les modèles de simulation de réseau existants sont des représentations raisonnablement bonnes de l'Internet déployé (ou d'un futur Internet plausible) [FK02] .

Sans une mesure solide du comportement actuel d'Internet, il est très difficile de savoir quels problèmes opérationnels autrement inconnus existent qui nécessitent une attention, et il est également difficile de comprendre pleinement l'impact des changements (passés ou futurs) sur les caractéristiques comportementales réelles d'Internet.

3.11. Applications

Des recherches sont nécessaires sur un large éventail de questions liées aux applications Internet.

En prenant le courrier électronique comme exemple d'application, des recherches sont nécessaires pour comprendre le problème du spam et pour étudier les outils et techniques permettant d'atténuer les effets du spam, y compris les outils et techniques qui facilitent la mise en œuvre de mesures anti-spam légales et non techniques [ASRG ]. «Spam» est un terme générique désignant une gamme de types très différents de courriers électroniques indésirables, avec de nombreux types d'expéditeurs, de contenu et de techniques de génération de trafic. Dans le cadre du contrôle du spam, nous devons développer une bien meilleure compréhension de ses nombreuses caractéristiques différentes et de leurs interactions les unes avec les autres.

3.12. Répondre aux besoins du futur

À mesure que la taille du réseau, la bande passante de la liaison, la capacité du processeur et le nombre d'utilisateurs augmentent, des recherches seront nécessaires pour garantir que l'Internet du futur évolue pour répondre à ces demandes croissantes. Nous avons discuté de certains de ces problèmes de mise à l'échelle dans des sections spécifiques ci-dessus.

Cependant, pour toutes les questions de recherche abordées dans ce document, le but de la recherche doit être non seulement de relever les défis déjà rencontrés aujourd'hui, mais aussi de relever les défis que l'on peut s'attendre à voir émerger à l'avenir.

3.13. Prototypes librement distribuables

La DARPA américaine a historiquement financé le développement d'implémentations librement distribuables de diverses technologies Internet (par exemple, TCP / IPv4, RSVP, IPv6 et sécurité IP) dans une variété de systèmes d'exploitation (par exemple, 4.2 BSD, 4.3 BSD, 4.4 BSD, Tenex). L'expérience a montré qu'un bon moyen d'accélérer le déploiement d'une nouvelle technologie est de fournir un prototype libre et librement distribuable qui peut être incorporé dans des produits commerciaux ainsi que dans des prototypes non commerciaux. Le projet WIDE du Japon a également financé certains de ces travaux, principalement axés sur la mise en œuvre d'IPv6 pour 4.4 BSD et Linux. [WIDE] Nous pensons que les projets de recherche appliquée en réseautage auront une probabilité accrue de succès si les équipes de projet de recherche rendent les implémentations logicielles qui en résultent librement disponibles pour des utilisations commerciales et non commerciales.

4. Conclusions

Ce document a résumé l'historique du financement de la recherche sur Internet et a mis en évidence des exemples de questions de recherche ouvertes. L'IAB estime que des recherches supplémentaires sont nécessaires pour faire avancer l'évolution de l'infrastructure Internet et qu'un financement non commercial suffisant et cohérent est nécessaire pour permettre une telle recherche.

En cas de confusion, dans ce document, nous ne suggérons aucun rôle direct ou indirect pour l'IAB, l'IETF ou l'IRTF dans la gestion de tout financement de la recherche sur Internet.

5. Remerciements

Les personnes qui ont directement contribué à ce document sous une forme ou une autre sont les suivantes: Ran Atkinson, Guy Almes, Rob Austein, Vint Cerf, Jon Crowcroft, Sally Floyd, James Kempf, Joe Macker, Craig Partridge, Vern Paxson, Juergen Schoenwaelder et Mike St. John's.

Nous remercions également Kim Claffy, Dave Crocker, Michael Eder, Eric Fleischman, Andrei Gurtov, Stephen Kent, JP Martin-Flatin et Hilarie Orman pour leurs commentaires sur les versions antérieures de ce document.

Nous nous sommes également inspirés des rapports suivants: [CIPB02, IST02, NV02, NSF02, NSF03, NSF03a].

6. Considérations relatives à la sécurité

Ce document ne crée pas en lui-même de nouveaux problèmes de sécurité pour la communauté Internet. Les problèmes de sécurité au sein de l'architecture Internet sont principalement traités dans la section 3.4 ci-dessus.

7. Références informatives

[ASRG] Groupe de recherche anti-spam (ASRG) de l'IRTF. URL " http://asrg.sp.am/ ".

[Atk96] R. Atkinson et al., "Implementation of IPv6 in 4.4 BSD", Actes de la conférence technique annuelle USENIX 1996, Association USENIX, Berkeley, Californie, USA. Janvier 1996. URL http://www.chacs.itd.nrl.navy.mil/publications/CHACS/ 1996 / 1996atkinson-USENIX.pdf

[Bellman1957] RE Bellman, "Programmation dynamique", Princeton University Press, Princeton, NJ, 1957.

[Claffy03] K. Claffy, "Priorities and Challenges in Internet Measurement, Simulation, and Analysis", réunion du réseau à grande échelle, (États-Unis) National Science Foundation, Arlington, VA, États-Unis. 10 juin 2003. URL « http://www.caida.org/outreach/ présentations / 2003 / lsn20030610 /».

[Claffy03a] K. Claffy, "Top Problems of the Internet and What Sysadmins and Researchers Can Do To Help", conférence plénière à LISA'03, octobre 2003. URL " http://www.caida.org/outreach/presentations/ 2003 / netproblems_lisa03 / ".

[Clark02] DD Clark, "Deploying the Internet - why does it take so long and, can research help?", Large-Scale Networking Distinguished Lecture Series, (US) National Science Foundation, Arlington, VA, 8 janvier 2002. URL: http: //www.ngi- supernet.org/conferences.html

[CSTB99] Computer Science and Telecommunications Board, (États-Unis) National Research Council, "Funding a Revolution: Government Support for Computing Research", National Academy Press, Washington, DC, 1999. URL " http://www7.nationalacademies.org/ cstb / pub_revolution.html ".

[CIPB02] Critical Infrastructure Protection Board, "Stratégie nationale pour sécuriser le cyberespace", La Maison Blanche, Washington, DC, USA. Septembre 2002, URL " http://www.whitehouse.gov/pcipb ".

[CWWS92] J. Crowcroft, I. Wakeman, Z. Wang et D. Sirovica, "Is Layering Harmful?", IEEE Networks, Vol. 6, numéro 1, pp 20-24, janvier 1992.

[Diot00] C. Diot, et al., «Deployment Issues for the IP Multicast Service and Architecture», IEEE Network, janvier / février 2000.

[Deering1988] S. Deering, "Multicast Routing in Internetworks and LANs", ACM Computer Communications Review, volume 18, numéro 4, août 1988.

[Dijkstra59] E. Dijkstra, "Une note sur deux problèmes de connexion avec les graphes", Numerische Mathematik, 1, 1959, pp.269-271.

[FF1962] LR Ford Jr. et DR Fulkerson, "Flows in Networks", Princeton University Press, Princeton, NJ, 1962.

[FK02] S. Floyd et E. Kohler, "Internet Research Needs Better Models", Actes du 1er atelier sur les sujets d'actualité dans les réseaux (Hotnets-I), Princeton, NJ, USA. Octobre 2002. URL " http://www.icir.org/models/bettermodels.html ".

[IM1993] J. Ioannidis et G. Maguire Jr., "The Design and Implementation of a Mobile Internetworking Architecture", Actes de la Winter USENIX Technical Conference, pages 489-500, Berkeley, CA, USA, janvier 1993.

[IST02] Réseau de recherche en Europe - Lutte pour un leadership mondial, technologies de la société de l'information, 2002. URL " http://www.cordis.lu/ist/rn/rn-brochure.htm ".

[Jacobson88] Van Jacobson, "Congestion Evitement and Control", Actes du Symposium ACM SIGCOMM 1988, ACM SIGCOMM, Stanford, CA, août 1988. URL " http://citeseer.nj.nec.com/jacobson88congestion.html ".

[Jackson02] William Jackson, "Les États-Unis devraient financer la R&D pour des protocoles Internet sécurisés, dit Clarke", Government Computer News, 31 October 2002. URL " http://www.gcn.com/vol1_no1/security/20382-1.html " .

[Kruse00] Hans Kruse, "The Pitfalls of Distributed Protocol Development: Unintentional Interactions between Network Operations and Applications Protocols", Actes de la 8e Conférence internationale sur la conception des systèmes de télécommunication, Nashville, TN, États-Unis, mars 2000. URL " http: // www.csm.ohiou.edu/kruse/publications/ TSYS2000.pdf ".

[KLMS2000] S. Kent, C. Lynn, J. Mikkelson et K. Seo, "Secure Border Gateway Protocol (S-BGP)", Proceedings of ISOC Network and Distributed Systems Security Symposium, Internet Society, Reston, VA, février 2000.

[LD2002] E. Lear et R. Droms, "Ce qui est dans un nom: pensées du NSRG", expiré Internet-Draft, décembre 2002.

[MBFIPS01] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson et Scott Shenker, «Controlling High Bandwidth Aggregates in the Network», ACM Computer Communications Review, Vol. 32, n ° 3, juillet 2002. URL " http://www.icir.org/pushback/ ".

[MBKQ96] M. McKusick, K. Bostic, M. Karels et J. Quarterman, "Conception et mise en œuvre du système d'exploitation 4.4 BSD", Addison-Wesley, Reading, MA, 1996.

[MGVK02] Z. Mao, R. Govindan, G. Varghese et R. Katz, «Route Flap Dampening Exacerbates Internet Routing Convergence», Proceedings of ACM SIGCOMM 2002, ACM, Pittsburgh, PA, USA, août 2002.

[NV02] Commission NetVision 2012, «Plan stratégique décennal de la DARPA pour la recherche en réseau», (États-Unis) Defense Advanced Research Projects Agency, October 2002. Citation à des fins de remerciement uniquement.

[NSF02] NSF Workshop on Network Research Testbeds, National Science Foundation, Directorat for Computer and Information Science & Engineering, Advanced Networking Infrastructure & Research Division, Arlington, VA, USA, October 2002. URL " http: // www- net.cs .umass.edu / testbed_workshop / ".

[NSF03] Réunion des chercheurs principaux NSF ANIR, National Science Foundation, Arlington, VA, États-Unis. 9-10 janvier 2003, URL " http://www.ncne.org/training/nsf- pi / 2003 / nsfpimain.html".

[NSF03a] DE Atkins, et al., «Revolutionizing Science and Engineering Through Cyberinfrastructure», rapport du NSF Advisory Panel on Cyberinfrastructure, janvier 2003. URL « http://www.cise.nsf.gov/evnt/reports/ atkins_annc_020303. htm ".

[NSF03b] Rapport de l'atelier de la National Science Foundation sur la recherche fondamentale en réseautage. 24-25 avril 2003. URL " http://www.cs.virginia.edu/~jorg/workshop1/NSF- NetWorkshop-2003.pdf".

[Floyd] S. Floyd, "Papers about Research Questions for the Internet", page Web, ICSI Center for Internet Research (ICIR), Berkeley, Californie, 2003 URL " http://www.icir.org/floyd/research_questions. html ".

[RFC-1510] Kohl, J. et C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510 , septembre 1993.

[RFC-1633] Braden, R., Clark, D. et S. Shenker, «Services intégrés dans l'architecture Internet: une vue d'ensemble», RFC 1633 , juin 1994.

[RFC-2082] Baker, F. et R. Atkinson, "Authentification RIP-2 MD5", RFC 2082 , janvier 1997.

[RFC-2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210 , septembre 1997.

[RFC-2154] Murphy, S., Badger, M. et B. Wellington, «OSPF avec signatures numériques», RFC 2154 , juin 1997.

[RFC-2385] Heffernan, A., «Protection des sessions BGP via l'option de signature TCP MD5», RFC 2385 , août 1998.

[RFC-2407] Piper, D., "Le domaine d'interprétation de la sécurité IP Internet pour ISAKMP", RFC 2407 , novembre 1998.

[RFC-2501] Corson, S. et J. Macker, «Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations», RFC 2501 , janvier 1999.

[RFC-2990] Huston, G., «Next Steps for the IP QoS Architecture», RFC 2990 , novembre 2000.

[RFC-3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221 , décembre 2001.

[RFC-3234] Carpenter, B. et S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234 , février 2002.

[RFC-3424] Daigle, L. et IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424 , novembre 2002.

[RFC-3467] Klensin, J., «Role of the Domain Name System (DNS)», RFC 3467 , février 2003.

[RFC-3535] Schoenwaelder, J., «Overview of the 2002 IAB Network Management Workshop», RFC 3535 , mai 2003.

[RFC-3387] Eder, M., Chaskar, H., et S. Nag, «Considérations du Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network», RFC 3387 , septembre 2002.

[RIPE] RIPE (Reseaux IP Europeens), Amsterdam, Pays-Bas. URL " http://www.ripe.net/ripe/ ".

[Savage00] Savage, S., Wetherall, D., Karlink, AR et Anderson, T., "Practical Network Support for IP Traceback", Actes de la conférence 2000 ACM SIGCOMM, ACM SIGCOMM, Stockholm, SE, pp. 295- 306. Août 2000.

[Schiller03] JI Schiller, "Interception Technology: The Good, The Bad, and The Ugly!", Présentation à la 28e réunion NANOG, North American Network Operators Group (NANOG), Ann Arbor, MI, États-Unis, juin 2003. URL " http : //www.nanog.org/mtg-0306/schiller.html ".

[SM03] P. Sharma et R. Malpani, "IP Multicast Operational Network Management: Design, Challenges, and Experiences", IEEE Network, Vol. 17, n ° 2, mars 2003.

[SMA03] N. Spring, R. Mahajan et T. Anderson, «Quantifying the Causes of Path Inflation», Actes de ACM SIGCOMM 2003, ACM, Karlsruhe, Allemagne, août 2003.

[WD02] Walter Willinger et John Doyle, «Robustness and the Internet: Design and Evolution», non publié / Preprint, 1er mars 2002, URL « http://netlab.caltech.edu/internet/ ».

[WIDE] Projet WIDE, Japon. URL " http://www.wide.ad.jp/ ".

8. Adresses des auteurs

Conseil d'architecture Internet
Courriel: iab@iab.org
Membres du conseil d'administration de l'architecture Internet
au moment de la publication de ce document étaient:
Bernard Aboba
Harald Alvestrand (président de l'IETF)
Rob Austein
Leslie Daigle (présidente de l'IAB)
Patrik Faltstrom
Sally Floyd
Mark Handley
Bob Hinden
Geoff Huston (directeur exécutif de l'IAB)
Jun-ichiro Itojun Hagino
Eric Rescorla
Pete Resnick
Jonathan Rosenberg

Nous notons que Ran Atkinson, l'un des éditeurs du document, était membre de l'IAB au moment de la création de ce document, en novembre 2002, et que Vern Paxson, le président de l'IRTF, est membre d'office de l'IAB. .

Déclaration de droit d'auteur complète

Copyright (C) L'Internet Society (2004). Ce document est soumis aux droits, licences et restrictions contenus dans BCP 78, et sauf indication contraire, les auteurs conservent tous leurs droits.

Ce document et les informations qu'il contient sont fournis «TELS QUELS» et LE CONTRIBUTEUR, L'ORGANISATION QU'IL / S IL / S IL REPRÉSENTE OU EST PARRAINÉ PAR (LE CAS ÉCHÉANT), LA SOCIÉTÉ INTERNET ET LE GROUPE DE TRAVAIL D'INGÉNIERIE INTERNET DÉCLINENT TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS, MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DES INFORMATIONS CI-DESSUS NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.

Propriété intellectuelle

L'IETF ne prend aucune position concernant la validité ou la portée des droits de propriété intellectuelle ou d'autres droits qui pourraient être revendiqués comme se rapportant à la mise en œuvre ou à l'utilisation de la technologie décrite dans ce document ou la mesure dans laquelle une licence en vertu de ces droits pourrait ou non être disponible; il ne prétend pas non plus avoir fait un effort indépendant pour identifier de tels droits. Des informations sur les procédures de l'IETF en ce qui concerne les droits dans les documents de l'IETF peuvent être trouvées dans BCP 78 et BCP 79.

Des copies des divulgations de DPI faites au Secrétariat de l'IETF et toute assurance de licences à rendre disponibles, ou le résultat d'une tentative faite pour obtenir une licence générale ou une autorisation pour l'utilisation de ces droits de propriété par les implémenteurs ou les utilisateurs de cette spécification peuvent être obtenues à partir du référentiel IPR en ligne de l'IETF à l' adresse http://www.ietf.org/ipr .

L'IETF invite toute partie intéressée à porter à son attention tous les droits d'auteur, brevets ou demandes de brevet, ou autres droits de propriété qui peuvent couvrir la technologie qui pourrait être nécessaire pour mettre en œuvre cette norme. Veuillez adresser les informations à l'IETF à l'adresse ietf- ipr@ietf.org.

Reconnaissance

Le financement de la fonction d'édition RFC est actuellement assuré par l'Internet Society. Demande de commentaires du groupe de travail du réseau : 3869
Catégorie: Information
Internet Architecture Board

Août 2004

Préoccupations et recommandations de l'IAB

concernant la recherche et l'évolution sur Internet
R. Atkinson, Ed.
'S. Floyd, éd.
</center>

Statut de ce mémo 
Ce mémo fournit des informations à la communauté Internet. Il ne spécifie aucune norme Internet d'aucune sorte. La distribution de ce mémo est illimitée.
Copyright 
Copyright (C) L'Internet Society (2004).
Abstrait 
Ce document discute des préoccupations de l'IAB selon lesquelles des recherches en cours sont nécessaires pour poursuivre l'évolution de l'infrastructure Internet et qu'un financement non commercial suffisant et cohérent est nécessaire pour permettre une telle recherche.



1. Introduction

Ce document traite de l'historique du financement de la recherche sur Internet, exprime des inquiétudes concernant l'état actuel de ce financement et décrit plusieurs domaines spécifiques qui, selon l'IAB, méritent des recherches supplémentaires. Les niveaux de financement actuels de la recherche sur Internet ne sont généralement pas adéquats et plusieurs domaines de recherche importants sont considérablement sous-financés. Cette situation doit être corrigée pour qu'Internet poursuive son évolution et son développement.

1.1. Organisation des documents

La première partie du document est une discussion de haut niveau sur l'historique du financement de la recherche sur Internet afin de fournir un contexte historique à ce document. Le financement initial de la recherche sur Internet provenait en grande partie du gouvernement américain, suivi par une période dans la seconde moitié des années 90 de financement commercial et de financement de plusieurs gouvernements. Cependant, le financement commercial de la recherche sur Internet a été réduit en raison du récent ralentissement économique.

La deuxième partie du document fournit un ensemble incomplet de sujets de recherche ouverts sur Internet. Ce ne sont que des exemples destinés à illustrer l'ampleur des sujets de recherche ouverts. Cette deuxième section soutient la thèse générale selon laquelle des recherches en cours sont nécessaires pour faire avancer l'évolution de l'infrastructure Internet. Cela comprend la recherche sur l'évolution à moyen terme de l'infrastructure Internet ainsi que la recherche sur les grands défis à plus long terme. Cela comprend également de nombreuses questions de recherche qui sont déjà activement étudiées dans la communauté de recherche Internet.

Les domaines abordés dans cette section sont les suivants: dénomination, routage, sécurité, gestion du réseau et transport. Les problèmes qui nécessitent plus de recherche comprennent également des problèmes d'architecture plus généraux tels que la superposition et la communication entre les couches. En outre, les sujets généraux abordés dans cette section comprennent la modélisation, la mesure, la simulation, les bancs d'essai, etc. Nous nous concentrons sur des sujets liés aux agendas de l'IETF et de l'IRTF (Internet Research Task Force). (Par exemple, les problèmes de Grid ne sont pas abordés dans ce document, car ils sont traités par le biais du Global Grid Forum et d'autres organisations spécifiques au Grid, pas dans l'IETF.)

Dans la mesure du possible, les exemples de ce document renvoient à des documents séparés sur ces questions et ne donnent qu'un résumé de haut niveau des questions soulevées dans ces documents.

1.2. Préoccupations de l'IAB

Au lendemain du 11 septembre 2001, les gouvernements semblent s'intéresser de nouveau au financement de la recherche sur les problèmes de sécurité liés à Internet. De [Jackson02]: "Il est généralement admis que la sécurité et la fiabilité des protocoles de base sous-jacents à Internet n'ont pas reçu suffisamment d'attention parce que personne n'y a un intérêt propriétaire".

Cette citation met en évidence un problème clé dans le financement de la recherche sur Internet, à savoir qu'aucune organisation unique (par exemple, aucun gouvernement, aucun éditeur de logiciels, aucun fournisseur d'équipement ou opérateur de réseau) n'a le sentiment de s'approprier l'infrastructure Internet mondiale, la recherche sur les problèmes généraux de l'infrastructure Internet ne sont souvent pas suffisamment financés. Dans notre climat économique difficile actuel, il n'est pas surprenant que les sources de financement commerciales soient plus susceptibles de financer cette recherche qui mène à un avantage concurrentiel direct.

La thèse principale de ce document est que si le financement commercial est la principale source de financement des futures recherches sur Internet, l'avenir de l'infrastructure Internet pourrait être en difficulté. En plus des questions sur les projets financés, la source de financement peut également affecter le contenu de la recherche, par exemple, en faveur ou contre le développement de normes ouvertes, ou en se souciant à divers degrés de l'effet des protocoles développés sur les autres trafic sur Internet.

Dans le même temps, de nombreuses contributions importantes à la recherche dans le domaine du réseautage proviennent de financements commerciaux. Cependant, pour la plupart des sujets abordés dans ce document, se fier uniquement à la recherche financée commercialement ne serait pas suffisant. Une grande partie du financement commercial actuel est axée sur la transition technologique, en prenant les résultats de la recherche non commerciale et en les intégrant à l'expédition de produits commerciaux. Nous n'avons pas essayé d'approfondir chacune des questions de recherche ci-dessous pour discuter, pour chaque question, du potentiel et des limites du financement commercial de la recherche dans ce domaine.

Sur une note plus pratique, s'il n'y avait pas de financement commercial pour la recherche sur Internet, alors peu de projets de recherche seraient menés à terme avec des mises en œuvre, un déploiement et une évaluation de suivi.

S'il est théoriquement possible qu'il y ait trop de financement pour la recherche sur Internet, c'est loin d'être le problème actuel. Il y a aussi beaucoup à faire au sein de la communauté de recherche du réseau pour rendre la recherche Internet plus ciblée et plus productive, mais cela ferait partie d'un document distinct.

1.3. Contributions à ce document

Un certain nombre de personnes ont directement contribué au texte de ce document, même si, conformément aux conventions actuelles, la liste officielle des auteurs RFC ne comprend que les principaux éditeurs du document. La section Remerciements à la fin du document remercie les autres personnes qui ont contribué à ce document sous une forme ou une autre.

2. Historique de la recherche sur Internet et du financement de la recherche

2.1. Avant 1980

La plupart des premières recherches sur les réseaux à commutation de paquets ont été financées par la US Defense Advanced Research Projects Agency (DARPA) [CSTB99]. Cela comprend la conception initiale, la mise en œuvre et le déploiement de l'ARPAnet reliant plusieurs universités et autres entrepreneurs de la DARPA. L'ARPAnet a été mis en ligne à la fin des années 1960. Il a pris de l'ampleur au cours des années 1970, toujours principalement grâce au financement de la DARPA, et a démontré l'utilité du réseau à commutation de paquets.

Le financement de la DARPA pour la conception Internet a commencé en 1973, quatre ans seulement après le déploiement initial d'ARPAnet. Le soutien à la conception d’Internet était l’un des résultats du financement antérieur de la DARPA pour la recherche sur la radio par paquets et les satellites par paquets. L'existence de plusieurs réseaux (ARPAnet, radio par paquets et satellite par paquets) a conduit à la recherche d'interréseaux. Internet est né dans une large mesure à la suite du financement de la recherche DARPA pour ces trois réseaux - et ne résulte qu'incidemment des travaux financés par Xerox PARC sur Ethernet.

2.2. Années 1980 et début des années 1990

L'ARPAnet est passé au protocole Internet (IP) le 1er janvier 1983, environ 20 ans avant la rédaction de ce document. Tout au long des années 80, le gouvernement des États-Unis a continué de financer fortement la recherche et le développement pour la technologie Internet. La DARPA est restée la principale source de financement, mais a été complétée par d'autres financements du DoD (US Department of Defence) (par exemple, via le programme Defence Data Network (DDN) de la Defense Communication Agency (DCA)) et d'autres financements du gouvernement américain (par ex. , Financement du Département américain de l'énergie (DoE) pour les réseaux de recherche dans les laboratoires nationaux du DoE, financement de la National Science Foundation (NSF) (États-Unis) pour les établissements universitaires). Ce financement comprenait la recherche fondamentale, la recherche appliquée (y compris les prototypes librement distribuables), l'achat de produits compatibles IP,

Au cours des années 80, le Département de la Défense des États-Unis a souhaité abandonner la fourniture de services de réseau opérationnels aux établissements universitaires, de sorte que le financement de la plupart des activités universitaires a été transféré à la NSF au cours de la décennie. Le travail initial de NSF comprenait le parrainage de CSnet en 1981. En 1986, NSF parrainait également divers projets de recherche sur le réseautage (par exemple, le travail de Mills sur les Fuzzballs). À la fin des années 80, NSF a créé le backbone NSFnet et a parrainé la création de plusieurs réseaux régionaux NSF (par exemple, SURAnet) et des interconnexions avec plusieurs réseaux de recherche internationaux. NSF a également financé la recherche sur les réseaux gigabits, par le biais de la Corporation for National Research Initiatives (CNRI), à partir de la fin des années 1980. Il est important de noter que le parrainage de la NSF était axé sur la réalisation des objectifs fondamentaux de la NSF, comme la mise en relation de scientifiques de grandes universités avec des centres de calcul intensif NSF. Les besoins d'accès à distance hautes performances aux supercalculateurs ont conduit les performances globales de NSFnet. En tant qu'effet secondaire, cela signifiait que les étudiants et les professeurs de ces universités bénéficiaient d'un environnement Internet relativement performant. Au fur et à mesure que ces étudiants ont obtenu leur diplôme, ils ont favorisé à la fois l'utilisation commerciale d'Internet et le marché résidentiel naissant. Ce n’est pas un hasard si c’est dans cet environnement que le World Wide Web est né. ils ont conduit à la fois à l'utilisation commerciale d'Internet et au marché résidentiel naissant. Ce n’est pas un hasard si c’est dans cet environnement que le World Wide Web est né. ils ont conduit à la fois à l'utilisation commerciale d'Internet et au marché résidentiel naissant. Ce n’est pas un hasard si c’est dans cet environnement que le World Wide Web est né.

La plupart des financements de recherche en dehors des États-Unis au cours des années 1980 et au début des années 1990 étaient axés sur le projet de réseau ISO OSI ou sur les nouvelles formes de médias de réseau à l'époque (par exemple, l'accès sans fil à large bande). L'Union européenne a été une source importante de financement de la recherche pour la communauté des réseaux en Europe pendant cette période. Certains des meilleurs travaux préliminaires de mise en réseau gigabit ont été entrepris au Royaume-Uni et en Suède.

2.3. Milieu des années 1990 à 2003

À partir du milieu des années 90, le financement du gouvernement américain pour la recherche et le développement sur Internet a été considérablement réduit. La prémisse à cet égard était que l’industrie Internet en pleine croissance paierait pour la recherche et le développement nécessaires. Certains financements pour la recherche et le développement d'Internet ont continué pendant cette période de la part d'organisations européennes et asiatiques (par exemple, le projet WIDE au Japon [WIDE]). Réseaux IP Europeens [RIPE] est un exemple de recherche de réseau financée par le marché en Europe au cours de cette période.

L’expérience de cette période a montré que les entreprises commerciales se sont souvent concentrées sur le don d’équipement aux établissements universitaires et sur la promotion de projets éducatifs quelque peu professionnels. Bon nombre des projets de recherche et développement financés par le commerce semblent avoir été sélectionnés parce qu'ils semblaient susceptibles de donner à la source de financement un avantage économique spécifique à court terme par rapport à ses concurrents. Les propositions de recherche plus risquées et plus innovantes n'ont généralement pas été financées par l'industrie. Une opinion commune dans la Silicon Valley a été que les entreprises commerciales établies ne sont pas très douées pour la transition de la recherche de pointe vers les produits, mais étaient plutôt bonnes pour acheter de petites entreprises en démarrage qui avaient réussi la transition de ces recherches de pointe vers des produits. Malheureusement,

2.4. Statut actuel

Le résultat de la réduction du financement du gouvernement américain et du financement industriel à court terme et à faible risque axé sur le profit a été un déclin des activités de recherche plus risquées, mais plus innovantes. L'industrie s'est également moins intéressée à la recherche pour faire évoluer l'architecture globale d'Internet, car ce travail ne se traduit pas par un avantage concurrentiel pour l'entreprise qui finance ce travail.

Le CCI estime qu'il serait utile que les gouvernements et autres sponsors non commerciaux augmentent leur financement à la fois de la recherche fondamentale et de la recherche appliquée liées à Internet, et de maintenir ces niveaux de financement à l'avenir.

3. Ouvrir les sujets de recherche Internet

Cette section traite principalement de certains sujets spécifiques qui, selon l'IAB, méritent des recherches supplémentaires. La recherche, bien sûr, comprend non seulement la conception d'une théorie, d'un algorithme ou d'un mécanisme pour atteindre un objectif, mais également l'évaluation de l'efficacité générale de l'approche, puis les avantages par rapport aux coûts de déploiement de cet algorithme ou mécanisme. Des mises en garde importantes concernant cette discussion sont données dans la sous-section suivante. Cet ensemble particulier de sujets ne se veut pas exhaustif, mais vise plutôt à démontrer l'étendue des questions de recherche ouvertes sur Internet.

D'autres discussions sur les problèmes d'Internet qui méritent des recherches plus approfondies sont les suivantes: [CIPB02, Claffy03a, Floyd, NSF03a, NSF03b].

3.1. Portée et limites

Ce document n'est PAS conçu comme un guide pour les agences de financement public quant aux projets ou propositions qui devraient ou ne devraient pas être financés.

En particulier, ce document n'est PAS destiné à être une liste complète de * toutes * les questions de recherche qui sont importantes pour faire avancer l'évolution d'Internet; ce serait une tâche ardue et supposerait un effort plus large et plus intensif que celui que nous avons entrepris dans ce document.

De même, ce document ne vise pas à énumérer les questions de recherche jugées comme étant uniquement d'importance périphérique, ni à examiner les voies actuelles (mondiales, gouvernementales, commerciales et universitaires) de financement de la recherche sur Internet, ni à faire des recommandations spécifiques sur quels domaines nécessitent un financement supplémentaire. Le but du document est de persuader le lecteur que des recherches continues sont nécessaires pour l'évolution continue de l'infrastructure Internet; le but n'est pas de faire des déclarations contraignantes sur les domaines spécifiques qui méritent et ne méritent pas un financement futur.

Pour certaines recherches clairement pertinentes pour l'évolution future de l'Internet, il existe de grandes controverses entre des propositions concurrentes ou des écoles de pensée concurrentes; le but de ce document n'est pas de prendre position sur ces controverses, ni de prendre position sur la nature des solutions pour des domaines nécessitant des recherches plus poussées.

Tout cela soigneusement noté, le reste de cette section traite d'un large ensemble de domaines de recherche, en notant un sous-ensemble de sujets particuliers d'intérêt dans chacun de ces domaines de recherche. Encore une fois, cette liste n'est PAS exhaustive, mais vise plutôt à suggérer qu'un large éventail de recherches en cours est nécessaire et à proposer des sujets candidats.

3.1.1. Terminologie

Plusieurs endroits de ce document font référence aux «opérateurs de réseau». Par ce terme, nous avons l'intention d'inclure toute personne ou toute organisation qui exploite un réseau IP; nous n'utilisons pas ce terme au sens étroit des fournisseurs de services de réseau commerciaux.

3.2. Appellation

Internet a actuellement plusieurs espaces de noms différents, y compris les adresses IP, les sockets (spécifiés par l'adresse IP, le protocole de couche supérieure et le numéro de port de couche supérieure), le numéro de système autonome (AS) et le nom de domaine complet (FQDN) . De nombreux espaces de noms Internet sont pris en charge par le système de noms de domaine largement déployé [RFC-3467] ou par diverses applications Internet [RFC-2407, section 4.6.2.1]

3.2.1. Système de noms de domaine (DNS)

Le système DNS, s'il fonctionne bien compte tenu de ses contraintes actuelles, présente plusieurs points de stress.

Le système DNS actuel repose sur UDP pour le transport, plutôt que sur SCTP ou TCP. Étant donné le très grand nombre de clients utilisant un serveur DNS classique, il est souhaitable de minimiser l'état du côté serveur DNS de la connexion. UDP le fait bien, c'est donc un choix raisonnable, bien que cela ait d'autres implications, par exemple une dépendance à la fragmentation UDP. Avec IPv6, la fragmentation intermédiaire n'est pas autorisée et Path MTU Discovery est obligatoire. Cependant, la quantité d'états requise pour déployer Path MTU Discovery pour IPv6 sur un serveur DNS peut être un problème pratique important.

Une implication de ceci est que la recherche sur des protocoles de transport alternatifs, conçus davantage pour des applications de type DNS où de très nombreux clients utilisent chaque serveur, pourrait être utile. Les protocoles de transport avec peu de charge pour le serveur DNS seraient particulièrement intéressants, même si cela augmentait quelque peu la charge pour le client DNS.

Une étude supplémentaire de la mise en cache DNS, à la fois des techniques de mise en cache actuellement disponibles et des nouvelles techniques de mise en cache potentielles, pourrait être utile pour trouver des moyens de réduire la charge offerte pour un serveur DNS typique. En particulier, l'examen de la mise en cache DNS via des pare-feu commerciaux typiques pourrait être intéressant s'il conduisait à des implémentations de pare-feu alternatives qui constituaient moins un obstacle à la mise en cache DNS.

La communauté ne dispose pas d'un ensemble de mesures largement accepté pour mesurer les performances du serveur DNS. Il serait utile que les gens réfléchissent sérieusement aux caractéristiques du système DNS à mesurer.

Certains membres de la communauté préconiseraient de remplacer le système DNS actuel par quelque chose de mieux. Les tentatives passées pour concevoir une meilleure approche n'ont pas donné de résultats qui ont persuadé la communauté de changer. Les travaux proposés dans ce domaine pourraient être très utiles, mais pourraient nécessiter un examen attentif pour éviter de tomber dans des écueils de conception historiques.

En ce qui concerne la sécurité DNS, les principales préoccupations techniques concernent la recherche de méthodes pratiques pour signer de très grandes zones DNS (par exemple, et des outils pour faciliter la gestion d'une infrastructure DNS sécurisée.

La plupart des utilisateurs sont incapables de distinguer une panne liée au DNS d'une panne de réseau plus générale. Par conséquent, le maintien de l'intégrité et de la disponibilité du système de noms de domaine est très important pour la santé future de l'Internet.

3.2.2. Nouveaux espaces de noms

De plus, le groupe de recherche sur les espaces de noms (NSRG) de l'Internet Research Task Force (IRTF) a étudié l'ajout d'un ou plusieurs espaces de noms supplémentaires à l'architecture Internet [LD2002]. De nombreux membres du NSRG de l'IRTF estiment qu'il y aurait un avantage architectural significatif à ajouter un ou plusieurs espaces de noms supplémentaires à l'architecture Internet. Parce qu'un consensus sans heurts sur cette question ou sur les propriétés d'un nouvel espace de noms n'a pas été obtenu, l'IRTF NSRG n'a pas fait de recommandation formelle à la communauté IETF concernant les espaces de noms. L'IAB estime qu'il s'agit d'une question de recherche ouverte qui mérite d'être approfondie.

Enfin, nous pensons que les recherches futures sur l'évolution de l'informatique distribuée basée sur Internet pourraient bien bénéficier de l'étude de l'ajout d'espaces de noms supplémentaires dans le cadre d'une nouvelle approche de l'informatique distribuée.

3.3. Routage

Le système de routage unicast actuellement déployé fonctionne raisonnablement bien pour la plupart des utilisateurs. Cependant, l'architecture de routage unicast actuelle est sous-optimale dans plusieurs domaines, dont les suivants: temps de convergence de bout en bout dans des catenets à l'échelle mondiale (un système de réseaux interconnectés via des passerelles); la capacité de l'algorithme de vecteur de chemin interdomaine existant à évoluer bien au-delà de 200 000 préfixes; la capacité du routage intra-domaine et inter-domaine à utiliser simultanément plusieurs métriques et plusieurs types de métriques; et la capacité d'IPv4 et d'IPv6 à prendre en charge le multi-homing de site étendu sans impact négatif indu sur le système de routage interdomaine. L'intégration de la politique dans le routage est également une préoccupation générale, à la fois pour le routage intra-domaine et inter-domaine. Dans de nombreux cas, la politique de routage est directement liée à des enjeux économiques pour les opérateurs de réseau,

Il s'agit d'un problème pour lequel l'intérêt commercial est clair, mais il semble peu probable qu'il soit résolu par le financement commercial de la recherche, en l'absence d'un consortium d'un type quelconque.

3.3.1. Routage interdomaine

Le système de routage interdomaine opérationnel actuel a entre 150 000 et 200 000 préfixes de routage dans la zone sans défaut (DFZ) [RFC-3221]. La technologie ASIC évite les inquiétudes concernant la capacité de transmettre des paquets à des vitesses très élevées. La technologie ASIC évite également les préoccupations concernant le temps nécessaire pour effectuer les calculs de correspondance de préfixe le plus long. Cependant, certains membres expérimentés de la communauté du routage Internet craignent que les propriétés de convergence de bout en bout de l'Internet mondial n'atteignent des limitations algorithmiques fondamentales (c'est-à-dire pas des limitations matérielles) lorsque la DFZ se situe entre 200 000 et 300 000 préfixes. La recherche pour savoir si cette préoccupation est fondée en termes scientifiques semble très opportune.

Indépendamment de la préoccupation ci-dessus, des travaux récents ont montré qu'il peut y avoir des problèmes de convergence BGP importants aujourd'hui. À l'heure actuelle, il semble que les problèmes de convergence actuellement observés concernent la façon dont BGP a été configuré par les opérateurs de réseau, plutôt que d'être une sorte de limitation algorithmique fondamentale [MGVK02]. Ce problème de temps de convergence rend la durée de la panne apparente du réseau beaucoup plus longue qu'elle ne devrait l'être. Des recherches appliquées supplémentaires sur les aspects d'une configuration BGP qui ont le plus fort impact sur les temps de convergence contribueraient à atténuer les problèmes opérationnels actuellement observés.

En outre, le routage interdomaine nécessite actuellement une ingénierie humaine importante de chemins inter-AS spécifiques pour garantir que des chemins raisonnablement optimaux sont utilisés par le trafic réel. Idéalement, le système de routage interdomaine entraînerait automatiquement le choix de chemins raisonnablement optimaux. Des travaux récents indiquent que des mécanismes de politique BGP améliorés pourraient aider à garantir que des chemins raisonnablement optimaux sont normalement utilisés pour le trafic IP interdomaine. [SMA03] La poursuite de la recherche appliquée dans ce domaine pourrait conduire à des approches techniques nettement meilleures.

L'approche actuelle du multi-homing de site a pour effet secondaire hautement indésirable d'augmenter significativement le taux de croissance des entrées de préfixes dans la DFZ (en altérant le déploiement de l'agrégation de préfixes). Des recherches sont nécessaires sur de nouvelles architectures de routage qui peuvent prendre en charge le multi-homing de site à grande échelle sans les impacts indésirables sur le routage inter-domaine de la technique actuelle de multi-homing.

L'application originale de BGP était dans le routage inter-domaines, principalement dans les réseaux de fournisseurs de services, mais aussi avec une certaine utilisation par des sites multi-hébergés. Cependant, certains essaient maintenant d'utiliser BGP dans d'autres contextes, par exemple des environnements très mobiles, où il est évidemment moins bien adapté. La recherche sur le routage inter-domaine et / ou le routage de politique intra-domaine pourrait conduire à d'autres approches pour tous les environnements émergents où l'approche BGP actuelle n'est pas la meilleure.

3.3.2. Intégrité du routage

Récemment, on a pris conscience du problème de longue date du déploiement d'une authentification forte dans le système de routage interdomaine Internet. Les mécanismes actuellement déployés (par exemple, BGP TCP MD5 [RFC-2385], OSPF MD5, RIP MD5 [RFC-2082]) fournissent une authentification cryptographique des messages de protocole de routage, mais aucune authentification des données de routage réelles. Des propositions récentes (par exemple, S-BGP [KLMS2000]) pour améliorer cela dans le routage inter-domaine semblent difficiles à déployer sur Internet, en partie à cause de leur dépendance à une seule hiérarchie de confiance (par exemple, une seule PKI). Des propositions similaires (par exemple, OSPF avec signatures numériques, [RFC-2154]) pour le routage intra-domaine sont soutenues comme étant irréalisables sur le plan informatique à déployer dans un grand réseau.

Un défi récurrent avec toute forme d'authentification de routage inter-domaines est qu'il n'y a pas de source de vérité unique et complètement exacte sur les organisations qui ont le pouvoir d'annoncer quels blocs d'adresses. Des approches alternatives d'authentification des données dans le système de routage doivent être développées. En particulier, la possibilité d'effectuer une authentification partielle des données de routage faciliterait le déploiement incrémentiel des mécanismes d'authentification de routage. En outre, la possibilité d'utiliser des modèles de confiance non hiérarchiques (par exemple, le réseau de confiance utilisé dans l'application PGP) pourrait faciliter le déploiement incrémentiel et pourrait résoudre les problèmes existants concernant l'administration centralisée du système de routage, ce qui mérite donc une étude et une considération supplémentaires.

3.3.3. Algorithmes de routage

Le système de routage Internet actuel repose principalement sur deux algorithmes. Le routage à l'état des liens utilise l'algorithme de Dijkstra [Dijkstra59]. Le routage à distance-vecteur (par exemple, RIP) et le routage à vecteur de chemin (par exemple, BGP) utilisent l'algorithme de Bellman-Ford [Bellman1957, FF1962]. Des recherches de base supplémentaires en cours sur la théorie des graphes appliquée au routage en valent la peine et pourraient produire des algorithmes qui permettraient une nouvelle architecture de routage ou apporteraient des améliorations au système de routage.

Le routage multicast actuellement déployé repose sur l'algorithme Deering RPF [Deering1988]. Les recherches en cours sur les algorithmes et protocoles de routage multicast alternatifs pourraient contribuer à atténuer les préoccupations actuelles concernant l'évolutivité du routage multicast.

Le système de routage Internet déployé suppose que le chemin le plus court est toujours le meilleur chemin. Ceci est prouvé faux, mais il s'agit d'un compromis raisonnable étant donné les protocoles de routage actuellement disponibles. L'Internet manque d'approches déployables pour le routage basé sur des politiques ou le routage avec des métriques alternatives (c'est-à-dire, certaines métriques autres que le nombre de sauts vers la destination). Des exemples de politiques alternatives comprennent: la voie avec le plus faible coût monétaire; le chemin avec la plus faible probabilité de perte de paquets; le chemin avec une gigue minimisée; et le chemin avec une latence minimisée. Les mesures de politique doivent également prendre en compte les relations commerciales.

La transition du système de routage inter-domaines actuel vers tout nouveau système de routage inter-domaines ne sera probablement pas un exercice trivial. Toute proposition de nouveau système de routage doit donc examiner et documenter attentivement les stratégies de déploiement, les mécanismes de transition et d'autres considérations opérationnelles. En raison de l'aspect d'interopérabilité interdomaine du routage interdomaine, des transitions fluides à partir d'un système de routage interdomaine seront probablement difficiles à réaliser. Par ailleurs, le système de routage interdomaine manque de forces du marché fortes qui encourageraient la migration vers de meilleures approches techniques. Par conséquent, il semble peu probable que le secteur commercial soit à l'origine d'un système de routage interdomaine considérablement amélioré.

3.3.4. Routage mobile et ad-hoc

Alors que certaines des premières recherches sur les réseaux parrainées par la DARPA impliquaient des réseaux radio par paquets, le routage mobile [IM1993] et le routage mobile ad hoc [RFC-2501] sont des arrivées relativement récentes sur Internet et ne sont pas encore largement déployés. Les approches actuelles ne sont pas le dernier mot dans aucun de ces domaines. Nous pensons que des recherches supplémentaires sur la prise en charge du routage pour les hôtes mobiles et les réseaux mobiles sont nécessaires. Des recherches supplémentaires sur les hôtes mobiles ad hoc et les réseaux mobiles valent également la peine. Idéalement, les capacités de routage mobile et de routage ad hoc mobile devraient être des capacités natives inhérentes à l'architecture de routage Internet. Cela nécessitera probablement une évolution significative de l'architecture de routage Internet existante. (NB: le terme «mobilité» tel qu'utilisé ici ne se limite pas aux téléphones mobiles, mais est plutôt défini de manière très large,

Cette rubrique comprend une grande variété de problèmes. La nature plus distribuée et dynamique des systèmes de routage partiellement ou totalement auto-organisés (y compris les nœuds d'extrémité associés) crée des défis de sécurité uniques (en particulier en ce qui concerne l'autorisation, l'authentification et la comptabilité, et la gestion des clés). L'évolutivité des réseaux sans fil peut être difficile à mesurer ou à réaliser. La hiérarchie forcée est une approche, mais peut être très limitative. Des approches alternatives moins contraignantes de l'évolutivité sans fil sont souhaitées. Étant donné que les protocoles de couche liaison sans fil ont généralement une certaine connaissance des caractéristiques de liaison actuelles telles que la qualité de la liaison, les conditions d'encombrement des sous-couches ou le comportement des canaux transitoires, il est souhaitable de trouver des moyens de laisser le routage de couche réseau utiliser ces données.

3.4. Sécurité

Internet a la réputation de ne pas avoir une sécurité suffisante. En fait, Internet dispose d'un certain nombre de mécanismes de sécurité normalisés, dont certains sont largement déployés. Cependant, il existe un certain nombre de questions de recherche ouvertes relatives à la sécurité Internet. En particulier, les mécanismes de sécurité doivent être déployables de manière incrémentielle et faciles à utiliser. "La technologie [de sécurité] doit être facile à utiliser, sinon elle ne sera pas configurée correctement. Si elle est mal configurée, la sécurité sera perdue, mais les choses" fonctionneront "" [Schiller03].

3.4.1. Méthodes formelles

Il existe un besoin permanent de financement de la recherche fondamentale relative à la sécurité Internet, y compris le financement de la recherche sur les méthodes formelles liées aux algorithmes, protocoles et systèmes de sécurité.

Par exemple, il serait avantageux d'avoir une étude plus formelle des modèles de confiance non hiérarchiques (par exemple, le modèle Web-of-Trust de PGP). L'utilisation d'un modèle de confiance hiérarchique peut créer des limitations significatives dans la façon dont on pourrait aborder la sécurisation des composants d'Internet, par exemple le système de routage interdomaine. Ainsi, la recherche pour développer de nouveaux modèles de confiance adaptés à Internet ou sur l'applicabilité des modèles de confiance non hiérarchiques existants aux problèmes Internet existants en vaudrait la peine.

Bien qu'il y ait eu des travaux sur l'application de méthodes formelles aux algorithmes cryptographiques et aux protocoles cryptographiques, les techniques existantes d'évaluation formelle des algorithmes et des protocoles manquent d'automatisation suffisante. Ce manque d'automatisation signifie que de nombreux protocoles ne sont pas officiellement évalués en temps opportun. Ceci est problématique pour Internet, car une évaluation formelle a souvent révélé de graves anomalies dans les protocoles cryptographiques. La création d'outils automatisés pour appliquer des méthodes formelles aux algorithmes et / ou protocoles cryptographiques serait très utile.

3.4.2. Gestion des clés

Un défi récurrent pour la communauté Internet est de savoir comment concevoir, mettre en œuvre et déployer une gestion des clés appropriée à la myriade de contextes de sécurité existant dans l'Internet mondial. La plupart des travaux actuels dans le domaine de la gestion des clés monodiffusion se sont concentrés sur des modèles de confiance hiérarchiques, car une grande partie du travail existant a été conduit par des modèles d'exploitation «descendants» d'entreprise ou militaires.

La rareté des méthodes de gestion des clés applicables aux modèles de confiance non hiérarchiques (voir ci-dessus) est une contrainte importante sur les approches qui pourraient être adoptées pour sécuriser les composants d'Internet.

Une recherche axée sur l'élimination de ces contraintes en développant des méthodes pratiques de gestion des clés applicables aux modèles de confiance non hiérarchiques serait très utile.

Les sujets méritant une recherche supplémentaire incluent les techniques de gestion de clés, telles que les architectures de gestion de clés non hiérarchiques (par exemple, pour prendre en charge des modèles de confiance non hiérarchiques; voir ci-dessus), qui sont utiles par les groupes ad hoc dans les réseaux mobiles et / ou l'informatique distribuée.

Bien que certains progrès aient été réalisés ces dernières années, la gestion évolutive des clés multicast est loin d'être un problème résolu. Les approches existantes de la gestion évolutive des clés multicast ajoutent des contraintes importantes sur la portée du problème afin de proposer une solution technique déployable. Une approche plus générale de la gestion évolutive des clés de multidiffusion (c'est-à-dire une approche plus large et moins contraignante) améliorerait les capacités d'Internet.

Dans de nombreux cas, la négociation d'attributs est une capacité importante d'un protocole de gestion de clé. L'expérience acquise à ce jour avec Internet Key Exchange (IKE) a montré qu'il est excessivement complexe. Une grande partie de la complexité d'IKE provient de ses capacités de négociation d'attributs très générales. Une nouvelle approche de gestion des clés qui prendrait en charge la négociation d'attributs importants sans créer de niveaux de déploiement et de complexité des opérations difficiles serait utile.

3.4.3. Cryptographie

Il existe un besoin permanent de poursuivre le financement de la recherche dans le monde ouvert dans les domaines de la cryptographie et de la cryptanalyse. La plupart des gouvernements concentrent leurs recherches cryptographiques sur le secteur militaire. Bien que cela soit compréhensible, ces efforts ont souvent peu (ou pas) de publications dans la littérature ouverte. Puisque la communauté d'ingénierie Internet doit travailler à partir de la littérature ouverte, il est important que la recherche sur le monde ouvert se poursuive à l'avenir.

3.4.4. Sécurité pour le calcul distribué

Le projet Athena du MIT était un projet de recherche important et largement réussi sur l'informatique distribuée. Le projet Athena a développé le système de sécurité Kerberos [RFC-1510], qui a aujourd'hui un déploiement important dans les environnements de campus. Cependant, Kerberos inter-royaume n'est ni aussi largement déployé ni perçu comme un succès aussi répandu que Kerberos à domaine unique. Le besoin d'une authentification utilisateur interdomaine évolutive est de plus en plus aigu à mesure que l'informatique ad hoc et l'informatique mobile sont de plus en plus largement déployées. Ainsi, travailler sur des mécanismes évolutifs pour l'authentification interdomaine mobile, ad hoc et non hiérarchique serait très utile.

3.4.5. Considérations de déploiement dans la sécurité

Beaucoup de travail a été fait sur une sécurité théoriquement parfaite qui est impossible à déployer. Malheureusement, la proposition S-BGP est un exemple de bon produit de recherche qui présente d'importants défis de déploiement non résolus. Il est loin d'être évident de savoir comment déployer S-BGP à grande échelle sans déployer auparavant une infrastructure à clé publique interdomaine à grande échelle et centraliser également l'application de la politique de publicité d'itinéraire dans les registres d'informations de routage ou un organisme similaire. Historiquement, les infrastructures à clé publique ont été soit très difficiles, soit impossibles à déployer à grande échelle. Les mécanismes de sécurité qui nécessitent une infrastructure supplémentaire n'ont pas été bien déployés. Nous avons désespérément besoin d'une sécurité générale, facile à installer et à gérer.

3.4.6. Protection contre le déni de service

Historiquement, la communauté Internet a pour la plupart ignoré les attaques par déni de service (DoS). Cela était approprié à un moment donné, car de telles attaques étaient rares et difficiles à défendre. Cependant, l'une des tendances récentes des logiciels antagonistes (par exemple, les virus, les vers) a été l'incorporation de fonctionnalités qui transforment l'hôte infecté en un «zombie». Ces zombies peuvent être contrôlés à distance pour monter une attaque de déni de service distribuée sur une machine victime. Dans de nombreux cas, les opérateurs autorisés de systèmes ne savent pas que certains ou tous leurs systèmes sont devenus des zombies. Il semble que la présence d'un nombre non négligeable de zombies sur l'Internet mondial soit désormais endémique, ce qui rend les attaques par déni de service distribuées une préoccupation beaucoup plus grande. Les modèles de menaces Internet doivent donc supposer la présence de tels zombies en nombre significatif. Cela rend la conception de protocoles résiliente en présence d'attaques de déni de service distribuées très importantes pour la santé d'Internet. Un certain travail a été fait sur ce front [Savage00], [MBFIPS01], mais il en faut davantage.

3.5. La gestion du réseau

Internet a connu un succès précoce dans la surveillance des périphériques réseau avec le protocole SNMP (Simple Network Management Protocol) et sa base d'informations de gestion (MIB) associée. La gestion des réseaux a été comparativement moins réussie, contrairement à la surveillance des appareils individuels. En outre, il existe un certain nombre d'exigences des opérateurs qui ne sont pas bien prises en charge par le cadre de gestion Internet actuel. Il est souhaitable d'améliorer l'architecture actuelle de gestion du réseau Internet afin de mieux répondre aux besoins opérationnels.

Malheureusement, la recherche sur la gestion de réseau a toujours été très sous-financée. Les opérateurs se sont plaints de l'insuffisance des solutions existantes. Des recherches sont nécessaires pour trouver de meilleures solutions.

3.5.1. Gérer les réseaux, pas les appareils

À l'heure actuelle, il existe peu ou pas de bons outils pour gérer un réseau entier au lieu d'appareils isolés. Par exemple, le manque d'outils de gestion de réseau appropriés a été cité comme l'un des principaux obstacles au déploiement généralisé de la multidiffusion IP [Diot00, SM03]. Les protocoles de gestion de réseau actuels, tels que le protocole SNMP (Simple Network Management Protocol), conviennent pour la lecture de l'état d'objets bien définis à partir de boîtes individuelles. La gestion de réseaux au lieu de périphériques isolés nécessite la possibilité de voir le réseau comme un grand système distribué. Des recherches sont nécessaires sur les mécanismes d'agrégation de données distribués évolutifs, les mécanismes de corrélation d'événements distribués évolutifs et les mécanismes de contrôle distribués et fiables.

La recherche appliquée sur les méthodes de gestion des ensembles d'appareils en réseau semble utile. Idéalement, une telle approche de gestion prendrait en charge la gestion distribuée, plutôt que d'être strictement centralisée.

3.5.2. Capacités de surveillance améliorées

SNMP ne s'adapte pas toujours bien à la surveillance d'un grand nombre d'objets dans de nombreux périphériques dans différentes parties du réseau. Une approche alternative qui mérite d'être explorée est de savoir comment fournir une surveillance évolutive et distribuée, non pas sur des appareils individuels, mais plutôt sur des groupes d'appareils et sur le réseau dans son ensemble. Cela nécessite des techniques évolutives d'agrégation de données et de corrélation d'événements des données d'état du réseau provenant de nombreux emplacements du réseau.

3.5.3. Gestion du réseau client

Un problème ouvert lié à la gestion du réseau est d'aider les utilisateurs et d'autres personnes à identifier et à résoudre les problèmes du réseau. Si un utilisateur ne peut pas accéder à une page Web, il serait utile que l'utilisateur puisse savoir, facilement, sans avoir à exécuter un ping et un traceroute, si le problème était que le serveur Web était en panne, que le réseau a été partitionné en raison d’un échec de liaison, qu'il y avait une forte congestion le long du chemin, que le nom DNS n'a pas pu être résolu, que le pare-feu a interdit l'accès ou qu'un autre événement spécifique s'est produit.

3.5.4. Gestion de réseau autonome===

Des recherches supplémentaires sont nécessaires pour améliorer le degré d'automatisation atteint par les systèmes de gestion de réseau et localiser la gestion. La gestion de réseau autonome peut impliquer l'application de la théorie du contrôle, de l'intelligence artificielle ou des technologies de système expert à des problèmes de gestion de réseau.

3.6. Qualité de service

Il y a eu un corpus intensif de recherche et développement sur l'ajout de la qualité de service à l'architecture Internet depuis plus de dix ans maintenant [RFC-1633, RFC-2474, RFC-3260, RFC-2205, RFC-2210], mais nous ne 'pas de QoS de bout en bout sur Internet [RFC-2990, RFC-3387]. L'IETF est bon pour définir les mécanismes de QoS individuels, mais médiocre au travail sur les architectures QoS déployables. Ainsi, alors que les mécanismes de services différenciés (DiffServ) ont été normalisés en tant que comportements par saut, il reste encore beaucoup à apprendre sur le déploiement de ce mécanisme ou d'autres mécanismes de qualité de service pour la qualité de service de bout en bout. En plus de travailler sur des questions purement techniques, cela inclut une attention particulière aux modèles économiques et aux stratégies de déploiement qui permettraient un déploiement accru de la QoS dans le réseau.

Dans de nombreux cas, le déploiement de mécanismes de qualité de service augmenterait considérablement les risques de sécurité opérationnelle [RFC-2990], de sorte que toute nouvelle recherche sur les mécanismes ou architectures de qualité de service devrait spécifiquement discuter des problèmes de sécurité potentiels associés à la ou aux nouvelles propositions et comment les atténuer. problèmes de sécurité.

Dans certains cas, la demande de mécanismes de qualité de service a été diminuée par le développement de techniques de codage voix / vidéo plus résilientes, mieux adaptées à l'Internet au meilleur effort que les anciennes techniques de codage conçues à l'origine pour les réseaux à commutation de circuits.

L'un des facteurs qui a émoussé la demande de QoS a été la transition de l'infrastructure Internet d'une forte congestion au début des années 1990 à une surprovisionnement des dorsales et de nombreuses liaisons internationales aujourd'hui. Ainsi, la recherche sur les mécanismes de QoS doit également inclure une attention particulière aux coûts et avantages relatifs de la QoS à différents endroits du réseau. La recherche appliquée sur la qualité de service devrait inclure une considération explicite des problèmes économiques liés au déploiement et à l'exploitation d'un réseau IP compatible avec la qualité de service [Clark02].

3.6.1. Architecture QoS inter-domaines

En règle générale, un routeur dans l'Internet interdomaine déployé fournit une transmission au mieux des paquets IP, sans se soucier du fait que la source ou la destination du paquet est un client direct de l'opérateur du routeur. Cette propriété contribue de manière significative à l'évolutivité actuelle de l'Internet mondial et contribue à la difficulté de déployer des mécanismes de qualité de service (QoS) interdomaines.

Le déploiement de mécanismes de qualité de service (QoS) existants, par exemple des services différenciés ou des services intégrés, à travers une frontière interdomaine crée une vulnérabilité de déni de service importante et facilement exploitable pour tout réseau qui fournit une prise en charge de la qualité de service interdomaine. Cela a conduit les opérateurs de réseau à s'abstenir de prendre en charge la qualité de service interdomaine. Internet bénéficierait de recherches supplémentaires sur des approches alternatives de la qualité de service, en particulier sur des approches qui ne créent pas de telles vulnérabilités et peuvent être déployées de bout en bout [RFC-2990].

En outre, les modèles commerciaux actuels ne sont pas cohérents avec la qualité de service interdomaine, en grande partie parce qu'il est impossible ou impossible d'authentifier l'identité de l'expéditeur du trafic potentiel préféré tout en acheminant le trafic au débit de ligne. En l'absence d'une telle capacité, on ne sait pas comment un opérateur de réseau pourrait facturer ou recouvrer autrement les coûts associés à la fourniture de ce service préféré. Ainsi, tout nouveau travail sur les mécanismes et architectures de QoS interdomaines doit examiner attentivement les implications économiques et sécuritaires de telles propositions.

3.6.2. Nouvelles disciplines de mise en file d'attente

La qualité de service globale du trafic est en partie déterminée par les mécanismes de planification et de gestion des files d'attente au niveau des routeurs. Bien qu'il existe un certain nombre de mécanismes existants (par exemple, RED) qui fonctionnent bien, il est possible que des stratégies améliorées de mise en file d'attente active soient conçues. Les mécanismes qui réduisent le coût de mise en œuvre dans les routeurs IP peuvent aider à accroître le déploiement de la gestion active des files d'attente, par exemple.

3.7. Contrôle de la congestion.

Les mécanismes d'évitement de congestion et de contrôle de TCP, à partir de 1988 [Jacobson88], ont été un facteur clé dans le maintien de la stabilité d'Internet et sont utilisés par la majeure partie du trafic Internet. Cependant, les mécanismes de contrôle de la congestion d'Internet doivent être étendus et modifiés pour répondre à un large éventail de nouvelles exigences, des nouvelles applications telles que le streaming multimédia et la multidiffusion aux nouveaux environnements tels que les réseaux sans fil ou les chemins à très haut débit, et les nouvelles exigences pour minimiser le délai de mise en file d'attente. Bien qu'il existe des travaux importants sur plusieurs de ces questions, il reste encore beaucoup à faire.

Nous notons que la recherche sur le contrôle de la congestion TCP n'est pas encore "terminée", avec beaucoup à faire dans le TCP à haut débit, ou dans l'ajout de performances robustes sur des chemins avec une réorganisation significative, une connectivité intermittente, une perte de paquets non congestive, et le semblable.

Plusieurs de ces problèmes soulèvent des questions fondamentales difficiles sur les coûts et avantages potentiels d'une communication accrue entre les couches. Cela aiderait-il le transport à recevoir des indices ou d'autres informations du routage, des couches de liaison ou d'autres connexions de niveau transport? Dans l'affirmative, quel serait le coût d'un fonctionnement robuste dans divers environnements?

Pour les mécanismes de contrôle de congestion dans les routeurs, la gestion active des files d'attente et la notification explicite de congestion ne sont généralement pas encore déployées, et il existe une gamme de propositions, dans divers états de maturité, dans ce domaine. Dans le même temps, il y a beaucoup de choses que nous ne comprenons toujours pas sur les interactions des mécanismes de gestion des files d'attente avec d'autres facteurs du réseau. Des mécanismes de contrôle de la congestion basés sur les routeurs sont également nécessaires pour détecter et répondre à la congestion globale, comme dans les attaques de déni de service distribué et les foules flash.

Étant donné que de plus en plus d'applications ont besoin de transférer des fichiers très volumineux sur des chemins de produits à bande passante à fort retard, les contraintes sur les mécanismes actuels de contrôle de la congestion soulèvent la question de savoir si nous avons besoin d'un retour plus fin des routeurs. Cela inclut le défi de permettre aux connexions d'éviter les retards de démarrage lent et d'utiliser rapidement la bande passante nouvellement disponible. À un niveau plus général, nous ne comprenons pas le potentiel et les limites du trafic au mieux sur les chemins de produits à bande passante à haut retard, étant donné les commentaires actuels des routeurs, ou la gamme de possibilités pour des commentaires plus explicites des routeurs.

Il existe également un besoin de recherche à long terme sur le contrôle de la congestion, distincte des exigences fonctionnelles spécifiques telles que celles énumérées ci-dessus. Nous en savons très peu sur la dynamique du contrôle de la congestion ou la dynamique du trafic d'un grand réseau complexe comme l'Internet mondial, avec ses mélanges de trafic hétérogènes et changeants, ses technologies de niveau de liaison, ses protocoles de réseau et ses mécanismes de routeur, ses modèles de congestion, ses modèles de tarification et les comme. L'élargissement de nos connaissances dans ce domaine semble nécessiter un riche mélange de mesures, d'analyses, de simulations et d'expérimentation.

3.8. Étudier l'évolution de l'infrastructure Internet

L'évolution de l'infrastructure Internet a été extrêmement lente et difficile, avec de longues histoires sur les difficultés d'ajout d'IPv6, de QoS, de multidiffusion et d'autres fonctionnalités à Internet. Nous avons besoin d'une compréhension plus scientifique des potentiels d'évolution et des difficultés d'évolution de l'infrastructure Internet.

Ce potentiel évolutif est affecté non seulement par les problèmes techniques de l'architecture IP en couches, mais également par d'autres facteurs. Ces facteurs comprennent les changements dans l'environnement au fil du temps (par exemple, le surapprovisionnement récent des dorsales, le déploiement de pare-feu) et le rôle du processus de normalisation. Les facteurs économiques et de politique publique sont également critiques, y compris le fait central d'Internet en tant que système décentralisé, les principaux acteurs étant non seulement les individus, mais également les FAI, les entreprises et des industries entières. Les problèmes de déploiement sont également des facteurs clés de l'évolution d'Internet, y compris le problème continu de la poule et de l'œuf d'avoir suffisamment de clients pour mériter le déploiement d'un service dont l'utilité dépend en premier lieu de la taille de la clientèle.

Les réseaux de superposition peuvent servir de technologie de transition pour certaines nouvelles fonctionnalités, avec un déploiement initial dans des réseaux de superposition, et avec la nouvelle fonctionnalité se déplaçant plus tard dans le noyau si cela semble justifié.

Il y a aussi des obstacles accrus à l'évolution d'Internet sous la forme d'une complexité accrue [WD02], d'interactions de caractéristiques imprévues [Kruse00], d'interactions entre couches [CWWS92], d'interventions par des boîtiers de médiation [RFC-3424], etc. Parce qu'une complexité croissante semble inévitable, des recherches sont nécessaires pour comprendre les mécanismes architecturaux qui peuvent s'adapter à une complexité accrue sans diminuer la robustesse des performances dans des environnements inconnus, et sans fermer les futures possibilités d'évolution. Plus concrètement, des recherches sont nécessaires pour savoir comment faire évoluer Internet et conservera ses atouts fondamentaux, tels que le degré actuel d'adressabilité globale des hôtes, la transparence de bout en bout du transfert de paquets et de bonnes performances pour le trafic au mieux.

3.9. Boîtes médianes

Des recherches sont nécessaires pour relever les défis posés par la large gamme de boîtiers de médiation [RFC-3234]. Cela inclut les problèmes de sécurité, de contrôle, d'intégrité des données et de l'impact général des boîtiers de médiation sur l'architecture.

À bien des égards, les boîtiers de médiation sont une conséquence directe des intérêts commerciaux, mais il est nécessaire de regarder au-delà des besoins à court terme de la technologie, de rechercher ses implications plus larges et d'explorer des moyens d'améliorer la façon dont les boîtiers de médiation sont intégrés dans l'architecture.

3.10. Mesure Internet

Un défi récurrent consiste à mesurer Internet; il y a eu de nombreuses discussions sur la nécessité d'études de mesure comme partie intégrante de la recherche sur Internet [Claffy03]. Dans cette discussion, nous définissons la mesure de manière assez large. Par exemple, il existe de nombreux défis dans la mesure des performances le long d'un chemin Internet important, en particulier lorsque le chemin traverse les limites du domaine administratif. Il existe également des défis dans la mesure de l'utilisation des protocoles / applications sur toute liaison Internet à haut débit. Bon nombre des problèmes évoqués ci-dessus bénéficieraient d'une fréquence accrue de mesure ainsi que d'une meilleure qualité de mesure sur l'Internet déployé.

Un problème clé dans la mesure du réseau est que la plupart des fournisseurs de services Internet commerciaux considèrent les caractéristiques particulières de leur (s) réseau (s) IP de production comme des secrets commerciaux. Des moyens doivent être trouvés pour des études de mesure coopératives, par exemple, pour permettre aux chercheurs non commerciaux légitimes d'être en mesure de mesurer les paramètres de réseau pertinents tout en protégeant également les droits à la vie privée des FAI mesurés.

En l'absence de données mesurées, il existe peut-être une dépendance excessive aux simulations de réseau dans certaines parties de la communauté de recherche sur Internet et une validation probablement insuffisante du fait que les modèles de simulation de réseau existants sont des représentations raisonnablement bonnes de l'Internet déployé (ou d'un futur Internet plausible) [FK02] .

Sans une mesure solide du comportement actuel d'Internet, il est très difficile de savoir quels problèmes opérationnels autrement inconnus existent qui nécessitent une attention, et il est également difficile de comprendre pleinement l'impact des changements (passés ou futurs) sur les caractéristiques comportementales réelles d'Internet.

3.11. Applications

Des recherches sont nécessaires sur un large éventail de questions liées aux applications Internet.

En prenant le courrier électronique comme exemple d'application, des recherches sont nécessaires pour comprendre le problème du spam et pour étudier les outils et techniques permettant d'atténuer les effets du spam, y compris les outils et techniques qui facilitent la mise en œuvre de mesures anti-spam légales et non techniques [ASRG ]. «Spam» est un terme générique désignant une gamme de types très différents de courriers électroniques indésirables, avec de nombreux types d'expéditeurs, de contenu et de techniques de génération de trafic. Dans le cadre du contrôle du spam, nous devons développer une bien meilleure compréhension de ses nombreuses caractéristiques différentes et de leurs interactions les unes avec les autres.

3.12. Répondre aux besoins du futur

À mesure que la taille du réseau, la bande passante de la liaison, la capacité du processeur et le nombre d'utilisateurs augmentent, des recherches seront nécessaires pour garantir que l'Internet du futur évolue pour répondre à ces demandes croissantes. Nous avons discuté de certains de ces problèmes de mise à l'échelle dans des sections spécifiques ci-dessus.

Cependant, pour toutes les questions de recherche abordées dans ce document, le but de la recherche doit être non seulement de relever les défis déjà rencontrés aujourd'hui, mais aussi de relever les défis que l'on peut s'attendre à voir émerger à l'avenir.

3.13. Prototypes librement distribuables

La DARPA américaine a historiquement financé le développement d'implémentations librement distribuables de diverses technologies Internet (par exemple, TCP / IPv4, RSVP, IPv6 et sécurité IP) dans une variété de systèmes d'exploitation (par exemple, 4.2 BSD, 4.3 BSD, 4.4 BSD, Tenex). L'expérience a montré qu'un bon moyen d'accélérer le déploiement d'une nouvelle technologie est de fournir un prototype libre et librement distribuable qui peut être incorporé dans des produits commerciaux ainsi que dans des prototypes non commerciaux. Le projet WIDE du Japon a également financé certains de ces travaux, principalement axés sur la mise en œuvre d'IPv6 pour 4.4 BSD et Linux. [WIDE] Nous pensons que les projets de recherche appliquée en réseautage auront une probabilité accrue de succès si les équipes de projet de recherche rendent les implémentations logicielles qui en résultent librement disponibles pour des utilisations commerciales et non commerciales.

4. Conclusions

Ce document a résumé l'historique du financement de la recherche sur Internet et a mis en évidence des exemples de questions de recherche ouvertes. L'IAB estime que des recherches supplémentaires sont nécessaires pour faire avancer l'évolution de l'infrastructure Internet et qu'un financement non commercial suffisant et cohérent est nécessaire pour permettre une telle recherche.

En cas de confusion, dans ce document, nous ne suggérons aucun rôle direct ou indirect pour l'IAB, l'IETF ou l'IRTF dans la gestion de tout financement de la recherche sur Internet.

5. Remerciements

Les personnes qui ont directement contribué à ce document sous une forme ou une autre sont les suivantes: Ran Atkinson, Guy Almes, Rob Austein, Vint Cerf, Jon Crowcroft, Sally Floyd, James Kempf, Joe Macker, Craig Partridge, Vern Paxson, Juergen Schoenwaelder et Mike St. John's.

Nous remercions également Kim Claffy, Dave Crocker, Michael Eder, Eric Fleischman, Andrei Gurtov, Stephen Kent, JP Martin-Flatin et Hilarie Orman pour leurs commentaires sur les versions antérieures de ce document.

Nous nous sommes également inspirés des rapports suivants: [CIPB02, IST02, NV02, NSF02, NSF03, NSF03a].

6. Considérations relatives à la sécurité

Ce document ne crée pas en lui-même de nouveaux problèmes de sécurité pour la communauté Internet. Les problèmes de sécurité au sein de l'architecture Internet sont principalement traités dans la section 3.4 ci-dessus.

7. Références informatives

[ASRG] Groupe de recherche anti-spam (ASRG) de l'IRTF. URL " http://asrg.sp.am/ ".

[Atk96] R. Atkinson et al., "Implementation of IPv6 in 4.4 BSD", Actes de la conférence technique annuelle USENIX 1996, Association USENIX, Berkeley, Californie, USA. Janvier 1996. URL http://www.chacs.itd.nrl.navy.mil/publications/CHACS/ 1996 / 1996atkinson-USENIX.pdf

[Bellman1957] RE Bellman, "Programmation dynamique", Princeton University Press, Princeton, NJ, 1957.

[Claffy03] K. Claffy, "Priorities and Challenges in Internet Measurement, Simulation, and Analysis", réunion du réseau à grande échelle, (États-Unis) National Science Foundation, Arlington, VA, États-Unis. 10 juin 2003. URL « http://www.caida.org/outreach/ présentations / 2003 / lsn20030610 /».

[Claffy03a] K. Claffy, "Top Problems of the Internet and What Sysadmins and Researchers Can Do To Help", conférence plénière à LISA'03, octobre 2003. URL " http://www.caida.org/outreach/presentations/ 2003 / netproblems_lisa03 / ".

[Clark02] DD Clark, "Deploying the Internet - why does it take so long and, can research help?", Large-Scale Networking Distinguished Lecture Series, (US) National Science Foundation, Arlington, VA, 8 janvier 2002. URL: http: //www.ngi- supernet.org/conferences.html

[CSTB99] Computer Science and Telecommunications Board, (États-Unis) National Research Council, "Funding a Revolution: Government Support for Computing Research", National Academy Press, Washington, DC, 1999. URL " http://www7.nationalacademies.org/ cstb / pub_revolution.html ".

[CIPB02] Critical Infrastructure Protection Board, "Stratégie nationale pour sécuriser le cyberespace", La Maison Blanche, Washington, DC, USA. Septembre 2002, URL " http://www.whitehouse.gov/pcipb ".

[CWWS92] J. Crowcroft, I. Wakeman, Z. Wang et D. Sirovica, "Is Layering Harmful?", IEEE Networks, Vol. 6, numéro 1, pp 20-24, janvier 1992.

[Diot00] C. Diot, et al., «Deployment Issues for the IP Multicast Service and Architecture», IEEE Network, janvier / février 2000.

[Deering1988] S. Deering, "Multicast Routing in Internetworks and LANs", ACM Computer Communications Review, volume 18, numéro 4, août 1988.

[Dijkstra59] E. Dijkstra, "Une note sur deux problèmes de connexion avec les graphes", Numerische Mathematik, 1, 1959, pp.269-271.

[FF1962] LR Ford Jr. et DR Fulkerson, "Flows in Networks", Princeton University Press, Princeton, NJ, 1962.

[FK02] S. Floyd et E. Kohler, "Internet Research Needs Better Models", Actes du 1er atelier sur les sujets d'actualité dans les réseaux (Hotnets-I), Princeton, NJ, USA. Octobre 2002. URL " http://www.icir.org/models/bettermodels.html ".

[IM1993] J. Ioannidis et G. Maguire Jr., "The Design and Implementation of a Mobile Internetworking Architecture", Actes de la Winter USENIX Technical Conference, pages 489-500, Berkeley, CA, USA, janvier 1993.

[IST02] Réseau de recherche en Europe - Lutte pour un leadership mondial, technologies de la société de l'information, 2002. URL " http://www.cordis.lu/ist/rn/rn-brochure.htm ".

[Jacobson88] Van Jacobson, "Congestion Evitement and Control", Actes du Symposium ACM SIGCOMM 1988, ACM SIGCOMM, Stanford, CA, août 1988. URL " http://citeseer.nj.nec.com/jacobson88congestion.html ".

[Jackson02] William Jackson, "Les États-Unis devraient financer la R&D pour des protocoles Internet sécurisés, dit Clarke", Government Computer News, 31 October 2002. URL " http://www.gcn.com/vol1_no1/security/20382-1.html " .

[Kruse00] Hans Kruse, "The Pitfalls of Distributed Protocol Development: Unintentional Interactions between Network Operations and Applications Protocols", Actes de la 8e Conférence internationale sur la conception des systèmes de télécommunication, Nashville, TN, États-Unis, mars 2000. URL " http: // www.csm.ohiou.edu/kruse/publications/ TSYS2000.pdf ".

[KLMS2000] S. Kent, C. Lynn, J. Mikkelson et K. Seo, "Secure Border Gateway Protocol (S-BGP)", Proceedings of ISOC Network and Distributed Systems Security Symposium, Internet Society, Reston, VA, février 2000.

[LD2002] E. Lear et R. Droms, "Ce qui est dans un nom: pensées du NSRG", expiré Internet-Draft, décembre 2002.

[MBFIPS01] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson et Scott Shenker, «Controlling High Bandwidth Aggregates in the Network», ACM Computer Communications Review, Vol. 32, n ° 3, juillet 2002. URL " http://www.icir.org/pushback/ ".

[MBKQ96] M. McKusick, K. Bostic, M. Karels et J. Quarterman, "Conception et mise en œuvre du système d'exploitation 4.4 BSD", Addison-Wesley, Reading, MA, 1996.

[MGVK02] Z. Mao, R. Govindan, G. Varghese et R. Katz, «Route Flap Dampening Exacerbates Internet Routing Convergence», Proceedings of ACM SIGCOMM 2002, ACM, Pittsburgh, PA, USA, août 2002.

[NV02] Commission NetVision 2012, «Plan stratégique décennal de la DARPA pour la recherche en réseau», (États-Unis) Defense Advanced Research Projects Agency, October 2002. Citation à des fins de remerciement uniquement.

[NSF02] NSF Workshop on Network Research Testbeds, National Science Foundation, Directorat for Computer and Information Science & Engineering, Advanced Networking Infrastructure & Research Division, Arlington, VA, USA, October 2002. URL " http: // www- net.cs .umass.edu / testbed_workshop / ".

[NSF03] Réunion des chercheurs principaux NSF ANIR, National Science Foundation, Arlington, VA, États-Unis. 9-10 janvier 2003, URL " http://www.ncne.org/training/nsf- pi / 2003 / nsfpimain.html".

[NSF03a] DE Atkins, et al., «Revolutionizing Science and Engineering Through Cyberinfrastructure», rapport du NSF Advisory Panel on Cyberinfrastructure, janvier 2003. URL « http://www.cise.nsf.gov/evnt/reports/ atkins_annc_020303. htm ".

[NSF03b] Rapport de l'atelier de la National Science Foundation sur la recherche fondamentale en réseautage. 24-25 avril 2003. URL " http://www.cs.virginia.edu/~jorg/workshop1/NSF- NetWorkshop-2003.pdf".

[Floyd] S. Floyd, "Papers about Research Questions for the Internet", page Web, ICSI Center for Internet Research (ICIR), Berkeley, Californie, 2003 URL " http://www.icir.org/floyd/research_questions. html ".

[RFC-1510] Kohl, J. et C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510 , septembre 1993.

[RFC-1633] Braden, R., Clark, D. et S. Shenker, «Services intégrés dans l'architecture Internet: une vue d'ensemble», RFC 1633 , juin 1994.

[RFC-2082] Baker, F. et R. Atkinson, "Authentification RIP-2 MD5", RFC 2082 , janvier 1997.

[RFC-2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210 , septembre 1997.

[RFC-2154] Murphy, S., Badger, M. et B. Wellington, «OSPF avec signatures numériques», RFC 2154 , juin 1997.

[RFC-2385] Heffernan, A., «Protection des sessions BGP via l'option de signature TCP MD5», RFC 2385 , août 1998.

[RFC-2407] Piper, D., "Le domaine d'interprétation de la sécurité IP Internet pour ISAKMP", RFC 2407 , novembre 1998.

[RFC-2501] Corson, S. et J. Macker, «Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations», RFC 2501 , janvier 1999.

[RFC-2990] Huston, G., «Next Steps for the IP QoS Architecture», RFC 2990 , novembre 2000.

[RFC-3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221 , décembre 2001.

[RFC-3234] Carpenter, B. et S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234 , février 2002.

[RFC-3424] Daigle, L. et IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424 , novembre 2002.

[RFC-3467] Klensin, J., «Role of the Domain Name System (DNS)», RFC 3467 , février 2003.

[RFC-3535] Schoenwaelder, J., «Overview of the 2002 IAB Network Management Workshop», RFC 3535 , mai 2003.

[RFC-3387] Eder, M., Chaskar, H., et S. Nag, «Considérations du Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network», RFC 3387 , septembre 2002.

[RIPE] RIPE (Reseaux IP Europeens), Amsterdam, Pays-Bas. URL " http://www.ripe.net/ripe/ ".

[Savage00] Savage, S., Wetherall, D., Karlink, AR et Anderson, T., "Practical Network Support for IP Traceback", Actes de la conférence 2000 ACM SIGCOMM, ACM SIGCOMM, Stockholm, SE, pp. 295- 306. Août 2000.

[Schiller03] JI Schiller, "Interception Technology: The Good, The Bad, and The Ugly!", Présentation à la 28e réunion NANOG, North American Network Operators Group (NANOG), Ann Arbor, MI, États-Unis, juin 2003. URL " http : //www.nanog.org/mtg-0306/schiller.html ".

[SM03] P. Sharma et R. Malpani, "IP Multicast Operational Network Management: Design, Challenges, and Experiences", IEEE Network, Vol. 17, n ° 2, mars 2003.

[SMA03] N. Spring, R. Mahajan et T. Anderson, «Quantifying the Causes of Path Inflation», Actes de ACM SIGCOMM 2003, ACM, Karlsruhe, Allemagne, août 2003.

[WD02] Walter Willinger et John Doyle, «Robustness and the Internet: Design and Evolution», non publié / Preprint, 1er mars 2002, URL « http://netlab.caltech.edu/internet/ ».

[WIDE] Projet WIDE, Japon. URL " http://www.wide.ad.jp/ ".

8. Adresses des auteurs

Conseil d'architecture Internet
Courriel: iab@iab.org
Membres du conseil d'administration de l'architecture Internet
au moment de la publication de ce document étaient:
Bernard Aboba
Harald Alvestrand (président de l'IETF)
Rob Austein
Leslie Daigle (présidente de l'IAB)
Patrik Faltstrom
Sally Floyd
Mark Handley
Bob Hinden
Geoff Huston (directeur exécutif de l'IAB)
Jun-ichiro Itojun Hagino
Eric Rescorla
Pete Resnick
Jonathan Rosenberg

Nous notons que Ran Atkinson, l'un des éditeurs du document, était membre de l'IAB au moment de la création de ce document, en novembre 2002, et que Vern Paxson, le président de l'IRTF, est membre d'office de l'IAB. .

Déclaration de droit d'auteur complète

Copyright (C) L'Internet Society (2004). Ce document est soumis aux droits, licences et restrictions contenus dans BCP 78, et sauf indication contraire, les auteurs conservent tous leurs droits.

Ce document et les informations qu'il contient sont fournis «TELS QUELS» et LE CONTRIBUTEUR, L'ORGANISATION QU'IL / S IL / S IL REPRÉSENTE OU EST PARRAINÉ PAR (LE CAS ÉCHÉANT), LA SOCIÉTÉ INTERNET ET LE GROUPE DE TRAVAIL D'INGÉNIERIE INTERNET DÉCLINENT TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS, MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DES INFORMATIONS CI-DESSUS NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE QUALITÉ MARCHANDE OU D'ADÉQUATION À UN USAGE PARTICULIER.

Propriété intellectuelle

L'IETF ne prend aucune position concernant la validité ou la portée des droits de propriété intellectuelle ou d'autres droits qui pourraient être revendiqués comme se rapportant à la mise en œuvre ou à l'utilisation de la technologie décrite dans ce document ou la mesure dans laquelle une licence en vertu de ces droits pourrait ou non être disponible; il ne prétend pas non plus avoir fait un effort indépendant pour identifier de tels droits. Des informations sur les procédures de l'IETF en ce qui concerne les droits dans les documents de l'IETF peuvent être trouvées dans BCP 78 et BCP 79.

Des copies des divulgations de DPI faites au Secrétariat de l'IETF et toute assurance de licences à rendre disponibles, ou le résultat d'une tentative faite pour obtenir une licence générale ou une autorisation pour l'utilisation de ces droits de propriété par les implémenteurs ou les utilisateurs de cette spécification peuvent être obtenus à partir du référentiel IPR en ligne de l'IETF à l' adresse http://www.ietf.org/ipr .

L'IETF invite toute partie intéressée à porter à son attention tous les droits d'auteur, brevets ou demandes de brevet, ou autres droits de propriété qui peuvent couvrir la technologie qui pourrait être nécessaire pour mettre en œuvre cette norme. Veuillez adresser les informations à l'IETF à l'adresse ietf- ipr@ietf.org.

Reconnaissance

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