Ce RFC décrit une architecture nouvelle
permettant de mieux gérer les machines ayant plusieurs connexions à
l'Internet. On ne parle pas ici de gros
routeurs ou serveurs connectés à plusieurs réseaux, non, un simple
smartphone qui a à la fois
le WiFi et la 4G est un
exemple d'une machine qui a plusieurs interfaces. Et cela pose des
sérieux problèmes avec l'Internet d'aujourd'hui, car, parfois, chaque
interface va nécessiter des réglages différents. Notre nouvelle
architecture aborde ce problème en définissant le
PvD (ProVisioning Domain ou
domaine d'avitaillement), un ensemble cohérent de réglages, qui sera
attaché à chaque interface.
Pourquoi est-ce un problème d'avoir plusieurs interfaces actives ?
Car certains réglages ne sont valables que pour une seule interface,
alors que TCP/IP considérait au début que
toutes les interfaces se valaient et pouvaient être utilisées. Par
exemple, l'adresse IP obtenue sur une interface
ne doit pas être utilisée comme adresse IP source sur une autre
interface, de peur de se faire mordre par le . Le résolveur DNS obtenu sur une
interface ne doit pas être utilisé pour une autre car il refusera
probablement de répondre (). Et, même si
les résolveurs DNS acceptaient tous les clients, il arrive qu'ils
renvoient des données qui ne sont pas les mêmes pour tout le monde
(par exemple pour un serveur qui n'est accessible que depuis un
certain réseau). Le décrit plus en
détail le problème des interfaces multiples, et le proposait déjà quelques solutions, chacune spécifique à
une plate-forme donnée. Pour résumer (à
l'extrême) le , les risques sont :
Incohérence entre les informations obtenues depuis les
différentes interfaces (comme dans l'exemple DNS ci-dessus),Risque de mélanger les informations obtenues sur différentes
interfaces (tenter de résoudre le nom d'un
relais avec le serveur DNS d'un autre
opérateur...),Usage non conforme à la politique d'un des réseaux (par exemple,
téléchargement d'un jeu via le VPN de
l'entreprise...)
Donc, pour résoudre ce genre de problème, on introduit le concept
de PvD. Mais c'est quoi, un PvD (section 2) ? Un ProVisioning
Domain est simplement un ensemble cohérent d'informations de
configuration d'un réseau, pour une interface donnée. Cela comprend
par exemple l'adresse IP à utiliser (ou le préfixe IP), les adresses IP
des résolveurs DNS, le
routeur par défaut, le
proxy Web à utiliser,
etc. Une machine PvD-aware sait gérer cette
information (notamment en l'association à une interface et en gardant
en mémoire que, par exemple, ce résolveur DNS est fait pour cette
interface). Une application PvD-aware a du code
pour gérer la coexistence de différents PvD.
Aujourd'hui, les PvD sont implicites. La
machine connectée reçoit de l'information de configuration sur chaque
interface, via des processus divers (DHCP, mais
pas seulement), et cette information n'est pas groupée, sous
l'étiquette d'un PvD donné. C'est à la machine
PvD-aware de gérer une table de PvD en les nommant
et en les associant à chaque interface. Par défaut, avec les PvD
implicites, une interface = un PvD.
Mais il y aura plus tard des PvD
explicites. Cette distinction entre PvD
implicites et explicites est essentielle. L'idée est de développer via
l'IETF des
mécanismes (comme celui du ) pour communiquer à la machine
des PvD explicites, regroupant sous un nom donné un jeu d'informations
de configuration cohérentes. Par exemple, on peut imaginer une option
DHCP qui indique le nom du PvD correspondant aux options de
configuration contenues dans cette réponse DHCP (ce n'est qu'une
hypothèse : le RFC liste d'autres possibilités, cf. section 3). Avec les PvD
explicites, il n'y aura plus forcément une interface = un PvD. On
pourra avoir plusieurs interfaces utilisant le même PvD (si elles sont
gérées par la même organisation).
Cela impliquera un système (non encore défini) de nommage des
PvD. Le « PvD ID » devra être unique (puisque le but est de
différencier les informations de configuration de réseaux différents),
par exemple en le tirant au hasard dans un espace de grande taille. Le
PvD ID ne sera donc pas forcément lisible par un humain ; si on veut
une telle lisibilité, il faudra développer une solution, par exemple
de métadonnées associées au PvD.
Un PvD peut être commun à plusieurs familles IP (par exemple
IPv4 et IPv6) et
comporter donc plusieurs adresses. C'est utile si certaines options
ont un sens pour plusieurs familles (c'est le cas de la politique de
sélection de l'adresse du ). Pour les
PvD implicites, utiliser un seul PvD pour toutes les familles
présentes sur l'interface est la politique recommandée.
La section 3 examine quelques protocoles existants pour voir
comment ils pourraient être modifiés pour transporter de l'information
explicite sur les PvD. Aujourd'hui, la configuration des machines
terminales est
faite en général par DHCP () ou
RA (). Notons qu'elles ne sont
pas sécurisées par défaut. Des solutions existent pour authentifier la
machine qui émet la réponse DHCP ou RA mais authentification n'est pas
autorisation : elle ne nous dit pas si cette machine est autorisée à
annoncer explicitement tel PvD. Pour cela, il faudrait un moyen de
signer les PvD.
Évidemment, si on ajoute des mécanismes de PvD à ces protocoles,
cela devra être fait d'une manière compatible avec les machines
existantes, qui ne sont pas PvD-aware. Pendant la
phase de coexistence, il faudra peut-être dupliquer de l'information
dans les réponses DHCP ou RA, pour satisfaire tout le monde.
La section 4 du RFC présente trois études de cas concrètes. La
première est celle d'une machine mobile, un
smartphone, par exemple. Il
a une interface avec un réseau mobile, mettons
3G, et une interface
WiFi. S'il est dehors, loin de tout
hotspot, il n'aura qu'une
interface active et donc un seul PvD : pas de difficultés. S'il
s'approche d'un point d'accès WiFi et s'y connecte, le dilemme
commence : quelle interface utiliser ? Android,
par exemple, ne peut en utiliser qu'une à la fois et va donc cesser
d'utiliser la 3G. Cela simplifie le modèle de connexion pour les
développeurs mais n'est pas satisfaisant pour l'utilisateur. Il
serait plus satisfaisant de pouvoir utiliser les deux, mais en
respectant à chaque fois le PvD (qui peut être différent) de chaque interface.
Autre étude de cas, un VPN, qui peut être
considéré comme une interface supplémentaire, quoique virtuelle, et un
réseau à la maison, connecté à la fois à un FAI
généraliste classique et à un service de
VoD, avec une interface séparée qu'on n'utilise
que pour la vidéo, et qui est donc décrite par un PvD différent.
La section 5 de notre RFC étudie plus en détail certains points
spécifiques qui doivent être traités par un nœud
PvD-aware. Par exemple, la résolution de noms, déjà
citée plus haut, qui dépend fortement du PvD : un résolveur DNS n'est
typiquement utilisable que par certains clients, et pas par le monde
entier. En outre, les résultats d'une résolution de noms peuvent
varier selon le résolveur interrogé (cas d'un service spécifique à un
FAI, par exemple le MMS). La machine doit donc savoir quel PvD utiliser pour
chaque nom, avec des règles du genre « pour tous les noms se terminant
en ma-boîte.example, se servir du résolveur DNS
du PvD du VPN de ma boîte ». Si plusieurs PvD
correspondent à des FAI généralistes, pouvant servir pour tout accès à
un serveur public, la machine PvD-aware peut faire
les résolutions de noms en parallèle, et prendre le plus rapide, selon
un approche identique à celle des globes oculaires heureux du .
Et puisqu'on parle de sélectionner le « meilleur » PvD, il faut
rappeler que la connectivité au réseau local, tel qu'elle s'obtient
lorsqu'une requête DHCP ou RA a réussi, ne garantit pas un bon accès à
tout l'Internet. Le signal local peut être fort, le serveur DHCP très
réactif... et la connexion ultérieure échouer. Il est donc prudent de
tester les connexions obtenues, par exemple en essayant de se
connecter à un amer bien connu.
On a vu qu'une application pouvait être
PvD-aware si elle sait utiliser l'information sur
les PvD pour prendre des décisions. La section 6 décrit les propriétés
attendues de l'API qui permettra de développer
ces applications. Dans le cas le plus simple, une application
PvD-aware peut se limiter à n'utiliser qu'un seul
PvD. C'est le cas d'une application MMS qui
dépend d'un opérateur particulier et qui devra donc passer par
l'interface correspondante. Un peu plus complexe serait une
application qui exprime des exigences et des préférences, du genre
« il me faut IPv6 » ou
« je fais de la vidéo-conférence, je veux une
faible latence » ou bien « je suis
paranoïaque, je ne veux passer que par un PvD cité dans telle liste » ou encore « je ne suis pas
pressé, il vaut mieux utiliser la connexion la moins chère ». Le
système pourrait alors choisir, en regardant les informations obtenues
pour chaque PvD, quel PvD utiliser. Dans le dernier cas (une
application qui télécharge beaucoup, comme la mise à jour du
système d'exploitation, ou comme une
application pair-à-pair d'accès à la culture), un mécanisme de
sélection automatique via le PvD simplifierait nettement la tâche de
l'utilisateur en le dispensant d'options comme la « n'utiliser qu'avec
la WiFi » qu'on trouve souvent sur les applications
Android, qui veulent éviter de faire exploser
le forfait de téléphonie mobile.
Enfin, les applications les plus avancées pourraient simplement
obtenir la liste des PvD et leurs caractéristiques et faire leurs
choix elles-mêmes. Ces choix ne seront pas forcément respectés par le
système, qui peut avoir ses propres exigences (par exemple forcer la
passage par le VPN de l'entreprise pour les connexions aux services de
la dite entreprise).
Puisqu'on a parlé de sécurité (« je suis paranoïaque, je ne veux
passer que par un PvD cité dans telle liste »), un mot sur les PvD de
confiance ou pas (section 7). Par défaut, un PvD n'est pas « de
confiance ». Si je me promène dans la rue et que je me connecte à un
hotspot inconnu, le PvD
associé ne sera pas considéré comme de confiance. Certains systèmes ou
applications ne voudront se connecter à tel service que via un PvD de
confiance. Mais attention : supposons qu'on ait une telle liste (le
PvD du VPN de la boîte, le PvD d'un opérateur à qui on fait confiance,
le réseau local à la maison...), il ne faut pas pour autant considérer
que le PvD est ce qu'il annonce. Si le PvD de l'entreprise est
6a97f31e-34ec-4ef9-ba75-b1e3addd8222 (ce n'est
pas la vraie syntaxe des PvD ID, qui n'est pas encore décidée), et que
le serveur DHCP du hotspot annonce ce PvD ID, il ne
faut pas pour autant lui faire confiance (voir aussi la section 8). Un
PvD de confiance nécessite deux choses : une relation de confiance
avec son opérateur, et un moyen de vérifier qu'il s'agit bien du PvD
attendu. Ce moyen d'authentification peut
passer par une signature du PvD ID, ou bien
simplement par le mécanisme d'attachement au réseau : on peut décider
que, si on est connecté à un réseau physique stable et sûr, l'annonce
du PvD ID sur ce réseau peut être crue. À noter que le RFC fournit un
autre exemple, où on fait confiance au réseau d'un opérateur mobile,
ce qui ignore le risque des
IMSI-catchers.
La section 8 revient d'ailleurs sur les problèmes de
sécurité. Par exemple, même si le serveur DHCP ou RA est sûr, un
attaquant a pu modifier les données en cours de route. On peut
utiliser les techniques (très peu déployées en pratique) de l'option
AUTH du
(abandonnée depuis, dans le ), section
22.11, ou le
SEND du .