Similairement à ce que nous trouvions sur IPv4, en cette période épique où le Loose Source and Record Route fonctionnait encore sur IPv4, tel que défini par la RFC 791, IPv6 nous propose un source routing dont le principe est relativement simple. Votre but est de faire acheminer un paquet de S à D en passant par plusieurs routeurs de transit, disons A, B et C. Vous commencez donc par construire un premier paquet, à destination de votre premier point de passage, A. Maintenant, l'entête de routage, le fameux routing header, va vous permettre de compléter le chemin. Vous le remplissez avec un tableau d'adresses IP dont la dernière est évidemment votre destination et un pointeur vers la première adresse de votre tableau. Vous y placez donc les adresses de B, C et D et un pointeur désignant B. Vous émettez votre paquet qui fait son bonhomme de chemin et atteint A. Ce dernier voit le routing header, suit le pointeur et découvre la nouvelle destination du paquet. Il remplace alors la destination du paquet par B, et l'adresse de B par celle de A dans le tableau. Enfin, il modifie le pointeur pour qu'il désigne à présent le point de passage suivant, donc C, et envoie le paquet. Ce dernier va alors passer par B puis par C, lesquels effectueront le même traitement. Il atteindra enfin sa destination finale D.

Lorsque je présente cette option en cours, qu'il s'agisse de la version IPv4 ou IPv6, la question qui revient le plus souvent porte sur l'aspect Record Route. Si on comprend maintenant bien le Loose Source, ce dernier aspect est moins clair. Si on observe le paquet tel qu'il est reçu par la destination, on constate que le tableau d'adresses IP est encore présent et contient des adresses. En fait, les adresses de chaque nœud de transit par lesquelles on lui avait demandé de passer, du premier routeur A au dernier C. La destination a donc ainsi un enregistrement des points de passage du paquet. D'où le Record Route.

Quels sont les problèmes posés par ce type de fonctionnalité ? On peut les séparer en deux catégories. Il y a d'abord ceux qui découlent du fait de pouvoir imposer un trajet à un paquet. Lorsqu'un réseau IP fonctionne normallement, c'est le réseau qui décide du chemin du paquet, et le plus souvent de manière optimale. Le réseau est conçu pour fournir ce service au moyen de divers protocoles de routage si besoin est. Permettre à la source de choisir le chemin du paquet permet de contourner tout ceci. L'application la plus évidente est le déni de service par saturation entraîné par un ping-pong imposé entre deux nœuds, deux routeurs par exemple. Si vous envoyez des paquets à qui vous imposez dix aller-retour entre ces deux routeurs, vous allez charger le lien du fait de l'effet capacitif de cette attaque : les derniers paquets que vous émettez arrivent alors que les premiers n'ont toujours pas fini leur ping-pong. Vous obtenez donc un effet d'amplification vous permettant de créer entre ces deux routeurs un trafic nettement supérieur à celui dont vous disposez sur votre propre ligne.

Toujours dans la série du choix du chemin, vous pouvez vous amuser à jongler avec vos paquets. En envoyant des boomerangs, c'est à dire des paquets dont le chemin imposé va finalement revenir à leur source, vous chargez artificiellement le réseau. Application ? Le stockage de données dans le réseau dans la veine de ce qu'avaient imaginé Wojciech Purczynski et Michal Zalewski dans leur papier "Juggling with packets"[1]. Si vous arrivez à induire un délai suffisament long entre l'émission et le retour de votre paquet, alors vous allez pouvoir stocker dans le réseau une quantité de données dépendant directement de la MTU minimale et de la bande passante maximum du chemin choisi. Je répète : du chemin choisi. Comme vous imposez le chemin, vous maîtrisez également quelques paramètres vous permettant d'optimisez le mécanisme à votre avantage, c'est à dire maximisez l'effet parasite.

