Re: [FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On Wed, 28 Mar 2012 16:44:32 +0200, Stephane Le Men stephane.le...@anycast-networks.com said: Je suis sûr que dans la liste, il y a des personnes qui peer déjà au travers de tunnels pour les raisons qui motivent la sécurisation de BGP, certainement pas avec les 40k AS, mais celles qui ont une importance pour eux. C'est juste l'étape qui précède le peer direct sur un lien physique. Faire BGP *ET* IPSEC avec la meme destination c'est un exploit. Generalement, ceux qui font l'un ne font pas l'autre. J'irai jusqu'a dire que BGP et IPSEC VPN sont presque mutuellement exclusifs. Si jamais on parle de VPN autre qu'IPSEC. j'aimerais compter les gens qui ne font pas la confusion entre VPN et IPSEC VPN. Ca doit etre possible --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On 03/28/2012 05:02 AM, Michel Py wrote: Bonjour l'usine à gaz. Usine à paquets, je le reconnais volontiers, mais les VPN fournissent une solution sans rajouter de nouveau dataflow dans routing et couvre 3 trois problèmes: - assurance de la route, objectif premier - assurance que les AS intermédiaires ne toucheront pas au trafic, la seule option qui leur reste est de couper le VPN et pas de leur permettre d'observer, filtrer, dérouter trafic par trafic. - opportunité de refuser à la source un trafic indésirable en fermant la session d'un VPN AMHA, c'est une considération secondaire. Cela relève du choix de ses priorités. La facilité et le support constructeur viennent loin devant l'élégance théorique de la solution. En utilisant des VPN, il n'y a strictement rien à leur demander, ils fournissent déjà tous ce qu'il faut, avec du soft déjà qualifié dans le domaine du connu, il n'y aura pas mauvaise surprise, il n'y a plus qu'à mettre en œuvre en mode pair à pair, d'AS à AS. Je parie que ceux qui ont déjà eu à en souffrir, ou qui ont préféré s'en prémunir mais qui n'ont pas eu les finances suffisantes pour peerer en direct ont déjà choisi cette solution. le VPN, c'est un peu la fibre du pauvre. Et je vous dis cela parce que je connais des AS où dès qu'il y a du trafic qui devient stratégique pour lui avec une destination, quelques semaines plus tard, il y a un nouveau peering qui apparait dans son réseau. Il n'est plus question d'utiliser ces intermédiaires douteux. Je ne cherche pas à réinventer la poudre, le peering en direct a ses motivations et ses avantages que n'offre pas l'utilisation d'intermédiaires. Et quand on regarde les routeurs d'aujourd'hui à coté de ceux d'il y a 10 ans, il y a des solutions, qui il y a 10 ans, étaient totalement illusoires. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On Wed, Mar 28, 2012 at 12:15:12PM +0200, Stephane Le Men wrote: En utilisant des VPN, il n'y a strictement rien à leur demander, ils fournissent déjà tous ce qu'il faut, avec du soft déjà qualifié dans le domaine du connu, il n'y aura pas mauvaise surprise, il n'y a plus qu'à mettre en œuvre en mode pair à pair, d'AS à AS. Ce qui veut dire que tu établis un tunnel par AS avec lequel tu souhaite communiquer. Bon courage pour monter 40 000 tunnels sur chaque routeur...et ensuite administrer ça derrière... ;) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On 03/28/2012 02:17 PM, Laurent CARON wrote: Ce qui veut dire que tu établis un tunnel par AS avec lequel tu souhaite communiquer. Oui au minimun, mais en fait c'est plus, car un AS peut ne pas annoncer tous ses préfixes sur tous ses liens. Bon courage pour monter 40 000 tunnels sur chaque routeur...et ensuite administrer ça derrière... ;) En parcourant la doc d'un ASR1000, je suis tombé sur le chiffre (qui m'a impressionné) de 64k tunnels l2tp pour une application LNS. Je pense que ses concurrents ne sont pas en reste, mais je n'ai pas cherché à vérifier. Et dans 5 ans, ce chiffre aura certainement doublé ou quadruplé. Quand j'ai vu ce chiffre de 64k, j'ai inscrit dans mon agenda un petit projet de tester un Linux pour comparer (qui n'a pas commencé) Quant à l'administration, chez certains FAI, un tel nombre de tunnels doit déjà être en exploitation. Il suffit qu'il donne leur avis. Concernant BGP, gerer 40k peering direct peut poser des problèmes, mais son job se résume à récupérer les préfixes reçus pour les mettre dans la table de routage sans aucun calcul. En plus, rien ne t'oblige à monter les 40k tunnels sur un lien, tu peux en prendre qu'un sous ensemble ce qui permet de sélectionner avec qui tu veux dialoguer sur le lien sans avoir à jouer des communities. Le cas des 40k tunnels est l'équivalent sécurisé d'une annonce classique chez un transitaire. L'annonce classique sans tunnel, tu peux la conserver sur un lien spécifique qui récupère le reste du trafic qui a peu ou pas d'importance pour toi. Je suis sûr que dans la liste, il y a des personnes qui peer déjà au travers de tunnels pour les raisons qui motivent la sécurisation de BGP, certainement pas avec les 40k AS, mais celles qui ont une importance pour eux. C'est juste l'étape qui précède le peer direct sur un lien physique. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On Wed, Mar 28, 2012 at 04:44:32PM +0200, Stephane Le Men wrote: Oui au minimun, mais en fait c'est plus, car un AS peut ne pas annoncer tous ses préfixes sur tous ses liens. Niveau gestion, ça va être vraiment sympa... ;) En parcourant la doc d'un ASR1000, je suis tombé sur le chiffre (qui m'a impressionné) de 64k tunnels l2tp pour une application LNS. Je pense que ses concurrents ne sont pas en reste, mais je n'ai pas cherché à vérifier. Et dans 5 ans, ce chiffre aura certainement doublé ou quadruplé. Quand j'ai vu ce chiffre de 64k, j'ai inscrit dans mon agenda un petit projet de tester un Linux pour comparer (qui n'a pas commencé) Quant à l'administration, chez certains FAI, un tel nombre de tunnels doit déjà être en exploitation. Il suffit qu'il donne leur avis. Concernant BGP, gerer 40k peering direct peut poser des problèmes, mais son job se résume à récupérer les préfixes reçus pour les mettre dans la table de routage sans aucun calcul. En plus, rien ne t'oblige à monter les 40k tunnels sur un lien, tu peux en prendre qu'un sous ensemble ce qui permet de sélectionner avec qui tu veux dialoguer sur le lien sans avoir à jouer des communities. Le cas des 40k tunnels est l'équivalent sécurisé d'une annonce classique chez un transitaire. L'annonce classique sans tunnel, tu peux la conserver sur un lien spécifique qui récupère le reste du trafic qui a peu ou pas d'importance pour toi. Je suis sûr que dans la liste, il y a des personnes qui peer déjà au travers de tunnels pour les raisons qui motivent la sécurisation de BGP, certainement pas avec les 40k AS, mais celles qui ont une importance pour eux. C'est juste l'étape qui précède le peer direct sur un lien physique. Je ne suis pas certain que l'encapsulation de tout le trafic soit une bonne chose (ex: pb de MTU). TCP/UDP/ICMP over ... ? Tes paquets UDP seront encapsulés dans du TCP (exemple) si tu monte un tunnel vers l'AS de ta sortie SIP. Des peering au travers de tunnels 6to4 oui, le reste je ne pense pas qu'ils sont nombreux. Qu'en pensent les NOC/admin de gros opérateurs Neo, Nerim, Free, ...? --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On Mon, Mar 26, 2012 at 09:27:35AM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 10 lines which said: Ca vaudrait peut-être la peine de leur envoyer un petit mail pour le suggérer. Comme je le disais Un mail ? Bien mieux, je vais leur dire en face en les regardant dans les yeux. C'est l'IETF à Paris, cette semaine, où ROVER sera officiellement présenté. Qui de Frnog vient, d'ailleurs ? s'il n'y a pas de support dans IOS, les chances que je le déploie sont absolument zéro. IOS peut aussi se configurer avec du texte, donc ton stagiaire peut te développer en Python un script DNS2IOS qui prend du ROVER dans le DNS et en fait des route-maps... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On 03/25/2012 09:33 PM, Stephane Bortzmeyer wrote: Bon, pronostic : RPKI mort-né, Rover on a roll ? Encore trop tôt pour le dire. Je prends le pari que la grande majorité de Frnog n'a aucune opinion, ni sur RPKI, ni sur Rover :-) Mon opinion sur ces protocoles est que le niveau de sécurité obtenue à la fin sera toujours dépendant de la bonne volonté des AS intermédiaires qui séparent ceux qui veulent communiquer ensemble. L’établissement d'un circuit vérifié avec une destination ne préjuge en rien de la sécurité des autres circuits qui viendront par la suite et qui ne seront pas vérifié. Le seul cas avec BGP où l'on est sûr de l'AS avec qui on cause, c'est le cas l'on peer en direct avec cet AS. Ramenez les autres cas (destination séparé par des AS intermédiaires) à ce cas de peering en direct, revient à échanger du trafic au travers d'un VPN qui relie directement les deux AS. Comme on ne peut pas monter de VPN sur les net block que l'on annonce, la seule solution restante est le VPN monté sur les IP d'interconnexion de chaque AS et de peerer au travers de ce VPN. Résultat, ceux qui angoissent de se faire détourner leur trafic ont cette possibilité de se rapprocher (au sens AS PATH) par le biais de plusieurs VPN sur leurs différents liens d'interconnexions et de peerer au travers d'eux. Pour un AS qui ne serait pas un AS de transit, appliquer systématiquement cette politique reviendrait à être au contact direct de toutes les AS qui sont la source ou la destination du trafic que l'on veut sécuriser. J'y vois un autre avantage que la sécurité obtenue sur la route, la possibilité de refuser du trafic provenant d'un AS (plus ou moins mal tenu) qui inonderait un ou plusieurs liens en arrêtant le ou les VPN qui relient à l'AS source du trafic indésirable. Évidement, il ne faut pas utiliser de type de VPN sans session, (comme ip dans ip) sinon, le trafic que l'on refuse arrivera quand même à la destination. L'inconvénient étant l'overhead VPN, et le nombre important de VPN à monter si l'on veut généraliser cette politique à tout l'Internet. De mon avis, dans BGP, il n'y a rien de fondamental à changer, ce protocole est nickel. Mieux vaut s'en contenter, et prendre des mesures sur l'architecture d'interconnexion des AS qui comblent sa lacune de sécurité. Si j'ai un avis propre sur Rover vs RPKI, Rover a largement ma préférence parce le rapport hiérarchique se fait au niveau du LIR, et n'est pas totalement concentré chez les RIR. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
Stephane Le Men a écrit: Comme on ne peut pas monter de VPN sur les net block que l'on annonce, la seule solution restante est le VPN monté sur les IP d'interconnexion de chaque AS et de peerer au travers de ce VPN. Bonjour l'usine à gaz. Si j'ai un avis propre sur Rover vs RPKI, Rover a largement ma préférence parce le rapport hiérarchique se fait au niveau du LIR, et n'est pas totalement concentré chez les RIR. AMHA, c'est une considération secondaire. La facilité et le support constructeur viennent loin devant l'élégance théorique de la solution. Tu raisonnes un peu comme l'autre Stéphane à propos de ça, en regardant le protocole alors que je regarde l'outil. Stephane Bortzmeyer a écrit: Un mail ? Bien mieux, je vais leur dire en face en les regardant dans les yeux. C'est l'IETF à Paris, cette semaine, où ROVER sera officiellement présenté. Très bien, très bien. Qui de Frnog vient, d'ailleurs ? Pas moi, c'est un peu loin ;-) s'il n'y a pas de support dans IOS, les chances que je le déploie sont absolument zéro. IOS peut aussi se configurer avec du texte, donc ton stagiaire peut te développer en Python un script DNS2IOS qui prend du ROVER dans le DNS et en fait des route-maps... Trop compliqué. Comme discuté récemment, le support natif dans le routeur est un avantage très important. Dans ce cas précis, il y a une bonne possibilité de ré-utiliser le code existant. Ca me semble peu probable que Cisco ou Juniper adaptent leur code à ROVER. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On Sun, Mar 25, 2012 at 01:03:34PM -0700,
Michel Py mic...@arneill-py.sacramento.ca.us wrote
a message of 29 lines which said:
ROVER est uniquement un outil de détection ou d'analyse, il
n'empêche pas les routes illégitimes d'être acceptées.
Pas d'accord. ROVER est un mécanisme de publication des AS d'origine
et peut parfaitement être utilisé pour décider de ce qu'on fera d'une
route. Pareil avec RPKI+ROA, d'ailleurs : c'est aussi un mécanisme
d'étiquetage (« Cette route est valide ») qui ne présuppose pas de la
décision qui sera finalement prise par le routeur.
Heureusement d'ailleurs, car autrement on se retrouverait dans une
situation impossible: ROVER ayant besoin de DNS qui a besoin du
routage pour fonctionner, si on ne pouvait pas accepter les routes
sans les vérifier, tout se bloquerait.
La RPKI a exactement le même problème ('rsync -av
rsync://rpki.ripe.net/repository RPKI-repository' ne marche pas sans
le DNS...) et la solution est la même : un cache dans le validateur.
---
Liste de diffusion du FRnOG
http://www.frnog.org/
[FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
Michel Py a écrit: ROVER est uniquement un outil de détection ou d'analyse, il n'empêche pas les routes illégitimes d'être acceptées. Stephane Bortzmeyer a écrit: Pas d'accord. ROVER est un mécanisme de publication des AS d'origine et peut parfaitement être utilisé pour décider de ce qu'on fera d'une route. Pareil avec RPKI+ROA, d'ailleurs : c'est aussi un mécanisme d'étiquetage (« Cette route est valide ») qui ne présuppose pas de la décision qui sera finalement prise par le routeur. J'avais pris quelques raccourcis, et tu as tout a fait raison, syntaxiquement parlant. Je reformule: Sur Cisco et Juniper, l'implémentation de RPKI permet de manipuler les routes directement dans IOS ou JunOS: http://www.ripe.net/lir-services/resource-management/certification/router-configuration Donc avec RPKI, moyennant quelques modifications de route-maps, on peut facilement envoyer les annonces invalides aux oubliettes, ce qui après tout était le but du jeu. Qu'est-ce qu'il y a comme support pour ROVER dans IOS ou dans JunOS ? Est-ce qu'on peut interroger le validateur ROVER de la même façon que le validateur RPKI ? Si non, je ne donne pas trop cher de ROVER, à cause de la bien-connue loi dite de l'emmerdement minimum. Un autre aspect à considérer: le coté usine à gaz. Rover semble plus simple, mais pour que l'implémentation soit sécurisée, il faut avoir DNSSEC dans les zones in-addr.arpa (est-ce que j'ai lu correctement?) et on me dit dans l'oreillette que DNSSEC ce n'est pas aussi simple que ça en avait l'air. Si on fait ROVER sans DNSSEC, on s'expose à tout un tas d'ennuis genre cache poisoning, et one me dit que depuis Kaminsky ça n'a pas l'air si difficile. Je ne dis pas que ROVER sans DNSSEC ça ne sert à rien, ceci dit. C'est nettement plus compliqué d'annoncer un préfixe en devant en plus monter simultanément une attaque sur une zone in-addr.arpa; cela ne stoppera pas un attaqueur déterminé mais ça devrait stopper la bleusaille qui manque d'apprentissage au kilométrage et annonce l'Internet entier. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] RE: [TECH] ROVER: une technique alternative de sécurisation de BGP
Michel Py ROVER est uniquement un outil de Stephane Bortzmeyer Pas d'accord. ROVER est un mécanisme de Je ne l'avais pas réalisé avant, mais le désaccord est en grande partie du à la manière dont nous regardions respectivement les choses: Quand tu compares ROVER et RPKI, tu penses à des mécanismes, des protocoles. Comment ça marche. Quand je les compare, je pense à des outils. Comment je m'en sers. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On Mon, Mar 26, 2012 at 01:15:01AM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 46 lines which said: Je reformule: Sur Cisco et Juniper, l'implémentation de RPKI permet de manipuler les routes directement dans IOS ou JunOS: Cela ne semble pas spécifique à la RPKI. La configuration que tu indiques permet deux choses : 1) Indiquer une source de validation (10.1.1.6 dans le premier exemple) 2) En fonction des résultats de cette source, manipuler les routes (les jeter, changer les préférences, etc). Le deuxième point est identique quelle que soit la source de validation. Le premier point pourrait être adapté à ROVER très facilement : le protocole de communication routeur-validateur qu'utilise la RPKI, RTR RFC à venir, n'est pas du tout spécifique à la RPKI. Qu'est-ce qu'il y a comme support pour ROVER dans IOS ou dans JunOS ? ROVER est plus récent que RPKI+ROA donc forcément moins mis en oeuvre. La bonne stratégie, à mon avis, serait de réutiliser RTR, puisque JunOS et IOS ont déjà un client RTR. Est-ce qu'on peut interroger le validateur ROVER de la même façon que le validateur RPKI ? Pas spécifié dans les drafts ROVER actuellement, mais cela serait une bonne idée. Un autre aspect à considérer: le coté usine à gaz. Rover semble plus simple, mais pour que l'implémentation soit sécurisée, il faut avoir DNSSEC dans les zones in-addr.arpa (est-ce que j'ai lu correctement?) Tout à fait. ROVER sans DNSSEC n'a pas de sens. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] RE: [TECH] ROVER: une technique alternative de sécurisation de BGP
Stephane Bortzmeyer a écrit: La bonne stratégie, à mon avis, serait de réutiliser RTR, puisque JunOS et IOS ont déjà un client RTR. Tout à fait d'accord. Ca vaudrait peut-être la peine de leur envoyer un petit mail pour le suggérer. Comme je le disais précédemment, s'il n'y a pas de support dans IOS, les chances que je le déploie sont absolument zéro. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP
On Fri, Mar 23, 2012 at 01:53:46PM +0100, Jérôme Nicolle jer...@ceriz.fr wrote a message of 21 lines which said: C'est marrant comme ça ressemble à http://xkcd.com/927/... Rien de mieux qu'un nouveau standard pour être sur que RPKI ne sera pas déployé... En même temps, si on pense que RPKI est une mauvaise idée, on a le droit de développer autre chose, quand même. Bon, pronostic : RPKI mort-né, Rover on a roll ? Encore trop tôt pour le dire. Je prends le pari que la grande majorité de Frnog n'a aucune opinion, ni sur RPKI, ni sur Rover :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
