Re: [FRnOG] [TECH] Cisco pour transit ?
On Thu, Jun 27, 2013, at 7:47, Sébastien Namèche wrote: Bonjour Olivier, bonjour la liste, Et un Cisco de la gamme 2900 ? Le 2921, par exemple, 3300 euros prix liste. Tu lui ajoutes une extension de 1 Go de mémoire et tu as de quoi y mettre pas mal de full tables. C'est de l'ISR G2, c'est moderne. et c'est un routeur soft. Si un 7201 ne le fait pas, les 1900/2900/3900 faut meme pas y penser. Deja un 2900 pour du transit, il faut oublier par principe. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?
On Wed, Jun 26, 2013 at 10:17:06AM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 48 lines which said: S'il est vrai que les adresses du routeur lui-même risquent d'être bloquées, rien n'empêche le routeur de générer un paquet avec une IP qui circulerait librement. Attention, en TCP, c'est plus compliqué que cela car il faut recevoir les réponses. Scénario facile: il suffit d'avoir 2 PC qui communiquent et dont le trafic transite par hasard dans le routeur cœur de réseau en question, le dit routeur connaissant l'adresse de l'un des deux PC ou une signature quelconque à l'intérieur du paquet et interceptant le trafic pour y prendre ses instructions ou le modifier et y injecter ses trouvailles (faut pas oublier de refaire les checksums). Ah oui, cool idée, je savais bien que j'avais raison de demander sur cette liste. Je transmets l'idée à Pékin tout de suite et j'attends mon chèque. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
On Thu, Jun 27, 2013 at 07:37:13AM +0200, Pierre Col - p...@9online.fr p...@9online.fr wrote a message of 15 lines which said: http://www.zdnet.fr/actualites/vers-une-refonte-en-profondeur-du-systeme-whois-avec-quels-risques-39791833.htm Cool, on y voit que les français ont un whois en couleurs alors que les états-uniens ont de la triste police Courier noire sur fond blanc :-) Plus sérieusement, l'exemple est très mauvais : .com étant un registre mince, la sortie du serveur whois d'InterNIC ne contient pas grand'chose. En demandant au serveur whois de Mark Monitor, ou tout simplement en utilisant un client whois plus perfectionné (GNU whois dans mon cas), on a bien plus : Registrant: Domain Admin CBS Interactive, Inc. 235 Second Street San Francisco CA 94105 US hostmas...@cnet.com +1.4153442000 Fax: +1.4153442000 Domain Name: zdnet.com Registrar Name: Markmonitor.com Registrar Whois: whois.markmonitor.com Registrar Homepage: http://www.markmonitor.com Administrative Contact: Domain Admin CBS Interactive, Inc. 235 Second Street San Francisco CA 94105 US hostmas...@cnet.com +1.4153442000 Fax: +1.4153442000 Technical Contact, Zone Contact: Domain Admin CBS Interactive, Inc. 235 Second Street San Francisco CA 94105 US hostmas...@cnet.com +1.4153442000 Fax: +1.4153442000 Created on..: 1995-04-27. Expires on..: 2015-04-27. Record last updated on..: 2013-03-27. ... --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Session BGP priorité
Bonjour, Juste une petite question : Je dispose actuellement de 2 sessions BGP vers 2 transtaires différents. Chaque transitaire est branché sur un routeur différent. Ces 2 routeurs sont reliés via un Lan-to-Lan. Je voudrais savoir comment je peux à tout mon traffic (entrant et sortant) de passer uniquement sur un seul transitaire. On peut mettre en place le local-preference mais je ne suis pas convaincu... Avez-vous un retour d'expérience dessus? Merci. Etienne. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Le 6/27/13 9:10 AM, Etienne Girard a écrit : Bonjour, Juste une petite question : Je dispose actuellement de 2 sessions BGP vers 2 transtaires différents. Chaque transitaire est branché sur un routeur différent. Ces 2 routeurs sont reliés via un Lan-to-Lan. Je voudrais savoir comment je peux à tout mon traffic (entrant et sortant) de passer uniquement sur un seul transitaire. On peut mettre en place le local-preference mais je ne suis pas convaincu... Avez-vous un retour d'expérience dessus? Bonjour Etienne, Oui, local preference en route-map IN et prepend de l'as-path en OUT. Pour ce dernier, ça ne prendra cependant pas forcément le dessus si les opérateurs en face forcent d'un côté. Tu peux toujours diviser ton/tes préfixe(s) en 2 sous préfixes annoncés que d'un côté si vraiment tu veux forcer dans ce sens là, mais sauf problème réel de qualité, c'est généralement mieux de ne pas forcer plus que le prepend, car souvent le routage n'est pas forcé d'un côté par hasard. Frédéric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Hiho, local-pref pour la sortie, et prepend pour l'entrée. Sinon y'a ça : http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094934.shtml?referring_site=bodynav mais j'ai pas lu. SALUT. Benjamin Bonjour, Juste une petite question : Je dispose actuellement de 2 sessions BGP vers 2 transtaires différents. Chaque transitaire est branché sur un routeur différent. Ces 2 routeurs sont reliés via un Lan-to-Lan. Je voudrais savoir comment je peux à tout mon traffic (entrant et sortant) de passer uniquement sur un seul transitaire. On peut mettre en place le local-preference mais je ne suis pas convaincu... Avez-vous un retour d'expérience dessus? Merci. Etienne. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Journée du Conseil scientifique de l'Afnic du 9 juillet : vous y êtes invités !
Bonjour à tous, L'Afnic organise la journée du Conseil scientifique le 9 juillet prochain. J'ai le plaisir de vous y inviter. Je diffuse l'annonce sur cette liste parce que je pense ses membres font partie du public ciblé par la thématique de cette année : Quelles évolutions pour les architectures de l'Internet Je vous laisse découvrir des extraits du programme et les informations pratiques (inscription, accès…). Vous y reconnaîtrez en particulier un certain S. Bortzmeyer qui donnera un tutoriel en matinée sur un sujet qui a des chances de vous intéresser :-) http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-generales/7050/show/journee-du-conseil-scientifique-de-l-afnic-le-9-juillet-2013.html N'hésitez pas à diffuser cette annonce dans votre entourage. Excellente journée. Mohsen. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
On Thu, Jun 27, 2013, at 9:37, Benjamin BILLON wrote: local-pref pour la sortie, et prepend pour l'entrée. Juste pour rappeler que le prepend pour l'entree donne des resultats un peu aleatoires (ton traffic entrant, c'est le traffic sortant de quelqu'un d'autre, qui peut utiliser a son tour le localpref pour forcer la sortie a un certain endroit). Pour couper totalement l'entree, il faut soit retirer les annonces, soit couper carrement la session. Le prepend c'est juste ce que tu aimerais que les autres fassent, pas ce que les autres vont faire dans la realite. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
Le 2013-06-27 09:20, Stephane Bortzmeyer a écrit : Justement, WHOIS est broken. Ses inconvénients sont ses avantages. Par exemple, l'absence de format de sortie normalisé est une bonne chose. Ce « semantic firewall » rend plus difficile la récolte automatisée massive de données. Un iota plus difficile oui, mais tout de même très facile. On peut faire un petit script Perl en une soirée qui permettra de récolter 99.9% des données correctement. Le format sous-spécifié de WHOIS n'est donc pas une bonne protection contre la récolte automatisée. Il est par contre un véritable problème pour ceux qui tentent d'automatiser des processus légitimes. Et puis, remplacer un protocole décentralisé par un centralisé est-il une bonne chose ? C'est comme, je ne sais pas, prenons un exemple idiot, au lieu qu'on ait plusieurs serveurs SMTP, comme si tout le monde utilisait un service central espionné par PRISM ? Le remplacement du protocole WHOIS par un autre protocole n'implique pas la centralisation. Il s'agit seulement d'échanger un protocole contre un autre. La centralisation des données peut se faire peu importe le protocole d'accès aux données. Les deux concepts (protocole vs centralisation) sont orthogonaux. Pour ceux qui ne suivent pas les travaux de l'IETF, le remplaçant actuellement proposé pour whois (et qui, comme whois, est décentralisé), se nomme RDAP et repose sur des techniques buzzword-compliant (REST et JSON). Il est actuellement en Working Group Last Call. WHOIS et RDAP ne sont ni centralisés, ni décentralisés. L'architecture sous-jacente, elle, peut être centralisée ou décentralisée. C'est le protocole qui est en WGLC, alors que l'architecture n'est pas standardisée. Le groupe de travail discute actuellement du processus de bootstrapping pour RDAP, ce qui implique une certaine forme d'architecture. La discussion est encore très jeune. Deux drafts proposent des méthodes décentralisées: https://tools.ietf.org/html/draft-blanchet-weirds-bootstrap https://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [tech] l'ICANN veut mettre fin a WHOIS
Le 2013-06-27 02:13, Jérôme Nicolle a écrit : Justement, WHOIS est broken. Ah ? Moi je troue que ça arche plutôt bien. Un peu lent, mais rien de plus à en demander. Qu'est ce que tu lui reproche ? Le format est sous-spécifié, ce qui rend très difficile d'automatiser un processus qui ferait une requête WHOIS et traiterait le contenu de la réponse. Et même si tu passes plein d'heures à faire du beau code qui traite toutes les exceptions (ça va commencer à ressembler à de l'intelligence artificielle), le format change un peu à tous les jours, selon les évolutions de chaque registre. Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
On Thu, Jun 27, 2013 at 11:43:52AM +0200, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 19 lines which said: Et même si tu passes plein d'heures à faire du beau code qui traite toutes les exceptions Ne pas réinventer la roue, c'est déjà fait : http://search.cpan.org/dist/Net-DRI/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Bonjour Si ton equipement le supporte et que ton peer le supporte également et qu'il est d'accord pour le prendre en compte, l'attribut MED, optional et non transitive est une solution pour forcer ton traffic à entrer dans ton AS multihomed par un chemin précis. Cordialment 2013/6/27 Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net On Thu, Jun 27, 2013, at 9:37, Benjamin BILLON wrote: local-pref pour la sortie, et prepend pour l'entrée. Juste pour rappeler que le prepend pour l'entree donne des resultats un peu aleatoires (ton traffic entrant, c'est le traffic sortant de quelqu'un d'autre, qui peut utiliser a son tour le localpref pour forcer la sortie a un certain endroit). Pour couper totalement l'entree, il faut soit retirer les annonces, soit couper carrement la session. Le prepend c'est juste ce que tu aimerais que les autres fassent, pas ce que les autres vont faire dans la realite. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
On Thu, Jun 27, 2013 at 11:34:36AM +0200, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 52 lines which said: Le remplacement du protocole WHOIS par un autre protocole n'implique pas la centralisation. Mais la discussion ne portait pas sur le protocole mais sur une proposition particulière, ARDS, dont la principale caractéristique est d'être centralisée. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
Le 2013-06-27 11:49, Stephane Bortzmeyer a écrit : Et même si tu passes plein d'heures à faire du beau code qui traite toutes les exceptions Ne pas réinventer la roue, c'est déjà fait : http://search.cpan.org/dist/Net-DRI/ Ça prouve mon point. C'est une librairie hyper complexe qui n'arrive tout de même pas à atteindre 100% de succès et qui doit continuellement s'adapter pour suivre les évolutions du protocole. Alors qu'en RDAP on peut faire un client en 5 lignes de JavaScript, on sait qu'il marchera dans 100% des cas, et que demain il marchera encore. Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
Le 2013-06-27 11:53, Stephane Bortzmeyer a écrit : Le remplacement du protocole WHOIS par un autre protocole n'implique pas la centralisation. Mais la discussion ne portait pas sur le protocole mais sur une proposition particulière, ARDS, dont la principale caractéristique est d'être centralisée. Dans ce cas, désolé d'avoir détourné la discussion. (Au moins j'aurai pu expliquer que ARDS != RDAP.) Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Au risque de poser une question un peu noob, pourquoi vous utilisez du preprend en ingress au lieu du MED ? Le MED c'est quand même fait pour ça… On Jun 27, 2013, at 9:37 AM, Benjamin BILLON bbil...@splio.fr wrote: Hiho, local-pref pour la sortie, et prepend pour l'entrée. Sinon y'a ça : http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094934.shtml?referring_site=bodynav mais j'ai pas lu. SALUT. Benjamin Bonjour, Juste une petite question : Je dispose actuellement de 2 sessions BGP vers 2 transtaires différents. Chaque transitaire est branché sur un routeur différent. Ces 2 routeurs sont reliés via un Lan-to-Lan. Je voudrais savoir comment je peux à tout mon traffic (entrant et sortant) de passer uniquement sur un seul transitaire. On peut mettre en place le local-preference mais je ne suis pas convaincu... Avez-vous un retour d'expérience dessus? Merci. Etienne. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
On Thu, Jun 27, 2013 at 11:56:28AM +0200, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 13 lines which said: désolé d'avoir détourné la discussion. C'est un scandale ! Personne ne fait jamais cela sur Frnog ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Hello, Surement parce que la plupart des opérateurs avec des ASN à 3-4 chiffres (ou plus) ne savent pas l'honorer correctement ? Je vois pour nous .. On utilise clairement le MED et souvent .. Tout le monde s'en fout. Peer, uplinks, clients etc .. INGRESS ou EGRESS donc. J'ai pas mal d'ex. ou ça se passe très mal :) En tout cas bonne remarque pour le coup :) Bref .. -- Nicolas STRINA Jaguar Network Switzerland 19 Boulevard Georges Favon CH - 1204 Geneva More Than Your Hosting Company Tel : +33 4 88 00 65 16 Gsm : +33 6 18 20 49 55 Std : +41 8 40 65 61 11 Fax : +33 4 88 00 65 25 URL: http://www.jaguar-network.ch/ Support 24+7 : supp...@jaguar-network.ch Le 27 juin 2013 à 11:56, Fleuriot Damien m...@my.gd a écrit : Au risque de poser une question un peu noob, pourquoi vous utilisez du preprend en ingress au lieu du MED ? Le MED c'est quand même fait pour ça… On Jun 27, 2013, at 9:37 AM, Benjamin BILLON bbil...@splio.fr wrote: Hiho, local-pref pour la sortie, et prepend pour l'entrée. Sinon y'a ça : http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094934.shtml?referring_site=bodynav mais j'ai pas lu. SALUT. Benjamin Bonjour, Juste une petite question : Je dispose actuellement de 2 sessions BGP vers 2 transtaires différents. Chaque transitaire est branché sur un routeur différent. Ces 2 routeurs sont reliés via un Lan-to-Lan. Je voudrais savoir comment je peux à tout mon traffic (entrant et sortant) de passer uniquement sur un seul transitaire. On peut mettre en place le local-preference mais je ne suis pas convaincu... Avez-vous un retour d'expérience dessus? Merci. Etienne. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
Le 2013-06-27 12:00, Stephane Bortzmeyer a écrit : désolé d'avoir détourné la discussion. C'est un scandale ! Personne ne fait jamais cela sur Frnog ! Je suis poli, ma maman m'a bien élevé. ;) Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
Le 2013-06-27 11:53, Stephane Bortzmeyer a écrit : On Thu, Jun 27, 2013 at 11:34:36AM +0200, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 52 lines which said: Le remplacement du protocole WHOIS par un autre protocole n'implique pas la centralisation. Mais la discussion ne portait pas sur le protocole mais sur une proposition particulière, ARDS, dont la principale caractéristique est d'être centralisée. Mais, l'icann ne souhaite que cela, centraliser ! les noms de domaines le sont (hiérarchisé). les Ips en passe de le devenir. On ajoute la dessus une couche d'opérationnel, et la messe est dite... a+ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?
EM versus fibre, il y a une sacree difference. pas tant que ça quand tu as accès au media, il y a des techniques partiellement invasives qui n'alterent pas le signal. Pareil, ecouter un cable tout entier (plusieurs 100 de Gbps) pour sortir des morceaux bien choisis. hmmm il y a des meilleures approches. certes mais la on traite le cas specifique où le cable est dans des eaux étrangères et où n'a pas accès. Ne pas oublier, comme l'a dit Michel Py plus haut dans le thread, la taille de poches des gouvernements. pas difficile de submerger un container rempli de disques et le poser a coté de la fibre. d'ailleurs je viens de voir un truc que font les Arista et peut etre d'autres: il y a un FPGA embarqué user-programmable pour descendre des fonctions applicatives sur le switch, dans l'exemple c'etait un module de HFT. pourquoi ne pas imaginer un parseur wirerate? 2013/6/26 Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net On Wed, Jun 26, 2013, at 15:30, Michel Moriniaux wrote: http://en.wikipedia.org/wiki/Operation_Ivy_Bells pas de la fibre a l’époque, mais les techniques sont les mêmes, voir ci dessus le Jimmy Carter EM versus fibre, il y a une sacree difference. Pareil, ecouter un cable tout entier (plusieurs 100 de Gbps) pour sortir des morceaux bien choisis. hmmm il y a des meilleures approches. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Du fait qu'il soit optionnel comme attribut, son implémentation par les développeurs ou son support par un carrier ne sont pas garantis. Il est important de se mettre d'accord avec le peer au préalable, ou il sera ignoré par défaut. Cordialement 2013/6/27 Nicolas Strina nicolas.str...@jaguar-network.com Hello, Surement parce que la plupart des opérateurs avec des ASN à 3-4 chiffres (ou plus) ne savent pas l'honorer correctement ? Je vois pour nous .. On utilise clairement le MED et souvent .. Tout le monde s'en fout. Peer, uplinks, clients etc .. INGRESS ou EGRESS donc. J'ai pas mal d'ex. ou ça se passe très mal :) En tout cas bonne remarque pour le coup :) Bref .. -- Nicolas STRINA Jaguar Network Switzerland 19 Boulevard Georges Favon CH - 1204 Geneva More Than Your Hosting Company Tel : +33 4 88 00 65 16 Gsm : +33 6 18 20 49 55 Std : +41 8 40 65 61 11 Fax : +33 4 88 00 65 25 URL: http://www.jaguar-network.ch/ Support 24+7 : supp...@jaguar-network.ch Le 27 juin 2013 à 11:56, Fleuriot Damien m...@my.gd a écrit : Au risque de poser une question un peu noob, pourquoi vous utilisez du preprend en ingress au lieu du MED ? Le MED c'est quand même fait pour ça… On Jun 27, 2013, at 9:37 AM, Benjamin BILLON bbil...@splio.fr wrote: Hiho, local-pref pour la sortie, et prepend pour l'entrée. Sinon y'a ça : http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094934.shtml?referring_site=bodynav mais j'ai pas lu. SALUT. Benjamin Bonjour, Juste une petite question : Je dispose actuellement de 2 sessions BGP vers 2 transtaires différents. Chaque transitaire est branché sur un routeur différent. Ces 2 routeurs sont reliés via un Lan-to-Lan. Je voudrais savoir comment je peux à tout mon traffic (entrant et sortant) de passer uniquement sur un seul transitaire. On peut mettre en place le local-preference mais je ne suis pas convaincu... Avez-vous un retour d'expérience dessus? Merci. Etienne. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
On Thu, Jun 27, 2013, at 11:52, Mohamed Touré wrote: Bonjour Si ton equipement le supporte et que ton peer le supporte également et qu'il est d'accord pour le prendre en compte, l'attribut MED, optional et non transitive est une solution pour forcer ton traffic à entrer dans ton AS multihomed par un chemin précis. Le MED n'a strictement aucune valeur vers 2 AS differents. D'ailleurs le MED est non-transitif, donc il ne sera pas re-transmis par ton/tes upstream(s). Pour faire plus clair, toi (AS1) a deux upstreams (AS2 et AS3), et un autre AS (AS4) a les memes upstreams (AS2 et AS3). Si toi tu veux tout passer (in et out) via AS2, et que AS4 veut tout passer via AS3, tu fais comment pour le traffic entre AS1 et AS4 ? Ton localpref va forcer le traffic AS1-AS2-AS4, alors que le localpref d'AS4 va forcer le chemin AS4-AS3-AS1 (rappel, le localpref est prioritaire par rapport a la taille de l'AS-PATH). Si AS2 et AS3 peerent entre eux, en general ils vont appliquer leurs propres localprefs, pour forcer une route de type customer par rapport a une route de type peer. Vous allez avoir tous les deux du traffic entrant la ou vous le voulez pas. Il peut y avoir des solutions, mais ca depend du cas precis de chaque de tes upstreams (AS2 et AS3). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [tech] l'ICANN veut mettre fin a WHOIS
Même réaction ici, ça va encore se retrouver par accident centralisé aux US. Comme si l'ICANN, VeriSign et compagnie avaient déjà pas assez de pouvoir... On Jun 27, 2013, at 7:37 AM, Pierre Col - p...@9online.fr p...@9online.fr wrote: Sachant ce qu'on sait de PRISM, est-il raisonnable de centraliser (et vraisemblablement sur des serveurs aux USA) toutes les infos de l'annuaire mondial des noms de domaines ? Je ne le pense pas : bit.ly/newWHOIS - http://www.zdnet.fr/actualites/vers-une-refonte-en-profondeur-du-systeme-whois-avec-quels-risques-39791833.htm -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [tech] l'ICANN veut mettre fin a WHOIS
On 27.06.2013 13:16, Fleuriot Damien wrote: Même réaction ici, ça va encore se retrouver par accident centralisé aux US. Comme si l'ICANN, VeriSign et compagnie avaient déjà pas assez de pouvoir... avec la NSA en sous main, comme de bien entendu... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Le 27/06/2013 11:56, Fleuriot Damien a écrit : Le MED c'est quand même fait pour ça… Non. Le MED c'est fait pour plusieurs liens entre les deux mêmes AS, il n'a jamais été prévu que le MED doive être transmis au delà du premier AS. Il peut l'être, comme les communautés, mais il est d'usage de le shooter à l'export, ce qui le rend inutilisable dans d'autres cas de figure que le multiple-attachement de deux AS. La bonne utilisation du MED est dans le cas de plusieurs raccordement géographiquement répartis entre deux AS, il permet alors de mieux maitriser le routage entre ces deux AS en permettant le cold-potato de façon plus propre que par d'autres méthodes. Par défaut aucun speaker n'honore le MED. En Cisco, il faut : bgp deterministic-med et bgp always-compare-med L'impact des deux commandes est détaillé là : http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094925.shtml Dans le cas présenté en début de thread, local-pref en route-map IN et prepend en route-map OUT sont les plus simples. Ajouter les communautés de contrôle si les upstream le proposent. @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Le 27/06/2013 11:56, Fleuriot Damien a écrit : Au risque de poser une question un peu noob, pourquoi vous utilisez du preprend en ingress au lieu du MED ? Le MED c'est quand même fait pour ça… Mais, je lis « 2 sessions BGP vers 2 transtaires différents » ci-dessous. On utilise, normalement, MED pour choisir entre routes de même longueur de AS-path et même origine-code reçus d'un même AS dans des scenarios de multi-homing. Si on le souhaite, on peut - mais avec prudence (*) - enlever la condition « reçus d'un même AS », mais cela ne regle pas tout le problème posé par Etienne... Il pourrait utiliser ce « hack » afin de utiliser MED pour influencer la sortie de son traffic. Mais, ces deux fournisseurs ne se trouvent pas dans cette situation par rapport à lui. Cheers, mh (*) Donc rarement, voir jamais, fait par « transit networks ». On Jun 27, 2013, at 9:37 AM, Benjamin BILLON bbil...@splio.fr wrote: Hiho, local-pref pour la sortie, et prepend pour l'entrée. Sinon y'a ça : http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094934.shtml?referring_site=bodynav mais j'ai pas lu. SALUT. Benjamin Bonjour, Juste une petite question : Je dispose actuellement de 2 sessions BGP vers 2 transtaires différents. Chaque transitaire est branché sur un routeur différent. Ces 2 routeurs sont reliés via un Lan-to-Lan. Je voudrais savoir comment je peux à tout mon traffic (entrant et sortant) de passer uniquement sur un seul transitaire. On peut mettre en place le local-preference mais je ne suis pas convaincu... Avez-vous un retour d'expérience dessus? Merci. Etienne. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS
Le schéma de l'article semble indiqué que la centralisation correspond à une copie des data. Donc, oui, la NSA pourra toujours venir lire, mais normalement les registrars locaux gardent leur prérogative, non ? -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Frédéric Envoyé : jeudi 27 juin 2013 12:25 À : frnog@frnog.org Objet : Re: [FRnOG] Re: [tech] l'ICANN veut mettre fin a WHOIS Le 2013-06-27 11:53, Stephane Bortzmeyer a écrit : On Thu, Jun 27, 2013 at 11:34:36AM +0200, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 52 lines which said: Le remplacement du protocole WHOIS par un autre protocole n'implique pas la centralisation. Mais la discussion ne portait pas sur le protocole mais sur une proposition particulière, ARDS, dont la principale caractéristique est d'être centralisée. Mais, l'icann ne souhaite que cela, centraliser ! les noms de domaines le sont (hiérarchisé). les Ips en passe de le devenir. On ajoute la dessus une couche d'opérationnel, et la messe est dite... a+ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Le MED n'a de valeur que pour ton peer ! C'est une manière de forcer son LOCAL PREF à lui, car l'attribut MED est évalué avant ce dernier. S'il le prend en compte cela veut dire que tout le trafic vers AS1 (qu'il gère) passera localement sur le meme peering (du point de vue de ton peer uniquement).C'est une manière d'influencer son local pref pour ton trafic entrant. AS3 continuera bien entendu à envoyer ton trafic au plus proche c'est à dire sur son lien de peering avec toi. ça n'a aucun impact sur les autres peers qui vont router ton trafic destination au plus proche. Après AS2 peut aussi se mettre d'accord avec AS4 pour positionner son MED pour ton trafic. C'est pas très pratique, c'est vrai. Ce n'est pas une solution viable. Une solution utilisée jadis était AS-PATH preprend. L'AS PATH etant propagé partout permet d'influencer le trafic ce qui pouvait obliger AS3 à ne pas utiliser son lien direct avec AS1. On aurait eu AS3 -AS4-AS2-AS1 ou AS3-AS2-AS1 (s'il ya un peering entre AS2 et AS3). De ce fait AS1 absorberait tout le trafic de à destination de AS1. Mais seulement aujourd'hui cette méthode n'est plus fiable car l'AS-PATH peut etre ignoré dans le calcul du best path. Comme déjà discuté sur ce forum, une solution consiste plutot à faire des annonces conditionnelles. Cela consiste à annoncer tes prefixes à AS3 que si AS2 est down. Ce qui te garantit que AS2 sera toujours le meilleur chemin pour tes destinations, tant qu'il sera UP. Cordialement 2013/6/27 Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net On Thu, Jun 27, 2013, at 11:52, Mohamed Touré wrote: Bonjour Si ton equipement le supporte et que ton peer le supporte également et qu'il est d'accord pour le prendre en compte, l'attribut MED, optional et non transitive est une solution pour forcer ton traffic à entrer dans ton AS multihomed par un chemin précis. Le MED n'a strictement aucune valeur vers 2 AS differents. D'ailleurs le MED est non-transitif, donc il ne sera pas re-transmis par ton/tes upstream(s). Pour faire plus clair, toi (AS1) a deux upstreams (AS2 et AS3), et un autre AS (AS4) a les memes upstreams (AS2 et AS3). Si toi tu veux tout passer (in et out) via AS2, et que AS4 veut tout passer via AS3, tu fais comment pour le traffic entre AS1 et AS4 ? Ton localpref va forcer le traffic AS1-AS2-AS4, alors que le localpref d'AS4 va forcer le chemin AS4-AS3-AS1 (rappel, le localpref est prioritaire par rapport a la taille de l'AS-PATH). Si AS2 et AS3 peerent entre eux, en general ils vont appliquer leurs propres localprefs, pour forcer une route de type customer par rapport a une route de type peer. Vous allez avoir tous les deux du traffic entrant la ou vous le voulez pas. Il peut y avoir des solutions, mais ca depend du cas precis de chaque de tes upstreams (AS2 et AS3). -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Session BGP priorité
Errata ! Une erreur de ma part. Je viens de m'en rendre compte ! Le MED est évalué après le LOCAL_PREF. (confusion avec le WEIGHT) Oubliez ce que je viens de dire sur MED. Il faut lire aussi : AS2 et non AS1 On aurait eu AS3 -AS4-AS2-AS1 ou AS3-AS2-AS1 (s'il ya un peering entre AS2 et AS3). De ce fait AS2 absorberait tout le trafic de à destination de AS1. Mais seulement aujourd'hui cette méthode n'est plus fiable car l'AS-PATH peut etre ignoré dans le calcul du best path. Pour conclure, la solution avec les annonces conditionnelles peut etre une bonne piste. Cordialement 2013/6/27 Mohamed Touré mohamed.to...@secresys.com Le MED n'a de valeur que pour ton peer ! C'est une manière de forcer son LOCAL PREF à lui, car l'attribut MED est évalué avant ce dernier. S'il le prend en compte cela veut dire que tout le trafic vers AS1 (qu'il gère) passera localement sur le meme peering (du point de vue de ton peer uniquement).C'est une manière d'influencer son local pref pour ton trafic entrant. AS3 continuera bien entendu à envoyer ton trafic au plus proche c'est à dire sur son lien de peering avec toi. ça n'a aucun impact sur les autres peers qui vont router ton trafic destination au plus proche. Après AS2 peut aussi se mettre d'accord avec AS4 pour positionner son MED pour ton trafic. C'est pas très pratique, c'est vrai. Ce n'est pas une solution viable. Une solution utilisée jadis était AS-PATH preprend. L'AS PATH etant propagé partout permet d'influencer le trafic ce qui pouvait obliger AS3 à ne pas utiliser son lien direct avec AS1. On aurait eu AS3 -AS4-AS2-AS1 ou AS3-AS2-AS1 (s'il ya un peering entre AS2 et AS3). De ce fait AS1 absorberait tout le trafic de à destination de AS1. Mais seulement aujourd'hui cette méthode n'est plus fiable car l'AS-PATH peut etre ignoré dans le calcul du best path. Comme déjà discuté sur ce forum, une solution consiste plutot à faire des annonces conditionnelles. Cela consiste à annoncer tes prefixes à AS3 que si AS2 est down. Ce qui te garantit que AS2 sera toujours le meilleur chemin pour tes destinations, tant qu'il sera UP. Cordialement 2013/6/27 Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net On Thu, Jun 27, 2013, at 11:52, Mohamed Touré wrote: Bonjour Si ton equipement le supporte et que ton peer le supporte également et qu'il est d'accord pour le prendre en compte, l'attribut MED, optional et non transitive est une solution pour forcer ton traffic à entrer dans ton AS multihomed par un chemin précis. Le MED n'a strictement aucune valeur vers 2 AS differents. D'ailleurs le MED est non-transitif, donc il ne sera pas re-transmis par ton/tes upstream(s). Pour faire plus clair, toi (AS1) a deux upstreams (AS2 et AS3), et un autre AS (AS4) a les memes upstreams (AS2 et AS3). Si toi tu veux tout passer (in et out) via AS2, et que AS4 veut tout passer via AS3, tu fais comment pour le traffic entre AS1 et AS4 ? Ton localpref va forcer le traffic AS1-AS2-AS4, alors que le localpref d'AS4 va forcer le chemin AS4-AS3-AS1 (rappel, le localpref est prioritaire par rapport a la taille de l'AS-PATH). Si AS2 et AS3 peerent entre eux, en general ils vont appliquer leurs propres localprefs, pour forcer une route de type customer par rapport a une route de type peer. Vous allez avoir tous les deux du traffic entrant la ou vous le voulez pas. Il peut y avoir des solutions, mais ca depend du cas precis de chaque de tes upstreams (AS2 et AS3). -- Mohamed Touré 06 38 62 99 07 -- Mohamed Touré 06 38 62 99 07 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?
Le jeu., juin 27, 2013 at 09:03:50 +0200, Stephane Bortzmeyer claviotta : On Wed, Jun 26, 2013 at 10:17:06AM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 48 lines which said: S'il est vrai que les adresses du routeur lui-même risquent d'être bloquées, rien n'empêche le routeur de générer un paquet avec une IP qui circulerait librement. Attention, en TCP, c'est plus compliqué que cela car il faut recevoir les réponses. Scénario facile: il suffit d'avoir 2 PC qui communiquent et dont le trafic transite par hasard dans le routeur cœur de réseau en question, le dit routeur connaissant l'adresse de l'un des deux PC ou une signature quelconque à l'intérieur du paquet et interceptant le trafic pour y prendre ses instructions ou le modifier et y injecter ses trouvailles (faut pas oublier de refaire les checksums). Ah oui, cool idée, je savais bien que j'avais raison de demander sur cette liste. Je transmets l'idée à Pékin tout de suite et j'attends mon chèque. Et jusque là, le routeur il a stocké ses trouvailles sur quoi ? un disque dur ? :) On en revient au fait qu'un élément en trop dans un routeur, ça se verrait. Ou alors il a sélectionné les trouvailles intéressantes, possibilité déjà écartée par le manque de puissance. -- Guillaume Subiron Mail - maet...@subiron.org GPG - C7C4 455C Jabber - maet...@im.subiron.org IRC - maethor@(freenode|geeknode) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?
Le 27 juin 2013 à 17:18, Guillaume Subiron a écrit : Le jeu., juin 27, 2013 at 09:03:50 +0200, Stephane Bortzmeyer claviotta : On Wed, Jun 26, 2013 at 10:17:06AM -0700, Michel Py mic...@arneill-py.sacramento.ca.us wrote a message of 48 lines which said: S'il est vrai que les adresses du routeur lui-même risquent d'être bloquées, rien n'empêche le routeur de générer un paquet avec une IP qui circulerait librement. Attention, en TCP, c'est plus compliqué que cela car il faut recevoir les réponses. Scénario facile: il suffit d'avoir 2 PC qui communiquent et dont le trafic transite par hasard dans le routeur cœur de réseau en question, le dit routeur connaissant l'adresse de l'un des deux PC ou une signature quelconque à l'intérieur du paquet et interceptant le trafic pour y prendre ses instructions ou le modifier et y injecter ses trouvailles (faut pas oublier de refaire les checksums). Ah oui, cool idée, je savais bien que j'avais raison de demander sur cette liste. Je transmets l'idée à Pékin tout de suite et j'attends mon chèque. Et jusque là, le routeur il a stocké ses trouvailles sur quoi ? un disque dur ? :) On en revient au fait qu'un élément en trop dans un routeur, ça se verrait. Ou alors il a sélectionné les trouvailles intéressantes, possibilité déjà écartée par le manque de puissance. Un peu de place en RAM pour y stocker quelques Mo pendant quelques dixièmes de secondes. Et toi tu t'arranges d'avoir un ou plusieurs pings qui passent par ce routeur là toutes les secondes ou moins. En soit l'idée est pas idiote si tu cibles un trafic faible mais de haute valeur informative (mail par exemple). Cordialement Emmanuel Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?
Michel Py a écrit: Scénario facile: il suffit d'avoir 2 PC qui communiquent et dont le trafic transite par hasard dans le routeur cœur de réseau en question, le dit routeur connaissant l'adresse de l'un des deux PC ou une signature quelconque à l'intérieur du paquet et interceptant le trafic pour y prendre ses instructions ou le modifier et y injecter ses trouvailles (faut pas oublier de refaire les checksums). Stephane Bortzmeyer a écrit: Ah oui, cool idée, je savais bien que j'avais raison de demander sur cette liste. Je transmets l'idée à Pékin tout de suite et j'attends mon chèque. Tu n'oublies pas mes 20%, merci ! J'espère que tu n'en a pas besoin pour boucler ton mois ceci-dit; ce que j'ai décrit c'est le ba-ba simpliste que tout le monde connaît depuis 15 ans. Si c'était secret je ne l'écrirais pas sur la liste du FRnOG. Guillaume Subiron a écrit: Et jusque là, le routeur il a stocké ses trouvailles sur quoi ? un disque dur ? :) La flash c'est plus petit. On en revient au fait qu'un élément en trop dans un routeur, ça se verrait. Pas d'accord du tout. Un routeur cœur de réseau, c'est un châssis de taille non négligeable qui contient plein de trucs dont très peu de monde savent complètement qui fait quoi. En plus, je vois tout le temps des cartes avec des composants manquants. La raison est que les usines travaillent en flux tendus, et qu'on soude sur la carte le composant qui est en stock au moment de la fabrication. Tu achètes la même carte 2 jours différents, tu pourrais trouver que l'une a été faite en Asie et l'autre en Amérique latine, et que la moitié des composants ne sont pas les mêmes. La place vide sur la carte qui recevrait le mythique ASIC d'espionnage, ça ne se remarque pas; et quand il est installé, surtout si un autre composant est manquant, ça se remarque difficilement. Le problème de détecter ce genre de chose dans un routeur cœur de réseau, c'est que tu n'as en général pas le routeur à ta disposition pour faire joujou. Ou alors il a sélectionné les trouvailles intéressantes, possibilité déjà écartée par le manque de puissance. Pas du tout, suffit d'avoir l'ASIC qui va bien. Emmanuel Thierry a écrit: Un peu de place en RAM pour y stocker quelques Mo pendant quelques dixièmes de secondes. Et toi tu t'arranges d'avoir un ou plusieurs pings qui passent par ce routeur là toutes les secondes ou moins. +1; Remplace les quelques pings par un flux télé HD et ça commence à devenir sympa. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?
On 27/06/2013 17:25, Emmanuel Thierry wrote: Scénario facile: il suffit d'avoir 2 PC qui communiquent et dont le trafic transite par hasard dans le routeur cœur de réseau en question, le dit routeur connaissant l'adresse de l'un des deux PC ou une signature quelconque à l'intérieur du paquet et interceptant le trafic pour y prendre ses instructions ou le modifier et y injecter ses trouvailles (faut pas oublier de refaire les checksums). Et jusque là, le routeur il a stocké ses trouvailles sur quoi ? un disque dur ? :) On en revient au fait qu'un élément en trop dans un routeur, ça se verrait. Ou alors il a sélectionné les trouvailles intéressantes, possibilité déjà écartée par le manque de puissance. Un peu de place en RAM pour y stocker quelques Mo pendant quelques dixièmes de secondes. Non vous avez mal lu l'idée de Michel : un trafic bidon entre 2 PC qui passe par le routeur, avec un payload qui contient du bourrage. En temps normal le routeur est passif et route normalement le trafic vers la destination. Quand le PC source envoie le bon pattern dans le payload, le routeur est activé et remplace le bourrage par de vraies info, refait le checksum et fait suivre au PC collecteur comme si de rien n'était. Le trafic semble n'avoir pas changé, ni vu ni connu. Suffit de mettre plus de bourrage en entrée pour faire sortir plus de données tout aussi discrètement. --- Liste de diffusion du FRnOG http://www.frnog.org/