Autres applications intéressantes, les traceroutes distants. En combinant la technique du traceroute et le source routing, vous pouvez effectuer des traceroutes telles que les ferait un nœud lambda du réseau. Il vous suffit d'imposer un passage par ce nœud. Si on avance un peu peu plus sur cette piste, on peut également se servir de tels points de passage pour atteindre de ressources distribuées géographiquement. On pensera évidemment à l'exemple mentionné par Arnaud et Phil, à savoir les serveur DNS, mais on peut également penser à des services comme Akamai, de manière à atteindre un miroir précis de n'importe quel point de la planète.

La seconde catégorie de problèmes est induite par la l'implémentation de cette formidable fonctionnalité. Si on suit la RFC à la lettre, tous les nœuds, hôtes ou routeurs, doivent l'implémenter et traiter les paquets qui l'utilisent. Ce qui veut dire en substance que n'importe quelle machine sur Internet peut vous servir de rebond, quel que soit son rôle : routeur, firewall, serveur SMTP, serveur web, station de travail, etc. Supposons la situation suivante : vous avez une DMZ avec un serveur Web accessible depuis Internet et un serveur de base de données qui, lui, ne l'est pas. Le source routing va vous permette d'atteindre le serveur Web dans un premier temps et, dans un second, de rebondir vers le serveur de base données. Vous contournez ainsi le filtrage de paquets mis en place au niveau du firewall, lequel aura vu passer un paquet à destination du serveur Web. Pas top...

L'implémentation induit également une autre subtilité, qui est très bien décrite dans ce que beaucoup, moi compris, considèrent comme la référence en terme d'ouvrages sur les firewalls. Les paquets routés par la source, lorsqu'ils atteignent un nœuds, ne sont pas routés, ils sont traités. C'est ce qui explique que votre serveur Web de l'exemple au dessus route le paquet bien que n'ayant pas de fonctionnalité de routage activée. Mais cela va un peu plus loin que cela. Lorsqu'on configure un firewall, on s'attache surtout aux règles concernant les paquets qu'on route. Or ces paquets ne sont pas routés ! Les règles précédentes ne s'appliquent donc pas à ces paquets... Évidemment, là, on entre dans le domaine de l'implémentation et de la configuration qui rend les plate-formes inégales devant ce problème. En outre, certaines prennent à présent en compte cette subtilité, ce qui va aider. Ce soucis a donc une portée relativement réduite, et bien heureusement.

Devant tous ces problèmes qui existaient déjà sur IPv4, la communauté avait doucement, mais sûrement, banni le source routing de l'Internet v4. Les nœuds arrivent à présent avec cette fonctionnalité désactivée par défaut et la plupart ne traitent pas les paquets munis de cette option, quand bien même ils ne leur seraient pas destinés[2]. Cette fonctionnalité a donc pratiquement disparu du monde IPv4, pour les raisons évoquées ci-dessus. D'où la double surprise pour IPv6 : une première fois quand on constate que le mécanisme est encore là et une seconde lorsqu'on voit qu'il est activé partout.

