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/
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/
