From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- Repenser_la_scurit_du_routage_Internet.txt | 53 ++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Repenser_la_scurit_du_routage_Internet.txt (limited to 'Repenser_la_scurit_du_routage_Internet.txt') diff --git a/Repenser_la_scurit_du_routage_Internet.txt b/Repenser_la_scurit_du_routage_Internet.txt new file mode 100644 index 0000000..ba8b116 --- /dev/null +++ b/Repenser_la_scurit_du_routage_Internet.txt @@ -0,0 +1,53 @@ +Titre: Repenser la sécurité du routage Internet +Auteur: +Date: Wed 08 Feb 2017 01:00:00 +0100 +Lien: https://www.bortzmeyer.org/rethinking-routing-security.html + +Ah, voilà une question qu'elle est bonne : comment améliorer la sécurité du +routage Internet ? On sait qu'elle n'est pas bonne, on sait que n'importe qui[1] +ayant accès à un routeur de la DFZ peut annoncer les routes qu'il veut et ainsi +détourner du trafic. On sait aussi qu'il existe plusieurs techniques pour +limiter les dégâts. La question est : sont-elles bonnes, et ne perd-on pas du +temps avec des techniques compliquées lorsque de plus simples marcheraient +presque aussi bien ? C'est, en gros, l'argument des auteurs de cet excellent +article de Robert Lychev, Michael Schapira et Sharon Goldberg, « Rethinking +Security for Internet Routing[2] ». + +(Au passage, je n'ai pas trouvé cet article en ligne - le dinosaure ACM, +pourtant censé être une association d'informaticiens, ne le permet pas - mais +on peut le télécharger via l'excellent Sci-Hub. Encore merci à son auteure, +pour cet indispensable apport à la science.) + +Pour empêcher quelqu'un d'annoncer une route illégitime dans l'Internet, on a +plusieurs solutions (qui ne sont pas incompatibles : on peut en déployer +plusieurs, voir RFC 7454). On peut valider les annonces reçues de ses pairs BGP +contre un IRR (prefix filtering, dans l'article ; sur les IRR, voir le RFC +7682). On peut utiliser les techniques qui reposent sur la RPKI comme les ROA[3] +(origin validation dans l'article) ou comme le futur BGPsec (path validation, +dans l'article, les RFC sur BGPsec ne sont pas encore sortis). On peut même ne +rien faire et corriger après coup[4] quand une annonce anormale apparait. Ces +techniques ont en commun de nécessiter qu'on connaisse bien ses adresses IP et +sa connectivité (ne riez pas, certains opérateurs ont du mal ici !) La RPKI +stocke à peu près 5 % des routes de l'Internet aujourd'hui. + +Les auteurs de « Rethinking Security for Internet Routing[2] » ont testé +(enfin, simulé). Sur un banc de test représentant une partie de l'Internet, ils +ont essayé plusieurs stratégies et les résultats ne sont pas ceux qu'on +attendait. Si le filtrage des annonces des clients était complètement déployé, +il bloquerait presque autant d'attaques que les techniques plus sophistiquées +de ROA ou de BGPsec. Cela montre que les techniques simples et anciennes sont +souvent très efficaces. + +Évidemment, c'est irréaliste : on n'a jamais une technique de sécurité qui soit +complètement déployée partout. Toute analyse doit tenir compte des « maillons +faibles », qui ne vérifient rien. Mais, même dans ce cas, leur simulation +montre que le filtrage à la source est efficace. Pensez à cela la prochaine +fois que votre transitaire vous embêtera à exiger que vos routes apparaissent +dans la base d'un RIR : c'est pénible, mais c'est efficace contre les +détournements. + +Liens: +[1]: http://www.bortzmeyer.org/bgp-malaisie.html (lien) +[2]: http://cacm.acm.org/magazines/2016/10/207763-rethinking-security-for-internet-routing/ (lien) +[3]: http://www.bortzmeyer.org/securite-routage-bgp-rpki-roa.html (lien) +[4]: http://www.bortzmeyer.org/securite-bgp-et-reaction-rapide.html (lien) -- cgit v1.2.1