IPv6 arrive en effet avec ce mécanisme de source routing activé par défaut... Deux différences majeures. IPv6 n'ayant pas d'options, il prend la forme d'un nouvel entête, le Routing Header. Je ne vais pas décrire ici le mécanisme d'extension de l'entête IPv6 sinon qu'il fonctionne par chaînage d'entêtes supplémentaires spécifiques aux fonctionnalités qu'on veut ajouter, parmi lesquelles notre Routing Header qui fonctionne de façon similaire à l'option LSRR d'IPv4. Ensuite, le mécanisme d'échange entre l'adresse destination du paquet et le tableau de nœuds qui n'est pas présent dans IPv4 dont l'adresse destination est l'adresse finale tout au lon du chemin, ce qui rend le mécanisme à la fois plus puissant en terme de contournement de firewall et moins flexible dans la mesure où un nœuds n'implémentant pas le source routing ne peut pas vous servir de hop, contrairement à IPv4 où l'hôte peut forwarder normallement le paquet en ignorant l'option. Et ce mécanisme de source routing est non seulement implémenté, comme sur toutes les piles IPv4, mais aussi, plus grave, activé par défaut et surtout, utilisable sur les routeurs comme sur les hôtes. Ce qui permet d'appliquer toutes les joyeusetés décrites précédemment au contexte IPv6, même un peu plus... En général, la réponse qui vient à ce moment là, c'est "mais on s'en fout, personne n'utilise IPv6", ce qui n'est pas loin d'être faux. Mais repensons le problème autrement. L'Internet IPv6 est en fait supporté par l'architecture IPv4. Soit les liens sont nativement partagés entre IPv4 et IPv6, soit on encapsule l'IPv6 dans de l'IPv4. Si on reprend l'exemple de l'attaque par saturation, non seulement elle va perturber le lien IPv6, mais également le trafic IPv4 qui y transite. En outre, quelques vrais bon gros dénis de service ont été trouvés dans le traitement de ces headers qui vont permettre, en ciblant des nœuds supportant les deux protocoles, d'induire des effets sur l'Internet IPv4. Bref, pas top.

Un excellent article décrivant la problématique de manière plus précise est proposé par Geoff Huston pour The ISP Column de mai. Si vous voulez entrer un peu plus dans le détail, mettez la lecture de ce billet en pause pour une vingtaine de minutes et allez le lire. Vraiment.

Évidemment, les discussions vont bon train et prennent du temps, les avis variant entre maintenir le mécanisme[3], le désactiver par défaut jusqu'à le supprimer purement et simplement, dernière proposition qui semble prendre peu à peu les devants. Ouf...

Tout ce bruit ne m'inspire finalement pas grand chose, sinon un simple constat. Malgré le fait que les dangers du source routing soient connus depuis longtemps, que pas mal de gens aient soulevé le problème ça et là, y compris pour IPv6[4], la fonctionnalité a été conservée. Pourquoi ? Bonne question. Mais si on regarde plus loin, on se rendra compte que des gens qui se sont montrés relativement aggressifs durant les discussions qui ont suivi Cansec n'en ont pas moins implémenté le source routing au pied de la lettre dans leur couche IPv6, donc sans vraiment se poser de question...


Sinon, l'atterrissage à Paris hier soir, aux alentours de 18h15, était particulièrement... intéressant. Après une approche manquée sur Orly vers 18h30, l'appareil s'est fait dérouté sur Charles-de-Gaulle où nous avons bien passé une heure sur le tarmac le temps que ça se calme un peu et que les équipes puissent à nouveau accéder aux pistes pour nous amener une passerelle. Ça faisait longtemps que je n'avais vu une hôtesse redistribuer une vingtaine de sac en papier à l'arrière...

Newsoft me fait remarquer que la fourniture d'accès Wi-Fi commerciale est à présent reconnue comme telle. Finie l'exonération de taxe pour les opérateurs due au caractère expérimental[5] de la technologie. Maintenant, il faudra s'acquitter d'une taxe de vingt-mille euros, mais seulement si votre chiffre d'affaire dépasse le million d'euros. Ce qui ne devrait pas toucher grand monde, et en tout cas pas les réseaux communautaires.

Sinon, je donne rendez-vous au SSTIC à ceux qui ont réussi la gageure de trouver une place, y compris les aigris à condition qu'ils ne le restent pas trop longtemps. Comme je le disais, les plans loose, ça gave ;)

Notes

[1] Exemple que vous pouvez également retrouver dans l'excellent livre de Michal Zalewski, Silence on the Wire.

[2] Firewalls en particuliers, et certaines routeurs.

[3] Avec des argumentations remarquables de connerie...

[4] Les plus attentifs de mes élèves auront relevé ce problème, et un autre qui devrait faire l'objet de quelques travaux supplémentaires...

[5] J'adore la formulation...