Re: [FRnOG] [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA
Le 07/02/2012 14:21, Stephane Bortzmeyer a écrit : Pourquoi spéculer au hasard alors qu'on a déjà des cas concrets à étudier ? http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005858.html http://www.ripe.net/internet-coordination/news/about-ripe-ncc-and-ripe/ripe-ncc-to-seek-clarification-from-dutch-court-on-police-order-to-temporarily-lock-registration Avec la mise à jour du RIPE qui a finalement débloqué les plages d'adresses le 10 janvier : RIPE NCC Unlocks Registration in RIPE Registry http://www.ripe.net/internet-coordination/news/about-ripe-ncc-and-ripe/ripe-ncc-unlocks-registration-in-ripe-registry Une bonne synthèse de Milton Mueller and co. sur le site de l'IGP : http://blog.internetgovernance.org/blog/_archives/2011/11/23/4944811.html L'ARIN a obtempéré à l'injonction de la cour fédérale de NY, contrairement au RIPE NCC pour le moment. Par exemple pour la première plage d'adresse côté ARIN : http://whois.arin.net/rest/net/NET-67-210-0-0-1/pft Comments In accordance with a Court Order in connection with a criminal investigation, this registration record has been locked and during the period from November 8, 2011 through March 22, 2012, any changes to this registration record are subject to that Court Order. Patrick. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA
Stephane Bortzmeyer a écrit: Un tel empoisonnement signifierait probablement la fin de la RPKI (plus personne ne validerait) donc, si le FBI compte utiliser la RPKI, il ne pourra le faire qu'une fois. Bonus : si le préfixe était alloué par le RIPE, et que l'annonce FBI était signée par ARIN, cela signifierait probablement la fin d'ARIN dans la RPKI (plus personne ne garderait leur clé comme « trust anchor » après un coup pareil). Mouais; seulement peut-être, AMHA. Si RPKI avait était déployé il y a 1 mois, si MU avait des préfixes PI de RIPE (?), si MU avait du matos en réserve pour renaître de ses cendres et redéployer dans un pays ou le FBI n'est pas le bienvenu, si le FBI avait fait pression sur ARIN pour empoisonner les préfixes de MU (ça fait beaucoup de si) je me demande combien d'opérateurs auraient en pratique effacé la clé RPKI d'ARIN. Stephane Le Men a écrit. Est-ce que l'affaire MU Il n'y a pas d'affaire MU. Dans la couche 8 du réseau, personne n'en a entendu parler. Et dans la couche 9, à part Cogent et Kim Dotcom, tout le monde s'en frotte les mains. a énervé suffisamment de monde pour qu'ils se concertent et changent le contenue du root.cache de leur DNS ? Non. Stephane Bortzmeyer a écrit: S'il y a un État qui peut imposer (démocratiquement ou de manière dictatoriale, peu importe, le résultat est le même) En effet. Quand quelqu'un arrive dans ton DC avec un gros flingue et que toi tu n'en a pas, peu importe que le quelqu'un en question soit Harry Callahan ou l'exécuteur des basses besognes d'un dictateur. C'est celui qui a le gros soufflant dans la main qui a raison. opérateurs une politique donnée, qu'il y ait un ou dix acteurs à notifier, la différence est faible, et purement quantitative. +1 L'ARCEP compte 700 FAI licenciés en France mais combien font du BGP sans route par défaut ? (C'est une vraie question : si quelqu'un a le chiffre, ça m'intéresse). Bien plus que techniquement nécessaire. Faire du BGP sans défaut, c'est souvent une tactique crassouilleuse qui permet aux commerciaux d'un FAI d'essayer de dire à leurs clients qu'ils sont Tier-1 alors qu'ils ne le sont pas, en confondant allègrement peering et paid peering. Dire qu'on est opérateur dans la DFZ, c'est comme avoir une grosse bagnole: ça veut dire moi j'ai du fric pour acheter le gros méga-routeur à Mr Cisco ou à Mr Juniper. Comportement de nouveau riche; tentative d'affirmer un statut social désiré mais pas atteint. Les vrais Tier-1 ils n'ont pas besoin de le dire. D'où ma remarque sur les « vrais » opérateurs qui font du BGP sans route par défaut. En fait, dès qu'on n'est pas Tier-1, on a ce problème, avant même la RPKI : on est dépendant de la politique de routage de ses fournisseurs, comme on l'avait bien vu dans l'affaire du réseau 128 http://www.bortzmeyer.org/reseau-128.html où des AS sans aucun routeur Juniper avaient quand même été coupés de ce réseau car tous leurs transitaires avaient du Juniper. +1 Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA
Les gens de BGP étaient jaloux de ceux du DNS, qui s'amusaient comme des petits fous avec DNSSEC. Désormais, avec leur BGPdemisec, ils vont pouvoir rire eux aussi. Par contre, Pakistan Telecom ne pourra plus augmenter la productivité des entreprises occidentales, en empêchant leurs employés de regarder des lolcats sur YouTube. http://www.bortzmeyer.org/securite-routage-bgp-rpki-roa.html On le sait, le protocole BGP (normalisé dans le RFC 4271), sur lequel repose tout l'Internet, car c'est lui qui permet à l'information de routage de circuler entre les opérateurs, ce protocole, donc, est peu sûr. N'importe qui peut annoncer n'importe quelle route, dire « Je suis Google, envoyez-moi toutes les requêtes Google » et les autres le croient. Résoudre cette vulnérabilité n'est pas trivial, pour des raisons essentiellement non techniques. Néanmoins, le manque d'un mécanisme standard pour valider les routes était une des faiblesses du routage Internet. Une série de RFC vient de partiellement combler ce déficit. Écrits par le groupe de travail IETF SIDR http://tools.ietf.org/wg/sidr (Secure Inter-Domain Routing), ces RFC décrivent une série de protocoles, règles et formats qui permettent de sécuriser une partie de BGP. À eux seuls, ils sont loin de résoudre le problème, qui est très complexe. Mais ils fournissent des briques sur lesquelles seront bâties les solutions ultérieures. Ces annonces de route anormales sont relativement banales sur l'Internet. Pour ne citer que trois exemples relativement récents : * Le 24 février 2008, Pakistan Telecom annonce les adresses de YouTube et prive le monde de ce service pendant plusieurs heures http://www.bortzmeyer.org/pakistan-pirate-youtube.html, * Le 8 avril 2010, China Telecom annonce les adresses d'une bonne partie de l'Internet et attire ainsi leur trafic http://bgpmon.net/blog/?p=323, * Le 23 juin 2011, OpenTransit fait la même erreur et détourne également une partie du trafic http://www.mail-archive.com/frnog@frnog.org/msg15150.html. Les abonnés au service d'alarme BGPmon http://www.bortzmeyer.org/alarmes-as.html reçoivent des avis de détournement (en ligne sur http://www.bortzmeyer.org/files/bgpmon-as5511-june-2011.txt). Toutes étaient des erreurs et pas des attaques. Néanmoins, le risque que cette même faiblesse soit exploitée pour des attaques est réel. Celles-ci seront sans doute plus subtiles que les trois grosses bavures citées plus haut, et utiliseront sans doute des techniques de furtivité comme celle de Kapela Pilosov http://www.bortzmeyer.org/faille-bgp-2008.html. Mais alors, pourquoi malgré autant d'attaques (n'exagérons rien : il n'y en a pas tous les mois), n'a-t-on pas encore déployé une solution de sécurité ? Parce que le problème est compliqué. Le routage sur l'Internet n'est pas hiérarchique. Les relations entre opérateurs sont un graphe plutôt complexe, et un opérateur qui est situé loin ne sait pas ce qui est normal : après tout, qui me dit que YouTube n'a pas subitement changé de fournisseur pour s'installer au Pakistan ? Mëme si un être humain peut trouver cela bizarre, le pauvre routeur BGP n'a pas de moyen de décider si une annonce est normale ou pas. Il y a en fait deux choses qu'on peut vouloir authentifier dans une annonce BGP. Imaginons qu'un routeur reçoive une annonce pour le préfixe 2001:db8:666::/48 et que le chemin des AS traversés soit 64496 65550 65543 (rappelez-vous que le chemin se lit de droite à gauche, l'annonce initiale a donc été faite par l'AS 65543). Le routeur peut se demander « Est-ce que 65543 était bien autorisé à annoncer ce préfixe ? », ce qu'on appelle la *validation de l'origine*. Et il peut aussi s'interroger « Est-ce que 65550 avait le droit de relayer cette annonce ? Et 64496 ? ». C'est la *validation du chemin*. La première est relativement simple (il n'y a pas tant de préfixes IP que cela et ils sont normalement tous enregistrés dans les bases des RIR, et les origines changent rarement). La seconde est bien plus complexe (explosion combinatoire du nombre de possibilités, relations entre opérateurs qui ne sont pas dans les bases des RIR, changements fréquents) et ne sera traitée que dans un deuxième temps. Il y a donc eu de nombreuses tentatives de résoudre ce problème de sécurité (une liste partielle figure à la fin de cet article). Attention d'ailleurs en lisant ce qu'on trouve sur l'Internet : vous extrayerez des tas de propositions dépassées ou abandonnées. L'approche choisie par le groupe SIDR est modulaire : il n'y a pas une technique unique qui résoud tout mais un ensemble d'outils, à combiner selon les cas. À la base, se trouve la RPKI, une IGC hiérarchique, partant de l'IANA et des RIR, permettant de produire des certificats attestant de la « possession » d'une ressource (un préfixe IP, un numéro d'AS, etc). L'émission de ces certificats a été un des premiers pas concrets
Re: [FRnOG] [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA
On 02/04/2012 05:44 PM, Stephane Bortzmeyer wrote: http://internetgovernance.org/pdf/RPKI-VilniusIGPfinal.pdf, cela peut changer les rôles des acteurs de la gouvernance de l'Internet et la RPKI devrait donc être discutée politiquement, pas uniquement techniquement. Pour l'instant, les partisans de la RPKI considèrent que le problème doit être relativisé car le contrôle final est entre les mains du cache validateur qui croit qui il veut. S'il ne veut pas utiliser les trust anchors des RIR, il le peut. (Il peut aussi ne pas valider du tout, ou bien accepter les routes invalides, surtout s'il n'y a pas de routes alternatives.) Enfin une nouvelle qui va réjouir le FBI. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA
Stephane Bortzmeyer a écrit: Quelles sont les chances d'adoption de RPKI+ROA, sachant que d'innombrables protocoles de sécurité de l'IETF ont été peu ou pas déployés (IPsec, PGP, etc) ? Zat is ze question Tout le monde dit en effet vouloir davantage de sécurité mais, en pratique, personne ne veut en payer le prix. En voyant la chose d'assez loin (vérité dans la pub: je n'ai pas encore lu les 14 RFC et je n'ai pas encore fait le lab) et même si finalement tout en revient à l'argent, je pense que l'on n'en est pas encore à ce point là et que dans l'état actuel des choses les obstacles principaux sont plutôt: - De faire suffisamment de bruit pour que les intéressés regardent de plus près. Je trouve que ce que tu as écrit à propos de l'attaque de 2008 est pile poil sur le sujet: http://www.bortzmeyer.org/faille-bgp-2008.html Notons d'abord la mise en scène. Comme le disait un participant de Nanog : « I think they saw the DNS people getting their 10 minutes of fame and wanted their own :) ». La sécurité informatique est un métier, comme le show-business : il faut faire parler de soi. Ce n'est pas par hasard que les exposés à Defcon commencent toujours par « cette faille est particulièrement sérieuse ». On n'a jamais vu un chercheur en sécurité débuter avec « C'est une petite vulnérabilité sans intérêt. ». Prendre conscience de cela aide à mettre cette annonce dans son contexte. - De convaincre les opérateurs que le remède n'est pas pire que la maladie. Un échantillon ci-dessous. Faut être réaliste, c'est une usine à gaz. Une bonne partie des problèmes récents étant dus à des erreurs sans but malicieux, il est permis de se demander si l'usine à gaz (juste par la compléxité rajoutée) ne va pas générer plus d'erreurs que celles qu'elle est supposée résoudre. Est-ce que ce système n'ouvre pas la porte à un nouveau modèle de joe-job? Un autre problème potentiel est: ce genre de système a une tendance à générer des quantités considérables d'évènements. J'ai bien peur que ça ne finisse comme les logs de firewall: Il y a tellement de volume que personne ne les regarde. Il y a aussi un problème de compétence. Combien y a-t-il parmi les lecteurs de cette liste qui, disons dans les 2 mois, vont lire les 14 RFC en question et qui sont capables de comprendre le machin dans son ensemble? Et le problème associé: si un préfixe légitime est bloqué à cause d'une configuration incorrecte ou imprécise ou d'un bug, qui va faire le troubleshooting ? Plus la plomberie est compliquée, plus elle est facile à boucher. S'il faut 14 RFC pour décrire la chose, il va falloir combien d'étapes, d'outils, et de temps pour trouver quel est le composant qui bloque un préfixe ? Que se passe-t-il quand le client final qui se retrouve bloqué parle à son FAI qui n'y comprend rien ? A noter que je ne démolis pas le système même si ce que je viens d'écrire pourrait en avoir l'apparence. C'est quelque chose qu'il va falloir regarder d'assez près avant de prendre la décision d'implémenter ou pas. Y'a qu'à. Faut qu'on. 14 RFC d'un seul coup, un samedi ensoleillé à l'heure de l'apéro, c'est un peu raide ceci dit. Tout à fait sérieusement, l'ennemi principal de ce système c'est pas assez urgent. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
