1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
Titre: RFC 7971: Application-Layer Traffic Optimization (ALTO) Deployment Considerations
Auteur:
Date: Tue 22 Nov 2016 01:00:00 +0100
Lien: https://www.bortzmeyer.org/7971.html
Il est fréquent aujourd'hui sur l'Internet qu'une application cherche à accéder
à un contenu (mettons un film, ou bien la mise à jour d'un gros logiciel) qui
est disponible à plusieurs endroits. Dans ce cas (qui est notamment fréquent
pour le téléchargement en pair-à-pair), quelle source utiliser ? La
« meilleure », bien sûr, mais comment la connaître ? Le but du protocole ALTO
est de permettre de distribuer de l'information sur la topologie du réseau,
afin que les applications puissent choisir la source la plus proche d'elles.
ALTO est déjà normalisé (RFC 7285), ce nouveau RFC sert juste à décrire les
scénarios d'usage et à donner des conseils pratiques de déploiement
(déploiement qui semble très limité pour l'instant).
Outre le RFC décrivant le protocole (RFC 7285), il peut être utile de lire la
description du problème qu'ALTO veut résoudre, le RFC 5693, et le cahier des
charges, dans le RFC 6708.
La section 2 de notre RFC résume le fonctionnement d'ALTO. C'est un protocole
client-serveur, le serveur ALTO connait l'information (la topologie du réseau,
qui est connecté à qui, par quel genre de liens), le client est l'application
qui veut accéder au contenu, il connait un ensemble potentiel de sources, et il
veut savoir quelle est la « meilleure ». Par exemple, dans le cas de
BitTorrent, le client a les adresses IP de l'essaim, il veut savoir à laquelle
ou lesquelles demander les bouts de fichier (chunks) qui forment le contenu. Le
client ALTO peut être un processus séparé, tournant en permanence, ou bien une
bibliothèque liée à l'application. Il doit évidemment parler le protocole ALTO,
donc connaitre HTTP et JSON.
Pour déployer ALTO, il y a donc quatre entités logiques à considérer :
* L'origine de l'information (celle qui a compilé les informations de
topologie, par exemple en commençant par lister les préfixes IP connus),
* Le serveur ALTO, qui va distribuer cette information,
* Le client ALTO, qui va la récupérer,
* L'application (resource consumer, dans le RFC), qui va en faire quelque
chose d'utile.
Ces entités sont typiquement gérées par des organisations différentes. Un
exemple typique (mais ce n'est pas la seule possibilité) est que le FAI soit à
l'origine de l'information (il connait son réseau), et la mette dans un serveur
ALTO qu'il gère, ses abonnés ayant installé une application de partage de
fichiers qui inclut un client ALTO. Dans ce cas, il y aurait deux
organisations, le FAI gérant les deux premières entités et l'abonné les deux
dernières. Mais d'autres répartitions peuvent exister.
Les organisations qui peuvent être impliquées sont en effet multiples : FAI et
opérateurs réseau, bien sûr, utilisateurs, évidemment (agissant, soit seuls,
soit en groupes se répartissant le travail), mais aussi des tiers, spécialisés
dans la collecte et la distribution de cette information (par exemple des CDN).
On pourrait même voir apparaitre des sociétés qui ne font que de l'ALTO.
Tout ceci a des conséquences sur le déploiement. Par exemple, un utilisateur
peut faire confiance à un FAI mais pas à des tiers. Un FAI peut souhaiter
distribuer de l'information à ses abonnés mais pas à tout l'Internet. ALTO
définit un protocole, pas une politique : ce protocole permet différents
modèles, y compris celui de serveurs ALTO spécialisés et payants. Autre
conséquence de l'utilisation de telle ou telle répartition du travail, on
pourrait avoir des serveurs ALTO partiels, qui ne contiennent de l'information
que sur certains réseaux.
Dans tous les cas, le RFC rappelle qu'ALTO est juste une optimisation : une
application doit fonctionner même si elle ne trouve aucun serveur ALTO, ou bien
s'ils sont en panne.
Un petit rappel utile sur ALTO : il existe deux modes de fonctionnement
différents, qui ont tous les deux des conséquences importantes, notamment sur
la confidentialité. Dans le premier mode, le serveur ALTO fournit l'information
qu'il a (sous forme de maps, des ensembles de données sur le réseaux, les
liens, leur coût, etc) et le client cherche dedans ce qui l'intéresse. Ce mode
préserve la vie privée du client (qui ne dit pas au serveur ce qui l'intéresse)
mais pas celle du serveur (qui doit tout envoyer). Il n'est pas évident que
beaucoup de FAI acceptent cela. Dans le second mode, le serveur permet des
interrogations sur un point particulier (« qui est le plus proche de moi ?
192.0.2.87, 203.0.113.122 ou bien 198.51.100.20 ? »). Ce mode évite au serveur
de tout divulguer mais oblige en revanche le client à révéler ses intentions
(ici, les adresses IP des pairs potentiels, ce qui peut intéresser des
organisations répressives comme la HADOPI). Notez que la fuite d'informations
du serveur existe aussi dans le second mode : plusieurs clients ALTO peuvent
coopérer pour poser beaucoup de questions et extraire ainsi une partie
substantive de la base.
La partie 3 de notre RFC en vient aux conseils concrets pour les FAI. On
considère que l'objectif du FAI est de minimiser ses coûts, donc a priori de
garder le maximum de trafic en local (il y a des exceptions, que liste le RFC).
Le serveur ALTO que gère le FAI va donc annoncer des coûts plus faibles pour
les liens locaux.
Mais, d'abord, le FAI doit « remplir » le serveur ALTO avec de l'information.
Cette étape d'avitaillement commence par la récolte d'informations sur le
réseau. A priori, le FAI connait son propre réseau, et n'a donc pas de mal à
récolter ces informations. Outre sa propre documentation interne, le FAI peut
aussi utiliser de l'information issue d'autres sources, par exemple les
protocoles de routage comme BGP (cf., entre autres, le RFC 7752) ou bien des
mesures actives ou passives (cf. entre autres, le RFC 7491). Rappelez-vous
qu'ALTO est uniquement un protocole permettant d'accéder à de l'information sur
la topologie. Comment cette information a été récoltée et agrégée n'est pas de
la responsabilité d'ALTO, de même que le protocole HTTP ne se soucie pas de
comment est fabriquée la page HTML qu'il sert.
Le FAI doit ensuite appliquer ses critères (coût, performance, etc) à la
topologie. Ces critères sont forcément imparfaits. Le client ALTO ne doit pas
s'attendre à ce que l'information qui lui est donnée soit idéale dans tous les
cas. Par exemple, le serveur ALTO peut indiquer un lien rapide et pas cher mais
qui, au moment où le téléchargement commencera, sera saturé par un trafic
intense (ALTO ne prétend pas être temps-réel). Et il y a bien d'autres choses
qui ne seront pas connues de ceux qui ont compilé l'information, ou bien qui
n'auront pas été incluses dans la base de données du serveur ALTO (« la carte
n'est pas le territoire »). Les données distribuées par ALTO, les maps, sont
supposées être relativement statiques. Mais, dans le monde réel, les choses
changent et le client recevra donc peut-être une information légèrement
dépassée.
Si vous trouvez le concept de map un peu abstrait, la section 3.5 du RFC donne
plusieurs exemples. Par exemple, dans le cas le plus simple, celui d'un petit
FAI ayant un seul opérateur de transit, les adresses dudit FAI seront dans le
PID (Provider-defined IDentifier, cf. RFC 7285, section 5.1) 1, tout le reste
de l'Internet étant le PID 2. Cela donnera une map (syntaxe décrite dans le RFC
7285, section 9.2) :
{
...
"network-map" : {
"PID1" : {
"ipv4" : [
"192.0.2.0/24",
"198.51.100.0/25"
],
"ipv6" : [
"2001:db8:100::/48"
]
},
"PID2" : {
"ipv4" : [
"0.0.0.0/0"
],
"ipv6" : [
"::/0"
]
}
}
}
Un FAI plus gros, et à la topologie plus complexe, a plein de possibilités. Par
exemple, ses propres réseaux peuvent être dans des PID différents, s'il veut
pouvoir garder le trafic local à un de ses réseaux. Un exemple est celui où le
même FAI a des abonnés fixes et mobiles, et où on souhaite limiter les
transferts des abonnés fixes vers les mobiles, pour réduire l'utilisation des
liens hertziens.
Reste ensuite à effectuer le déploiement des serveurs ALTO. Il existe plusieurs
mises en œuvre logicielles d'ALTO et des compte-rendus d'expérience figurent
dans les Internet-Draftsdraft-seidel-alto-map-calculation[1] et
draft-lee-alto-chinatelecom-trial[2] et dans le RFC 6875 (ainsi que, pour un
protocole antérieur à ALTO, dans le RFC 5632). Cette expérience montre que
certaines façons de collecter l'information peuvent être coûteuses : si un FAI
a plusieurs liens avec l'Internet, et reçoit un flux BGP complet, et veut
mettre chaque préfixe de la DFZ dans ses maps, il doit prévoir des machines
assez costaud pour traiter cette information importante et assez changeante. Et
le résultat serait une map qu'il serait difficile d'envoyer à tous les clients,
vu sa taille. Il faut donc prévoir, dans ce cas extrême, de l'agrégation
vigoureuse des préfixes IP.
La section 4 de notre RFC couvre ensuite l'utilisation d'ALTO, une fois qu'il
est déployé. Normalement, tout le monde a intérêt à ce que ALTO soit utilisé :
le FAI veut que les utilisateurs épargnent les liens réseaux les plus lents et
les plus coûteux et les utilisateurs veulent les meilleures perfomances. En
théorie, tout le monde trouvera son intérêt à utiliser ALTO.
Un exemple est celui de BitTorrent. Si les pairs BitTorrent incluent un client
ALTO, chaque pair, quand il reçoit une liste d'adresses IP de l'essaim, peut
alors interroger le serveur ALTO et trouver les « meilleurs » pairs. Ils
peuvent même échanger cette information entre eux (PEX, Peer EXchange, dans le
monde BitTorrent). Mais une autre possibilité est que ce ne soient pas les
pairs qui interrogent le serveur ALTO mais le tracker (pour les essaims
fonctionnant avec une machine qui sert de tracker, ce qui n'est pas toujours le
cas). Ainsi, il n'est pas nécessaire de mettre un client BitTorrent dans chaque
pair, c'est le tracker qui, grâce à l'information ALTO, choisit les meilleurs
pairs pour chacun, et ne leur envoie que cela.
Le RFC se conclut pas une section 7 sur la sécurité. Parmi les problèmes à
considérer, il y a le fait qu'un serveur ALTO malveillant, ou bien un serveur
se faisant passer pour un serveur ALTO légitime, peut empoisonner le client
avec de fausses données.
Liens:
[1]: https://datatracker.ietf.org/doc/draft-seidel-alto-map-calculation (lien)
[2]: https://datatracker.ietf.org/doc/draft-lee-alto-chinatelecom-trial (lien)
|
