Mon blog

Cet article date de 2002 mais n'a pas pris une ride : « Tussle in Cyberspace: Defining Tomorrow's Internet » de D. Clark, J. Wroslawski, K. Sollins et R. Braden est consacré à une question vitale : comment gérer les évolutions techniques de l'Internet alors qu'il y a bien longtemps que ses acteurs n'ont plus de vision commune, voire ont des visions opposées ? Contrastant avec le nombre de RFC, il existe très peu d'articles technico-politiques sur l'Internet. Ce papier est donc une lecture indispensable.

En effet, la plupart des articles parlant de politique au sujet de l'Internet se limitent à des sujets politiciens médiocres (comme la gestion de l'ICANN). Pendant que certains s'amusent dans ces petits sujets, il y a heureusement des auteurs qui s'attaquent aux vrais problèmes. Le point de départ de « Tussle in Cyberspace: Defining Tomorrow's Internet » est de considérer que l'architecture de l'Internet est le terrain sur lequel se déroulent certaines luttes (par exemple entre le FAI, qui veut dépenser le moins possible, et ses clients qui veulent avoir plus de Gb/s pour moins d'€). Et qu'il faut admettre ces luttes (tussle) comme inévitables, et se contenter d'organiser le terrain pour que ces luttes ne cassent pas tout et ne s'étendent pas à tout.

Notons que la vision « autrefois, tout le monde était gentil sur l'Internet » est largement imaginaire. Mais c'est vrai que, comme le note l'article, il y avait une époque où il existait une vision commune, un but commun (la connectivité universelle). Ce n'est plus le cas. La nostalgie ne servant à rien, il faut aujourd'hui se demander comment les gens qui travaillent à faire évoluer l'Internet doivent gérer ces luttes. Vouloir les supprimer est irréaliste (je prends ma casquette de marxiste orthodoxe pour noter que ce serait aussi idiot que de nier la lutte des classes, même si les auteurs de l'article ne citent pas ce cas). Vouloir décider leur résultat est dangereux (certaines forces en lutte sont puissantes). Les auteurs estiment donc que le rôle des ingénieurs aujourd'hui est, selon leur expression, de concevoir le terrain, pas de décider du résultat du match.

Ils donnent de nombreux exemples de ces luttes « irréductibles » (qu'on ne pourra pas supprimer par un appel à la bonne volonté). Il y a bien sûr les luttes entre les FAI et leurs clients (cf. la question de la neutralité de l'Internet). Il y a celles entre les partisans du partage de la culture et les gens de l'appropriation intellectuelle. Il y a celle entre les citoyens qui veulent communiquer de manière privée et les États (démocratiques ou dictatoriaux) qui veulent les espionner.

Pour chacun de ces cas, il y a apparemment des réponses techniques. Par exemple, on peut changer l'Internet pour faciliter les écoutes (projet NGN de l'UIT, sous le nom d'« interception légale », auquel avait répondu le RFC 1984). On peut au contraire chercher à rendre ces écoutes impossibles (en imposant IPsec systématiquement ?) Où on peut dire que ce n'est pas un problème technique, mais politique, et que les ingénieurs ne doivent pas intervenir pour imposer telle ou telle politique.

Car, c'est un point central de l'article, l'architecture technique n'est pas neutre. Elle va rendre plus ou moins facile telle ou telle politique. Si les auteurs ne citent pas Lawrence Lessig, on ne peut que penser à son fameux « The code is the law », qui disait à peu près la même chose.

Donc, les recommandations des auteurs aux gens qui font l'Internet de demain sont : méfiez-vous des systèmes trop rigides, qui craqueront forcément sous la pression de telle ou telle partie à la lutte. Concevez des systèmes souples, où des choix différents pourront être exprimés.

Un bon exemple donné dans l'article est celui du DNS. Celui-ci sert à la fois à des fonctions de nommage stable des machines et des services (pour lesquelles l'identificateur utilisé n'a pas d'importance, il pourrait être numérique) et d'expression d'une identité sur le réseau (avec des cas extrême comme Amazon.com qui utilise son nom de domaine comme nom commercial). La seconde fonction mène forcément à des conflits (tout le monde veut avoir sex.com et s'appeler du nom d'une marque est risqué). Il aurait donc été préférable de séparer ces deux fonctions, laissant la première libre de la lutte pour les noms. Cela ne résoudrait pas les nombreux problèmes posés par cette lutte mais, au moins, elle ne déborderait pas sur des fonctions opérationnelles utiles. Plus généralement, il s'agit, non pas de nier la politique (et les luttes) mais de la séparer, autant que possible (l'article est très détaillé et reconnait bien que ce n'est pas facile), de la technique.

L'article donne d'autres exemples de lutte, comme le verrouilage chez un opérateur réseau via les adresses IP. Comme renuméroter son réseau est difficile (RFC 5887), le client va hésiter à changer de fournisseur. Il est donc important que l'Internet propose des mécanismes techniques pour que les adresses ne soient pas liées à un fournisseur. Autrement, l'architecture technique bloquerait la lutte... au détriment du client.

Bref, les gens qui conçoivent des nouveaux systèmes et des nouveaux protocoles sur l'Internet devraient passer un peu de temps à analyser les luttes qui en résulteront, et à essayer des les contenir (sans tenter de les supprimer).