T. Paila (Nokia)R. Walsh (Tampere University of Technology)M. Luby (Qualcomm)V. Roca (INRIA)R. Lehtonen (TeliaSonera)November20122012-11-07
Peut-on envoyer un fichier d'un ordinateur à un autre lorsque la
liaison est unidirectionnelle, c'est-à-dire que
les paquets ne voyagent que dans un sens ? Pas
question de se servir de FTP ou de
HTTP, qui reposent sur le protocole de
transportTCP, qui a besoin de bidirectionnalité (car il
dépend du retour des accusés de réception). Le protocole
FLUTE (File Delivery over Unidirectional Transport) normalisé dans ce
RFC, fournit un ensemble de mécanismes pour
effectuer ce transfert. La principale application concerne le
multicast, où une machine
unique diffuse un fichier à plusieurs autres, qu'elle ne connait pas
forcément et qui ne peuvent pas lui écrire. Un exemple typique est la
distribution des mises à jour d'un gros logiciel à des milliers, voire
millions, de machines dans le monde. Parmi les usages possibles, distribuer de la vidéo, une nouvelle version d'un jeu très
populaire, etc.
Pour cela, FLUTE s'appuie sur le système
ALC () + LCT (Layered Coding Transport, ), qui fait l'essentiel
du travail. ALC+LCT sert de protocole de transport d'objets binaires, FLUTE se charge de la
sémantique. FLUTE dépend aussi d'autres protocoles de la famille
multicast,
comme
FEC (), qui assure la
fiabilité du transport, en permettant au récepteur de détecter les erreurs.
Transférer des gros fichiers sur un réseau ouvert comme l'Internet implique également un mécanisme de
contrôle de la congestion, pour éviter que
l'émetteur ne noie le réseau sous les paquets, sans se rendre compte
que les tuyaux sont pleins. Comme on n'a pas
TCP pour limiter la congestion en détectant les
paquets perdus, il faut trouver un autre mécanisme. Dans le cas de
FLUTE, les récepteurs souscrivent plusieurs abonnements
multicast, éventuellement de débits différents, et
jonglent avec ces divers abonnements. (Sur des réseaux
fermés, le contrôle de congestion de FLUTE peut se faire par encore d'autres
mécanismes comme le shaping.)
Les métadonnées (les propriétés du fichier) sont transmises dans un élément
XML. On y trouve entre autres :
Un identifiant du fichier, un URI. C'est
juste un identifiant, et rien ne garantit qu'on puisse récupérer le
fichier à cet « endroit ».Un type de contenu, par exemple
text/plain.La taille du fichier.Un encodage utilisé pendant le transport, par exemple la
compression avec zlib ().D'éventuelles informations de sécurité comme une
empreinte cryptographique ou une
signature numérique.
L'élement XML <File> qui contient tout cela
est mis ensuite dans un élément
<FDT-Instance> (FDT = File
Delivery Table) qui contient également les informations
externes au fichier (comme la date limite pendant laquelle
cette information sera valable). Voici
l'exemple que donne le RFC, pour le fichier track1.mp3 :
]]>
Cet élément XML est transmis avec le fichier. Les informations liées à l'émission du
fichier (adresse IP source qui émettra le fichier, début de
l'émission, etc) sont récupérées par le destinataire par un moyen non
spécifié ici (cf. section 6). Cela a pu être une description
SDP (), une ressource sur le
Web ou bien d'autres méthodes, même une configuration manuelle. Le
point important est que, une fois toutes ces informations en sa
possession, le récepteur FLUTE peut se préparer à recevoir le fichier,
et peut vérifier sa bonne délivrance (l'émetteur, lui, n'en saura
rien, puisque la liaison est unidirectionnelle).
L'envoi unidirectionnel de fichiers soulève des problèmes de
sécurité particuliers (section 7, très détaillée). Si le fichier transmis est
confidentiel, il doit être chiffré avant, que
ce soit par un chiffrement global du fichier (par exemple avec
PGP) ou en route par
IPsec.
Et si l'attaquant veut modifier le fichier ? On peut utiliser une
signature numérique du fichier, avant son envoi
ou bien, pendant le trajet
authentifier les paquets ALC avec le ou bien
TESLA (Timed Efficient Stream Loss-Tolerant Authentication, et )
ou encore, là aussi, IPsec. À noter que certaines de ces techniques
demandent une communication bidirectionnelle minimale, par exemple
pour récupérer les clés publiques à utiliser.
Ce RFC est la version 2 de FLUTE, la version 1 était normalisée
dans le , qui avait le statut expérimental. Avec ce
nouveau document, FLUTE passe sur le chemin des normes
IETF. La liste des changements importants
figure en section 11. Notez tout de suite que FLUTE v2 est un
protocole différent, incompatible avec FLUTE v1.
Je ne connais pas les implémentations de FLUTE mais il en existe
plusieurs (pour la version 1) par exemple jFlute, l'ancien MCL v3 (plus maintenue en
version libre mais Expway en a
une version commerciale fermée) ou
MAD-FLUTE fait à l'université de Tampere.