from:"Stephane Le Men"

Re: [FRnOG] Re: [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-27 Par sujet Stephane Le Men


Le 26/07/2012 15:00, Michel Moriniaux a écrit :

depuis que nous suivons vos interventions vous etes très evasif sur la
solution qui selon vous sauverait le monde.


Il me semble avoir déjà donné les principes qui guident ma démarche.

Elle consiste juste à rappeler que si un opérateur se doit de vendre des 
routes à ses clients, ses clients attendent que des circuits se ferment 
correctement au travers de son infra. Même si le client n'utilise qu'une 
fraction du circuit, l'opérateur se doit de vendre des circuits qui se 
ferment.


Alors je me dis que si le circuit mis à disposition du client a été 
vérifié avant, par un automate, la vérification devrait répondre au 
problème.



Vous semblez detenir une
verité que personne n'ici ne peut effleurer vu le ton de vos mails.


J'ai une expérience qui fait que si j'avais été actionnaire de Virgin 
Mobile, j'aurais exigé la tête du pédégé pour ne pas avoir été capable 
de pouvoir migrer en un claquement doigt tous mes utilisateurs de Orange 
à SFR pour préserver le service que je vends à mes clients.


Et à ce conseil d'administration virtuel, on m'aurait répondu:

- mais nous avions demandé à la signature du contrat, mais on nous a 
répondu vous rigolez ?


j'aurais ensuite répondu:

- c'est le moment d'aller taper du point sur la table de l'Arcep.

Alors, le rapport qu'il y a entre Virgin et Neo, c'est la même cause, 
cette fameuse lutte des classes qui n'est pas has been.


Du coup, je prend un peu de plaisir à remuer le couteau dans la plaie. 
Il ne faut pas m'en vouloir, l'occasion était trop belle.




Je vous propose afin de calmer l'ambiance sur la ML de vous mettre a
votre plume et d'expliciter ces designs si resilients et de citer vos
sources plutot que de nous poser la question de ce que nous pensons
être la réponse.


ok, je vais tenter


Nous attendons toujours les docs demandées par
Stephane Bortzmeyer la derniere fois.



J'ai fini par trouver un document où il n'y a que 2 paragraphes à lire 
d'intéressant:


http://www.gsma.com/newsroom/wp-content/uploads/2012/03/ir3470.pdf

Point 3.6
Isolation between Service Communities on an Inter-Service Provider IP 
Backbone network can be logical (for example by VPNs on an Inter-Service 
Provider IP Backbone network) or physical (that is when the Service 
Provider connects to separate Inter-Service Provider IP Backbone 
networks, for example for GRX and an IPX Service).


4.3
In order to maintain isolation between Service Communities where Inter 
Service Provider Backbone networks are interconnected, separate VLANs 
and separate routing tables must be used for each Service Community



Le reste des contraintes qui sont listés dans ce document vous pouvez 
les jeter, on n'a pas besoin pour Internet.




La pluspart des membres actifs sur cette ML font vivre au jour le jour
des réseaux ayant presque tous des designs differents a toutes les
echelles, personellement j'ai connu un backbone tier 1 a budget
illimité satisfaisant votre laius sur les designs Sigtran mais il ne
permettait pas de se premunir des route-leak et hijack. Je suis
curieux de voir les differences de design entre votre modele et ceux
que je connais.


Est-ce qu'en lisant les 6 lignes, vous comprenez pourquoi votre tiers 1 
à budget illimité n'a pas su être satisfait avec sa configuration 
SIGTRAN sur un seul domaine de routage ?


Traduit en bon français, cette phrase anglaise demande que deux domaines 
de routages coexistent dans un GRX et qu'ils soient logiquement ou 
physiquement séparés. En ayant deux domaines de routage séparés, quand 
un domaine subit un route-leak ou un hitjak, l'étanchéité des deux 
domaines de routages offre une roue de secours sur le deuxième domaine 
qui n'est pas contaminé.


Votre tiers 1 à budget illimité n'a su déployé deux domaines de routages 
distincts dans son réseau, et c'est pour cette raison qu'il n'a pas été 
satisfait de sa conf SIGTRAN. Le plus petit domaine de routage possible 
utilisable est simplement un lien physique ou logique L2 à accoupler 
avec son réseau normal. (et il ne faut que l’état du lien L2 logique ne 
dépende pas de l'état du routing de son réseau. il faut preserver 
l'isolation)


SCTP est un transport sur 4 ip distincts, pour pouvoir être déployé sur 
des réseaux à deux domaines de routages distincts et étanches.

C'est l’étanchéité qui garanti la qualité.
C'est rappelé au point 4.3 du doc.

D'accord ou pas d'accord ?


bref soyons constructifs et apprenons tous ensemble!


Ben, je pose la question de savoir si cela sera utile. Voyez-vous, j'ai 
beaucoup de mal à croire qu'il existe dans le monde un tiers 1 qui 
déploie SIGTRAN sur un seul domaine de routing. Face à cette 
information, je me dis:


- soit, on me ment éhonteusement pour me faire raconter n'importe quoi.

- soit c'est bien vrai, il existe bien un tiers 1 qui déploie SIGTRAN 
sur un seul domaine de routing, et là, je suis scié. Incoyable et aucun 
client qui l'utilise ne s'en est rendu compte.
Encore plus

Re: [FRnOG] [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-26 Par sujet Stephane Le Men


Le 26/07/2012 10:46, Raphael MAUNIER a écrit :

heu, non



Dans ce cas là, il faut prendre rendez-vous l'ANSSI, il devrait être 
capable de vous expliquer où est le SPOF de votre conf BGP via à vis de 
3215.


Envoyez un Cisco en Chocolat à cet opérateur pour le remercier de vous 
montrer.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-26 Par sujet Stephane Le Men


Le 26/07/2012 10:57, Nicolas Strina a écrit :

Dans ce cas là, il faut prendre rendez-vous l'ANSSI, il devrait
être capable de vous expliquer où est le SPOF de

votre conf BGP via à vis de 3215.



C'est quoi le rapport ?



Le rapport c'est qu'il vient de prendre le service de circuit sur 
l’Internet avec 3215. Avant d'être un incident de sécurité, c'est un 
incident de service, de résilience.


Alors, je repose ma question, c'est quoi l'AS canonique d'une conf BGP 
résiliente, votre référence, votre mètre étalon de la résilience ?


On choisit ce que l'on veut pour répondre à cette question, et si on 
choisit les bonnes définitions, on a les bonnes conditions à réunir pour 
se prémunir.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-26 Par sujet Stephane Le Men


Le 26/07/2012 11:22, Jérémy Martin a écrit :

Wow, Stéphane, tu as fumé quoi ce matin ? :)


C'est peut être vrai. Je suis nul en français et je m'en excuse auprès 
de mes lecteurs.



Le rapport c'est qu'il vient de prendre le service de circuit sur
l’Internet avec 3215. Avant d'être un incident de sécurité, c'est un
incident de service, de résilience.


il fallait perdre pas prendre, je lis et me relis tres mal je me 
reconnais cette faiblesse, si vous arrivez à me l'excuser.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-26 Par sujet Stephane Le Men


Le 26/07/2012 11:32, Raphael Maunier a écrit :

Je pense que tu as raison, je vais cesser d'expliquer quoique ce soit,
surtout vu la deuxieme reponse.:)


Vous n'avez rien à expliquer, nous n'avons qu'à constater.

Ce qui est visible de l’extérieur décrit en partie ce qui se passe à 
l’intérieur. C'est comme quand on est médecin et qu'on ne peut pas se 
permettre d'ouvrir la patient juste pour voir à l’intérieur.


En allant au bout du raisonnement que je vous propose d'avoir sur la 
résilience de votre réseau, et pourquoi elle n'est pas au niveau 
attendue ou espérée, je pense que vous identifierez mieux à qui 
profitera réellement le déploiement de RPKI, par exemple, dans le but 
d'essayer d'améliorer cette résilience plutôt que de faire ce qui aurait 
du être fait au niveau de son architecture.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-26 Par sujet Stephane Le Men


Le 26/07/2012 12:09, Richard DEMONGEOT a écrit :

Vu les trois points, RPKI ou non, le résultat est le même.



Ma compréhension est que dans l'hypothèse où RPKI est déployé et activé, 
il aurait du couvrir ce problème d'annonces erronées.

D'où l'invitation au troll de l'OP.


L'important reste donc (encore) la réactivité des équipes techniques, et
en l'occurence, 25 minutes c'est plus que raisonnable.


C'est selon les jugements excellent ou lamentable. Si personne n'a rien 
vu, il n'y a rien à dire, si cela a été le tsunami au support, le 
responsable du support donnera sa propre appréciation de l'incident.




Concernant la résilience :
Orange n'est qu'une partie d'internet (certes importante pour le marché
Francophone), mais une partie d'internet, et un AS parmis tant d'autres.
(et encore, pas tout 3215 n'a été impacté à priori).


Un AS parmi tant d'autre dans la table des ASN, mais quelle fraction 
trafic de l'AS, 1%, 10% , 30% ? Il n'y a que le propriétaire de l'AS qui 
peut répondre. Et cette fraction de trafic, c'est une fraction de son 
service qu'il vend, et non pas 1 divisé par nombre d'AS de la table des 
ASN de l'Internet.




Est ce qu'il y a eu une coupure Internet ? Non. Il y a eu un incident sur
une partie d'internet. La résilience doit être mesurée sur quelle partie
d'internet?


Sur chaque fraction de son trafic. A priori, rares sont les AS qui 
discutent uniformément en terme de volumétrie avec le reste de la 
planète. Chaque AS a son profil volumétrique.
Je pense que si 99% de votre trafic ne se fait qu'avec 1 seul autre AS, 
cet AS mérite 99% de votre attention.


Je suis partisan de cette répartition plutôt que d'une répartition qui 
consiste à se préoccuper de toutes les AS, y compris celles avec qui on 
n'a pas ou très peu de trafic.




Enfin, mode avocat du diable :
Le problème viens du fait qu'un AS a émis des routes vérreuses. Avec moins
de résilience (aucun peering uniquement des upstreams), l'impact aurai été
moins visible.

Là encore, la résillience ne peut être mesurée sur des données aussi
faibles, un acteur donné.



J'ai la croyance qu'il vaut mieux diviser le problème de résilience pour 
y régner dessus, et je crois que la résilience globale obtenue d'un 
système ou d'un réseau n'est que la réunion de chacun de petits morceaux 
individuels de résilience du système.


Du coup, quand il y a un problème avec une destination, ce problème dit 
quelque chose sur un petit morceau de résilience du réseau.


Et normalement dans un réseau résilient, avant de perdre un service, 
on a perdu la résilience. Perdre un service, c'est une double faute.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [ALERT] Trouble dans la force ( soucis vers AS3215 )

2012-07-26 Par sujet Stephane Le Men


Le 26/07/2012 13:32, Damien Fleuriot a écrit :

Alors je vais être un peu sec mais c'est une réponse très conne.

Encore heureux que Neo ne nous accorde pas de l'attention qu'en fonction
de notre*trafic*  parce que ce qui peut représenter 3% pour eux, pour
nous c'est de la*prod*  et notre gagne-pain.


A supposé qu'un opérateur n'ait de résilience nul part, et qu'il cherche 
en acquérir une, est-ce que ses investissements seront proportionnels à 
son trafic ou l'opposé, est-ce qu'il va consacrer 6% de son budget 
résilience à 3% de son trafic ?


Pour que votre opérateur ne soit neutre vis à vis de votre trafic, et 
qu'il le discrimine par rapport autres, je pense qu'il va falloir payer, 
et payer plus que les autres clients.


La disponibilité, c'est comme le filtrage de paquets, elle peut être 
plus ou moins neutre.






---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?

2012-07-09 Par sujet Stephane Le Men


On 07/08/2012 01:28 PM, Xavier Hinfray wrote:


c est décentralisé. mais quand un bug logiciel fait planter un bout
du hlr , celui ci passe sur un autre noeud. et l autre noeud plante à
son tour un peu plus tard à cause du même bug bref, décentralisé
ne change rien pour ce type de problème.


Il y a un problème avec ce que vous dites, c'est que quand on lit des 
difficultés à envoyer des SMS dans la presse et qu'on connait un peu 
les réseaux, il suffit de trouver le call-flow d'un SMS pour voir où et 
quand le HLR intervient.


http://en.wikipedia.org/wiki/Short_message_service_technical_realisation_%28GSM%29 



Dans l'envoi du SMS le HLR n'intervient pas. Dans la réception 
seulement. Dans la presse, on n'a pas lu difficultés à recevoir, mais 
difficultés à envoyer. Le HLR ne peut donc pas être en cause dans les 
problèmes d'envoi d'un SMS.


On peut refaire la même recherche pour la data:

http://www.scribd.com/doc/57489605/GPRS-Call-Flow

Donc dire que le HLR est la cause des difficultés d'envoi de SMS ou pour 
l'accès Internet est équivalent à dire que quand on obtient no route to 
host à la commande telnet 10.10.10.1, c'est de la faute au DNS qui ne 
marche pas.


Je suis désolé de vous dire cela, mais ce sont les call-flow qui le 
disent, moi je ne fais que le remarquer.


Le call-flow de wikipédia pour un sms-mo n'est pas complet, on peut le 
modifier dans le HLR pour interroger un billing.


D’après cette page, France Telecom aurait cette plateforme:

http://wwwen.zte.com.cn/en/solutions/vas/consumer/200912/t20091224_179017.html

A partir des infos publiés dans la presse, le problème de vendredi 
ressemble beaucoup plus à une scène de ménage entre FranceTelecom et sa 
plateforme de billing ZTE plutôt qu'un problème de HLR.


Le HLR, c'est plutôt le système sur lequel on se jette pour tenter de 
donner un peu d'oxygène à son billing en plein d’évanouissement et qu'on 
ne sait pas quoi faire d'autre.


L'interview au Figaro donne lance une hypothèse, le passage en 
production sur le billing d'une nouvelle configuration, d'une nouvelle 
offre commerciales ... insuffisamment qualifiée et qui a d'abord fait 
trébuché le billing pour ensuite le planter.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?

2012-07-09 Par sujet Stephane Le Men


On 07/09/2012 06:33 PM, Alain Thivillon wrote:


en 2G, le réseau impose une réauthentification du mobile à chaque
utilisation de ressource


en 2G, mais ce sont des utilisateurs 3G qui ont été impactés, et en 
plus grand nombre.


La différence entre un échec authentification sur l'AuC et une demande 
de token de ressource non acquittée par le billing est parfaitement 
identifiable avec l'état du téléphone. L'information qui permet de 
trancher a été rapportée des clients dans la presse.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France

2012-06-28 Par sujet Stephane Le Men


On 06/27/2012 11:36 PM, Radu-Adrian Feurdean wrote:

  Quand on connait SIGTRAN, on peut vous poser la question: est-ce
  possible d'avoir deux vues indépendantes de BGP qui cohabitent
  simultanément sur des infras dédiés et où le trafic est loadbalancé ?

Load-balance entre quoi et quoi ?



Entre les deux infrastructures réseaux indépendantes qui a chacun sa 
propre vu BGP du réseau. Les deux vu BGP ne se connaissent pas, (et si 
chacun respecte bien la règle d'isolation)



Deja que faire du pur per-packet quand on maitrise les deux bouts de
chaque tuyau fait peur a certains (pas forcement sans raison).


Il suffit de demande à son constructeur, il enverra quelqu'un qui sait 
faire.




  Est-ce que vous voyez ce qu'il faut faire pour connecter deux routeurs
  BGP ensemble, sans qu'il peer, en maintenant chacun une vue BGP
  indépendante sur son infra ? (sur la partie LAN aussi, L2 et L3)

Un cable ?


Oui un cable entre eux, et deux switchs un pour chaque routeur, c'est 
aussi possible avec un seul switch aussi, il faut la conf, le truc qui 
fera que les vues seront étanches et que cela marchera aussi au niveau 
du LAN.



2 routeurs BGP sans session BGP entre eux, pas la peine de parler de
BGP.


Entre eux, non il ne faut pas, mais avec le reste du monde il faudra 
bien. C'est parce que vous n'avez jamais branché autre chose qu'un 
switch ou un bond Linux derrière un trunk Ethernet. Mais on peut aussi y 
brancher autre chose comme par exemple, une paires de routeurs 
indépendants, avec chacun sa vue bgp qui ignore l'autre.


Deux plans BGP l'un au dessus de l'autre, indépendant, connecté par un 
trunk avec les machines au milieu, entre les deux plans. Est-ce que vous 
voyez cela dans vos têtes ?


Mais bon, je ne me fais pas d'illusion de vous convaincre. Quand j'ai 
commencé à faire de la signalisation SS7 sur IP il y a 15 ans, on se 
faisait traiter de clochards des réseaux par les gens de TDM. A l'époque 
je ne comprenais pas pourquoi se faisait traiter de clochards mais 
c'était parce que j'y connaissais rien en TDM. Ils disaient si je me 
souviens bien 'remplacer TDM par IP, c'est faire comme Christophe Colomb 
mais avec un équipage de clochards'.


Si vous allez voir aujourd'hui les gens qui gèrent un réseau SIGTRAN et 
vous demandez d’évaluer la possibilité de mettre à niveau BGP à celui de 
SIGTRAN, ils vont vous dire avec cette bande de clochards ?


Moi, je suis plus cool qu'eux, je vous dit que c'est possible, simple à 
déployer, à peine plus compliqué à opérer mais surtout super simple à 
faire évoluer grâce à l’indépendance des vus BGP qui peuvent se secourir 
l'une l'autre.


Voilà, donc il n'y plus qu'à attendre le prochain test du RIPE avec un 
nouvel attribut BGP à la mode pour planter l'unique vue BGP existante. 
On verra sortir les guenilles de leurs boites en cartons.


Parce qu'en plus avec BGP, il n'y a même pas besoin d'acheter du matos 
pour migrer vers cette conf dual view, il y a juste besoin de repenser 
et reconfigurer.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France

2012-06-27 Par sujet Stephane Le Men


On 06/27/2012 02:23 PM, Jérôme Nicolle wrote:


l n'y a que 163 AS français

Source ?


Bien vu, j'avais mal lu, seulement connectés aux 4 AS testés :

nous avons pu déterminer que 163 d’entre eux sont à forte concentration 
géographique française.



Mais cela ne change rien au problème:

Si tu n'as pas de fonction mathématiques pour comparer deux 
architectures qui donne en résultat celle-ci est meilleur que l'autre 
en terme de résilience, je vois mal comment détecter les faiblesses et 
les supprimer.


La résilience, c'est comme la radioactivité, cela ne se voit pas, il 
faut construire un détecteur pour la voir, et ce détecteur a comme tous 
les détecteurs une sensibilité et un mode d'emploi.


Sur SS7, il y a déjà tout un travail de fait, qui n'est pas transposable 
directement pour Internet. Je suis étonné de ne pas le retrouver 
mentionné dans ce type de document, notamment dans l'architecture des 
réseaux SIGTRAN. Il y des contraintes qui sont pénibles dans SIGTRAN 
mais elles garantissent un niveau de résilience  qui guident 
l'opérationnel et le déploiement du réseau.


Transposer sur Internet les règles d'architectures SIGTRAN ne devrait 
pas en amuser beaucoup et faire hurler tout le monde au 
crypto-téléphoniste-stalinien en pleine lutte des classes mais les 
réseaux téléphoniques existent depuis plus longtemps que l'Internet, 
avec une expérience opérationnelle de la résilience qui à pondu SIGTRAN, 
réseau IP SS7 international, dont je ne connais pas la taille actuelle, 
mais qui couvrira la planète quand tous les vieux machins TDM seront 
chez Emmaüs. Et ce sont des fonctions mathématiques comme celles dont je 
parle plus haut qui ont conduit à SIGTRAN.


Mettre l'Internet au même niveau qu'un réseau SIGTRAN, c'est possible.

Quand on connait SIGTRAN, on peut vous poser la question: est-ce 
possible d'avoir deux vues indépendantes de BGP qui cohabitent 
simultanément sur des infras dédiés et où le trafic est loadbalancé ?


Est-ce que vous voyez ce qu'il faut faire pour connecter deux routeurs 
BGP ensemble, sans qu'il peer, en maintenant chacun une vue BGP 
indépendante sur son infra ? (sur la partie LAN aussi, L2 et L3)


Avec trois vue BGP indépendantes avec trois routers ?

C'est le même théorème de math qui s'applique sur les liens, peut aussi 
s'appliquer à la signalisation. Il faut juste avoir envie de le faire.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Rapport sur la résilience de l'Internet en France

2012-06-26 Par sujet Stephane Le Men


On 06/26/2012 09:38 AM, Stephane Bortzmeyer wrote:


http://www.ssi.gouv.fr/fr/menu/actualites/l-anssi-et-l-afnic-publie-un-etat-des-lieux-de-l-internet-francais.html
  ».
Il s'agit d'étudier*quantitativement*  la résilience de l'Internet
dans ce pays (oui, je sais, l'Internet est mondial, mais il faut bien
commencer quelque part). Le rapport définit donc un certain nombre
d'indicateurs puis les mesure et publie le résultat.


J'aurais trouvé utile de fournir une formule mathématique à appliquer 
sur les paramètres de son propre AS, histoire de ne pas avoir besoin de 
prendre rendez-vous avec ANSSI pour savoir si oui ou non, le dit AS est 
suffisamment connecté, et se comparer aux exemples d'AS donnés dans le 
rapport.


Je reconnais qu'il y a une contradiction entre le besoin d'anonymiser 
les AS tout en fournissant un moyen de mesure, parce qu'il n'y a que 163 
AS français et que les données utilisées par le rapport sont publiques.


Si la mesure est bien choisie, il y a peu de chance pour que deux AS 
aient au final, la même mesure dans seulement 163 AS.


Qui dit mesure, dit étalon, je serais curieux de connaitre la 
description de l'AS étalon par l'ANSSI, pour que chacun puisse mesurer 
la distance qui le sépare cet AS (et donc connaitre les efforts à 
fournir, ou de se dire ouf, je suis bon).







---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [MISC] détenteurs d'AS, l'ARCEP veut tout savoir sur vos peerings

2012-04-05 Par sujet Stephane Le Men


On 04/04/2012 09:26 PM, Stephane Bortzmeyer wrote:

On Wed, Apr 04, 2012 at 09:00:14AM -0700,
  Michel Pymic...@arneill-py.sacramento.ca.us  wrote
  a message of 14 lines which said:


Je le sais très bien mais euh,  çà c'est quoi ?
http://www.arcep.fr/index.php?id=10396
Un régulateur qui cite de genre de source, ça me fait froid dans le dos.


Je ne connaissais pas. Oui, c'est inquiétant.


Il faut savoir entendre entre le mots de ce monsieur.

Le messianisme de Riguidel vise cette architecture des réseaux:

http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem

Pour ceux qui connaissent, ils retrouvent dans le discours de Riguidel 
tous les petits que peut produire cette architecture.


L'IMS couvre le mobile et le fixe

Le sous ensemble de la partie fixe c'est TISPAN

http://en.wikipedia.org/wiki/Telecoms_%26_Internet_converged_Services_%26_Protocols_for_Advanced_Networks


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] détenteurs d'AS, l'ARCEP veut tout savoir sur vos peerings

2012-04-05 Par sujet Stephane Le Men


On 04/05/2012 07:45 PM, Guillaume Mellier wrote:


En tout état de cause, l’ARCEP n’a pas aujourd’hui l’intention de réguler
ce marché de l’interconnexion IP.


Vu que l'autorité de la concurrence a validé l'exigence d'une 
facturation à Cogent dans l'affaire MU, et qu'un acteur comme Google est 
en préparation d'entrer sur le marché de la TV sur IP particulièrement 
consommatrice de ressource réseau, il me semble logique pour Google de 
se lancer directement sur le marché de l'ADSL ou de la fibre plutôt que 
de financer ad vitam æternam et à fonds perdus des réseaux qui ne lui 
appartiennent pas.


Si l'autorité de la concurrence ne veut pas prendre la défense des 
petits acteurs face aux gros acteurs, je subodore que la mise à mort des 
FAI français par Google sera sans pitié.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] ROVER: une technique alternative de sécurisation de BGP

2012-03-28 Par sujet Stephane Le Men


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

2012-03-28 Par sujet Stephane Le Men


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

2012-03-27 Par sujet Stephane Le Men


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] 2012, fin du monde, Anonymous, racine du DNS et autres mots-clés

2012-02-24 Par sujet Stephane Le Men


On 02/23/2012 10:52 PM, Jean-Philippe Pick wrote:


Merci beaucoup, mais votre liste n'est pas du tout à jour :


Hier, j'ai noté que le fr. donnait cela en France:

dig +short ns fr.
c.nic.fr.
g.ext.nic.fr.
d.nic.fr.
d.ext.nic.fr.
e.ext.nic.fr.
f.ext.nic.fr.

Aujourd'hui il me donne cela:

f.ext.nic.fr.
d.ext.nic.fr.
g.ext.nic.fr.
e.ext.nic.fr.
d.nic.fr.

Hier, en Allemagne, j'ai eu la même réponse qu'aujourd'hui en France.
J'ai fait une supposition très olé olé, que selon la cellule, vous 
pouviez ne pas présenter le même ensemble de noms de serveur à des fins 
d'identification et/ou de leurres. Du coup, j'ai résolu tous les 
{a..g}.nic.fr et {a..g}.ext.nic.fr car j'ai échoué à trouver un resolver 
chinois et j'ai testé toutes ces IP n’étant pas sûr de savoir quels noms 
vous présentiez en Chine.


Pour votre information, j'ai un ami qui va souvent à Yiwu pour du 
commerce. Il m'a raconté que quand il ferme la porte de la chambre de 
son hôtel, le pc (appartenant à l’hôtel) est totalement réinitialisé.
N'étant pas informaticien, il n'a pas su me dire si le câble Ethernet 
était accessible, mais à priori, on ne doit pas pouvoir l'utiliser.


Et à lui, cela ne lui a posé aucun problème d'utiliser celui de 
l’hôtel plutôt que son PC.


Quand je vois cela, je suis près à parier que le réceptionniste de 
l’hôtel a une petite case à cocher pour les étrangers qui va 
directement configurer le réseau pour ce pc avec un profil étranger.


Pour eux, on est des barbares, et j'accorde une confiance toute 
relative au traceroute que je vous ai donné. S'ils ne laissent pas 
sortir librement leurs citoyens sur le réseau, il n'y a pas de raison 
qu'ils laissent les étrangers y entrer et s'y promener seuls sur leur 
territoire.


C'est pour cela que je suppose que bien qu'à Pekin, votre cellule soit 
quand même à l’extérieur de Chine d'un point de vue réseau. Pour le 
savoir il n'y a pas d'autre moyen que d'aller le vérifier sur place.


Je vous dis cela, parce que si mes soupçons sont vrais, vous ne devriez 
pas payer pour une cellule qui fonctionne dans un village Potemkine.

Et peut être qu'elle ne sert que les étrangers qui sont Chine.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] 2012, fin du monde, Anonymous, racine du DNS et autres mots-clés

2012-02-23 Par sujet Stephane Le Men


On 02/21/2012 09:57 AM, Stephane Bortzmeyer wrote:


Juste que le plan d'attaque envoyé sur
pastebin était très insuffisant : ce n'est pas comme ça qu'on fait
tomber la racine.



On, (je m') s'en fout se savoir comment cela se passera, cela ne 
m'intéresse pas. Cette question là n'intéressera que les légistes à 
prendre dans le sens de médecin légiste. Ils ouvriront le cadavre et 
diront :


ha, c'est à cause de ça, là.

Mais ce sera trop tard, exactement comme dans la Chine ancienne, lorsque 
les médecins du souverain échouaient à leur mission, préserver la santé 
du souverain plutôt que de soigner ses maux. Exact l'inverse de notre 
médecine actuelle, et exactement le job de certains aujourd'hui. A cette 
époque, la santé des médecins du souverain se dégradait encore très vite 
et plus gravement s'ils avaient failli à leur mission. Aujourd'hui, 
c'est la responsabilité ou le contrat de travail qui se dégrade à la 
place de sa santé.




Et, oui, le problème de planter la racine du DNS est très
difficile. Preuve expérimentale : deux attaques d'ampleur ont été
faites, en 2002 et 2007, et ont échoué.


Parlez en au pro de la crypto, ils auront plein de belles histoires à 
vous raconter qui commencent comme la vôtre.




Les b/s sont une mauvaise métrique pour un serveur DNS. C'est plutôt
les p/s qu'il faut prendre en compte.


Un serveur DNS est connecté à un réseau, qui lui a une métrique en b/s.
Le débit d'une fibre se mesure en b/s pas en p/s.
Le p/s c'est l'unité des systèmes entre les fibres, pas du réseau de 
fibre. C'est b/s qui borne le p/s en fonction du protocole.


A force de regarder l’état de vos systèmes vous en oubliez les fibres au 
milieu qui ne font rien d'autre que de limiter le tout.


Le b/s est l'unité du concepteur qui calcule les limites de son design, 
le p/s est l'unité de l'administrateur qui administre le design.



La signalisation BGP des borders de la racine a-t-elle été modifié
pour devenir out-of-band plutôt que in-band comme sur quasiment tous
les routeurs du monde.


Cela dépend des serveurs racine.


Enfin une bonne nouvelle, et tous les opérateurs qui ont refusé de le 
faire la lâcheront à son sort le moment venu comme lorsque les rats 
quittent un navire qui coule. Ils veulent bien dire je connecte la 
racine pour la pub, mais quand il faut assumer jusqu'au bout, il n'y a 
plus personne.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] 2012, fin du monde, Anonymous, racine du DNS et autres mots-clés

2012-02-23 Par sujet Stephane Le Men


On 02/21/2012 09:57 AM, Stephane Bortzmeyer wrote:

On Mon, Feb 20, 2012 at 02:43:42PM +0100,
  Stephane Le Menstephane.le...@anycast-networks.com  wrote
  a message of 19 lines which said:


Si un éléphant a le coeur d'une souris, il va avoir de sérieux
problèmes.  Apparemment ce n'est pas possible, mais c'est quand même
possible quand l'éléphant a une malformation cardiaque.


Très poétique, mais je ne comprends toujours pas.



C'est parce que vous n'avez pas fait assez de benchmarks.

Quand le codeur d'un service vient vous voir pour un bench de son 
service, l'intégrateur prend un serveur pour exécuter le service, un 
autre serveur pour être le trafic générateur et au milieu, il met un réseau.


A force de faire des benchs de services, on finit par anticiper 
facilement où seront les goulots d'étranglement. C'est pareil pour les 
SAN, cela se voir aussi, soit du coté système quand le service est 
compliqué, soit du coté réseau quand cela booste coté service.


Et les fonctions aussi simple que le DNS sont quand même assez rares.

Et pour l'intégrateur, un DDOS c'est ni plus ni moins qu'un benchmark 
imposé à sa ligne de production. Virus ou pas virus, psychose ou pas 
psychose, émeute de paquets ou pas émeute de paquets.


Qu'aurait fait X. Neil si tous les Freenautes avait été aussi borné 
qu'un virus sur son web d'inscription lors de son lancement ? Il aurait 
commandé un quintal d'Arbor ou un quintal de serveurs ?
Parce que dans ce cas là, ce n'était pas le réseau qui était en cause, 
la fonction est plus compliqué qu'un DNS.


Et pour un benchmark imposé, il n'y a pas de miracle, il est plus sage 
de prendre en compte la totalité de la zone couverte parce que sinon, 
vous pariez sur une fraction de cette zone, vous pouvez, mais vous 
_spéculerez_ comme à la bourse.


Êtes-vous prêt à parier que _jamais_, il n'existera jamais de virus 
multi-plateforme ultra-discret qui exploitera plusieurs zero-days 
simultanément ?


Moi, je ne parie pas, la catastrophe arrivera, basta, et je préfère être 
le petit cochon qui construit en brique sa maison.


Le cœur alimente toutes les cellules, il en oublie aucune, sinon c'est 
l’ischémie.


Le DNS est au cœur de l'Internet, appliquez le proverbe militaire, si 
vous ne copiez pas (la médecine) vous faites une connerie.


1 neurone (1 As) a en moyenne 10 000 cnx externe. Vous êtes loin du 
compte pour un service comme la racine ou le fr.



Ou est-ce que chacun fait ce qu'il veut de son coté ?


Bon résumé du fonctionnement de l'Internet. C'est pour cela qu'il
marche et résiste à tous les gens qui ont prétendu le planter.


En médecine, on n'échappe pas à la hiérarchie des structures, des 
organes, des membres avec en haut de la hiérarchie, le cerveau. Si vous 
refusez en tant que gestionnaire de DNS votre rôle d’organe vitale de 
l'Internet, et que vous faites ce que vous voulez, en dépit de ce qui 
se passe autour, vous nous exposez tous à de graves difficultés.


Vous devez comprendre que le jour où un de vos organes vitaux décidera 
de faire ce qu'il veut, ou ce qu'il peut mais aurait dû mieux faire, 
vous serez à l'article de la mort.


Je considère que quand on a des responsabilités à assumer, même des 
petites, on n'est pas libre de faire ce que l'on veut, même sur 
Internet. Il suffit de voir les irresponsables qui ont un simple Windows 
entre les mains. Et c'est d'autant plus irresponsable que la 
responsabilité est grande. Désolé, mais moi, je pense comme ça.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] 2012, fin du monde, Anonymous, racine du DNS et autres mots-clés

2012-02-23 Par sujet Stephane Le Men


On 02/20/2012 02:21 PM, Stephane Bortzmeyer wrote:


Plus sérieusement, .fr est conçu pour résister à des attaques dDoS
jusqu'à une _certaine_ taille (merci à Fernand R. pour la
précision). Cette résistance a été vérifiée aussi bien par les
organismes nationaux (ANSSI) que par des trucs internationaux (ICANN,
pour les candidatures de l'AFNIC à la gestion de TLD). Donc, ne me
croyez pas sur parole, interrogez les gens qui ont vérifié de
l'extérieur.


ce rapport là:

http://www.ssi.gouv.fr/IMG/pdf/2012-02-10_CP_Piranet12.pdf

savez-vous ce que j'en ai pensé quand je l'ai vu ?

Un baba-cool qui revient d'un séminaire Haré Krishna écrit la même chose 
à sa douce, il a appris plein de trucs. (*)


Et puis après je me suis dit humm, ce sont des militaires, des menteurs 
professionnels (à nous les civils), ressaisis toi, ils jouent comme à 
leurs habitudes, un coup de propagande.


Mais je doute quand même, tout simplement parce que si vis pacem para 
bellum c'est une de leurs raisons d'être, la dissuasion. Ils ont 
d'autres rôles, mais celui-ci est quand même important.


Mais est-ce que ce rapport dissuade un ennemi potentiel par un 
inventaire impressionnant ?


A mon avis, ce rapport ne dissuade personne, parce qu'il y manque le 
classique du défilé militaire démonstratif, l'inventaire de ce qui 
attend l'ennemi s'il bouge le petit doigt.


Alors s'il satisfait tout le monde, moi non, j'aurais bien aimé savoir 
ce qu'ils ont appris.


Quant aux Jupiter du code qui pondent des Stuxnet, ils se sentent 
pousser des ailes avec un rapport comme celui-ci.



Un des élements clés de cette conception est l'utilisation de serveurs
anycastés (presque tous les serveurs de .fr, désormais), sur une
centaine de sites en tout.


L'anycast, ce n'est pas le Saint Graal. D'une point de vue logique, 
quelle est la résultante d'une architecture anycast ?


Juste une agrégation de capacité réseau qui est distribuée sur un 
territoire.


Quand on constate cela, on comprend tout de suite que l'anycast ne 
change pas fondamentalement la situation par rapport à l'unicast, et que 
le Saint Graal n'est pas si saint que cela. Cela peut quand même le 
devenir, mais il y a des conditions ultra strictes à respecter, qui, 
lorsqu'on dessert la totalité de l'Internet, ne pourront pas ou très 
difficilement être réunies, à cause de son coût ou du fait que l'on vous 
ferme le cœur des opérateurs qui peuvent agréger un énorme trafic 
générateur.


Et je tiens à vous rappeler que vu de l’extérieur, l'anycast n'est 
visible _que_ sur le rtt: 5ms depuis Los Angeles et 5ms depuis Paris, 
c'est forcement une IP anycast. La physique interdit une telle 
performance en unicast.



J'attire votre attention sur les pages 9, 10 et 15 du dernier rapport
d'activités
http://www.afnic.fr/medias/documents/afnic-rapport-activite-2010.pdf.


Désolé, vos pages ne comblent pas ma faim.

Voilà une question simple:

Combien de giga/s au total sur toutes vos cellules anycast s'il vous 
plait ?


Une somme, ce n'est pas la mort à faire.
(mais cela peut être comme la mort de ne pas obéir au chef)



Il serait évidemment très imprudent de dire qu'on est
invulnérables. Disons simplement que le problème est connu et qu'on le
suit de près, de la conception des serveurs, jusqu'aux mesures
d'urgence (service d'astreinte, monitoring, etc). Nous maintenons une
veille active sur ces problèmes et testons régulièrement de nouveaux
joujous.


A l'armée, en médecine, en architecture (la vrai, les pont, immeubles) 
en économie ... dans une multitude de domaines la vulnérabilité se 
mesure, se quantifie. Alors, quelles sont, ou serait la ou les bonnes 
mesures de la vulnérabilité d'un réseaux (anycast ou pas ) ?


A l'armée, ils mesurent des épaisseurs de blindage, la mobilité de leurs 
armées etc etc .. en médecine, ce sont les tests biologiques anticorps, 
des épreuves d’effort sur un vélo etc etc .. en structure se sont les 
coefficients de marges prises sur les seuils de ruptures, la qualité des 
matériaux, et en réseaux, et particulièrement pour un réseaux anycast, 
qu'elle est cette mesure de vulnérabilité ?


Une mesure de vulnérabilité, au sens de mesure physique, cela devrez 
vous intéresser.


Quelle est cette métrique de vulnérabilité à l'Afnic ou à la racine ?

Parfois c'est compliqué, mais vous avez les maths qui peuvent venir à 
votre secours, souvenez-vous des complexes (a+ib) ou des matrices, les 
deux peuvent être utiles.




Est-ce que la volumétrie à ternir pour fr. est différente de la
racine selon vous ?


Les serveurs des TLD reçoivent souvent davantage de requêtes que la
racine puisque leur base est plus grosse (la racine est en entier dans
un cache une heure après son démarrage).


Veillez m'excusez pour mon orthographe lamentable, mais l'idée de ma 
question était de savoir si selon vous, le risque encouru par la racine 
ou le .fr ou n'importe quel autre TLD était plus petit ou plus grand. Un 
ordonnancement des risques, simplement.


En théorie, le niveau

[FRnOG] Re: [TECH] 2012, fin du monde, Anonymous, racine du DNS et autres mots-clés

2012-02-23 Par sujet Stephane Le Men


On 02/22/2012 12:25 PM, Stephane Bortzmeyer wrote:


On a un site anycast à Pékin, si c'était la question :-) Sérieusement,
BGP étant ce qu'il est, le site anycast n'a pas un contrôle complet de
qui il sert (le seul outil de sélection étant la politique de peering,
qui n'empêche pas un attaquant de nous envoyer des paquets).


http://tool.chinaz.com/Tracert

http://www.webkaka.com/Tracert.aspx

Voila vos IP

128.112.129.15
192.134.0.129
192.228.90.21
192.5.4.2
193.176.144.6
193.51.208.14
194.0.9.1
194.146.106.46

C'est laquelle qui marche en chine avec un rrt potable ?

j'en ai trouvé une mais depuis chez eux

http://www.ublink.org/tools/trace.php

mais ils sont à Taïwan.

Vous êtes bien sûr que les chinois ne se moquent pas de vous en natant 
du trafic externe à la Chine ?

Vous vous êtes promené en Chine pour vérifier votre conf ?
Je parie que non.

Si cela vous intéresse, j'ai peut être une connaissance pour vous qui 
y va souvent et qui pourrait vous aider. Et gratuit, j'en fais le pari.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] 2012, fin du monde, Anonymous, racine du DNS et autres mots-clés

2012-02-23 Par sujet Stephane Le Men


On 02/23/2012 05:58 PM, Benoit Peccatte wrote:


PS: les méthaphores c'est comme les mails frnog,
je ne les comprends pas toujours très bien et l'autre c'est une sorte de
droque.


Il faut bien regarder le dessin d'un ensemble de Mandelbrot pour saisir 
l'importance de la métaphore



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [TECH] 2012, fin du monde, Anonymous, racine du DNS et autres mots-clés

2012-02-23 Par sujet Stephane Le Men


On 02/23/2012 07:20 PM, Florian Lacommare wrote:


Si je pige bien tout, au final, rendre HS la racine ne serait pas
possible (à prendre avec des pincettes, rien n'est impossible) mais
on pourrait couper une partie des personnes d'Internet si certains
noeuds sont plus fragiles que d'autres en les faisant s'écrouler avec
du DDoS ?


Si la racine veut bien administrer un serveur chez toi et qui le lui 
autorise, pour toi, tu pourras dormir sur tes deux oreilles.
Si tes utilisateurs attaquent ton serveur, tu es chez toi, tu fais ta 
police.


Et sur l'Internet public, l'absence de l'OOB sur BGP, lorsque la cellule 
va tomber, le trafic de l'attaque va se ruer sur la cellule voisine pour 
l'aider à mourir plus vite. Quand celle qui a été sonnée se réveillera, 
elle va ré-attirer le trafic chez elle. Ce bagottement, va selon les 
version BGP perpétuer ou carrément dampenner le réseau, le retirer de 
la table de routage. Là, ce sera le black-hole pour cet région du réseau 
couverte par la cellule, pour un certain temps, et parfait pour 
l'attaque car tout le trafic ira un peu plus loin continuer son travail.


Alors la question est comment mesurer la fragilité ?
Comment font-ils ?
Le premier job du physicien, c'est la mesure, les unités.

Est-ce le nombre de sites qui mesure la fragilité ?
Pas vrai, il suffirait de mettre des modem 14k pour les liens de la 
racine et pas des gigas.


Montrez-tu dans une voiture dont tu ne connais pas la fragilité ou sa 
résistance ? Actuellement, on te dit elle est costaud mais sans plus, 
les chiffres données ne servent à rien pour se faire une idée de cette 
fragilité.



Et sinon, personne n'a penser a defoncer les fibres intercontinents
pour couper tout traffic. Bah quoi ?! Je parle en vécu, exemple : en
Afrique du Sud (mais d'autres pays) se sont vu coupé de l'Internet
pendant X temps (en 2010), créant ainsi des WAN déconnecté les uns
des autres (si on peut appeler ca comme ca).



Ce n'est pas grave, parce qu'on identifie toujours le coupable.

Pour identifier l'auteur d'un virus, c'est une autre affaire, et le but 
étant d'attaquer Anonymement x variable aléatoire sur l'ensemble des 
parties de la population, un état, un groupe d’individus, une personne.

N'est-ce pas la pire des situations que d’être attaqué par un invisible ?

Autre remarque, tous les reseaux des FAI sont anycast : 192.168.1.1 vous 
la connaissez cette IP. L'interface d'admin pour l’opérateur étant l'IP 
public. Il n'y a pas que Windows de dangereux, les IAD (les box), bien 
que se soit des Linux dans 99% des cas, ne sont pas l’abri d'un bug à 
découvrir et à exploiter, car très souvent ils sont figés en code et peu 
maintenu.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] 2012, fin du monde, Anonymous, racine du DNS et autres mots-clés

2012-02-20 Par sujet Stephane Le Men


On 02/17/2012 10:14 AM, Stephane Bortzmeyer wrote:

Vous le savez certainement, l'Internet s'arrête le 31 mars.

j'ai rassemblé ici quelques informations et une opinion :

http://seenthis.net/messages/57473


Dire que c'est difficile voir impossible, c'est faire la même erreur que 
ceux
isolent le réseau de tout autre réseau afin d'en assurer la sécurité 
réseau et
qui négligent les entrées/sorties des machines comme les clefs usb, 
lecteurs

cd etc  Stuxnet et pas que lui ont démontré le contraire.

Si un routeur possède 5 interfaces toutes à x mb/s, combien de paquets se
perdent si 4 interfaces concentrent à pleine charge sur la dernière ?

L'asymétrie maximale protocolaire du DNS, le rapport entre volumétrique
entre la plus grande réponse DNS obtenue par la plus petite requête DNS,
est-ce qu'on peut la constater sur l'architecture du réseau en terme de 
débit

des liens qui raccordent les serveurs DNS ?

Cela aura quelles conséquences si ce rapport est de 1 sur les 
infrastructures

de la racine ?
La signalisation BGP des borders de la racine a-t-elle été modifié pour 
devenir

out-of-band plutôt que in-band comme sur quasiment tous les routeurs du
monde. Est-ce que cela a de l’intérêt de faire de l'oob pour bgp dans le 
cas de

la racine ?
Avez-vous une idée de ce que devrait répondre un opérateur si un client lui
demande du BGP oob sur un exchange point ?

Connecter 10gb pour desservir 100 utilisateurs n'a pas du tout la même
conséquence que d'utiliser la même 10gb pour desservir 1 000 000
d'utilisateurs.

Est-ce que ces chiffres sont maitrisés lien par lien sur chaque cellule 
anycast ?
L'architectures du réseau qui dessert une cellule anycast est-elle 
régulièrement
mise à jour pour suivre l'évolution commerciale des opérateurs qui 
desservent

la racine ?

Quel débit doit encaisser une cellule anycast de la racine pour qu'un 
client
légitime de cette cellule ait 1 chance sur 2 de voir _toutes_ ses 
requêtes à sa

cellule racine échouer pendant _toute_ la durée du TTL ? 3 chances 4 ?
7 chances sur 8 ? 15 chances sur 16 ? ...

Honnêtement, j'ai cherché sans succès ces informations sur le net, et je ne
peux pas vous donner de réponses puisqu'elles nécessitent de connaitre 
cellule

par cellule, lien par lien des informations dont je ne dispose pas.

Donc, à mon avis, si on sait répondre à ces questions et majorer la 
dernière
question de proba sur la base de l'architecture de chaque cellule 
anycast, la
racine tiendra. Il faudra trouver la bon majorant, parce que si un 
client à 95%

de chance de voir ses requêtes échouer sur la durée du TTL, pour combien
de clients sera-t-elle vu encore up ?

Si on ne sait pas répondre, un Stuxnet like dirigé contre elle aura de 
très

grande de la mettra au tapis à l'expiration du TTL, tous simplement parce
que l'architecture des cellules aura bien peu de chance d'être correctement
dimensionné par hasard

Et ici, sur cette liste, à part un poignée de gens, aucun d'entre nous 
n'a à voir
avec la gestion de ce service. Je pense que je serais pas le seul à 
écouter de

potentielles réponses.

Et pour notre info, comment cela se passe-t-il pour .fr. ?
Est-ce que la volumétrie à ternir pour fr. est différente de la racine 
selon vous ?
Vous vous sentez plus fort ou bien moins que la racine au nic.fr et dans 
quel
rapport ? Est-ce que la racine assiste autant le .fr. que les opérateurs 
assistent

la racine ?

Donc, voilà , merci d'avance si vous répondez, vous pouvez prendre votre 
temps,
je suis désolé d'avoir trainé pour répondre à votre fin du monde, mais 
je n'ai pas

eu, et je n'ai toujours pas bcp de temps pour venir ici.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Re: La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA

2012-02-05 Par sujet Stephane Le Men


On 02/04/2012 06:38 PM, Stephane Bortzmeyer wrote:

Primo, je ne crois pas que le RIPE-NCC soit sous l'autorité du
FBI. C'est plutôt la Koninklijke Marechaussee qu'il faut craindre :-)


Bien oui justement, je ne pense pas que le RIPE-NCC, ni aucun autre RIR 
en fassent
plus qu'un registrar quand l'Inspecteur Harry débarquera dans ses locaux 
avec son 357.


C'est déjà le cas dans la réalité d'aujourd'hui, mais aujourd'hui 
l'inspecteur Harry est
encore contraint de faire le tour de tous les opérateurs un à un sous sa 
juridiction,

(ou son influence) pour obtenir la même chose.

RPKI simplifiera le travail en factorisant les sites à visiter vers 1 
seul ou quelques un.

L'équipe du FBI pourra être plus petite :)



Ensuite, que pensez-vous des approches citées dans mon article pour
diminuer le risque ? Si elles ne sont pas suffisantes, ou bien ont des
failles, il est temps de prévenir le RIPE-NCC avant que le déploiement
ne soit fini et figé.


Actuellement, l'Internet est un peu à l'image d'une carte politique du
Monde, une juxtaposition de politiques privées appliqués aux réseaux.

BGP-RPKI est un outil qui facilitera l'uniformité de ce patchwork de 
politiques

vers une seule.

Maintenant, les contraintes cryptographiques imposent, ou orientent vers 1
seul point d'autorité. Ce point là sera forcement sous 1 seule autorité 
politique

ou quelques une et elle(s) s'imposera/ont aux autres pouvoir politique.

Je trouve qu'on a déjà un soucis politique avec la structure en arbre du 
DNS,

pas besoin d'en ajouter un second avec BGP.
S'il existe une solution de crypto sans cette structure en arbre, elle 
serait mieux.


Quant à prévenir le RIPE-NCC que les arbres ont une faiblesse à la 
racine, je pense
qu'ils le savent déjà et que c'est clairement assumé. Le corolaire de 
prendre du
grade dans n'importe quelle activité c'est d'avoir des comptes à rendre 
sur son
activité. Le RIPE-NCC et les autres RIR sont volontaires pour ce job, je 
me vois mal

gâcher leurs ambitions.



Personnellement (mais je ne suis pas opérateur réseaux), la plus
raisonnable me semble être de ne jamais rejeter une annonce (même s'il
y a un ROA et qu'il est invalide) pour laquelle il n'existe pas de
route alternative. Cette solution empêche les attaques type Pakistan
Telecom (puisque le routeur verra l'annonce légitime de YouTube) mais
ne permet pas de se servir de la RPKI pour couper MegaUpload
(puisqu'il n'existe alors pas de route alternative)


Vous pourriez le faire si vous n'avez pas un Hortefeux ou un Guéant qui 
vous
empêcheront de le faire. En Chine, ils ont les deux au carré. Il ne 
faut pas oublier
que les opérateurs ont des contraintes de licences à respecter. C'est un 
efficace
moyen de pression, RIM et son Blackberry peut en parler dans le cas de 
l'Inde et

d'autres pays.

Et ce n'est pas dit qu'une annonce invalide parvienne à tout le monde.
Je suppose même qu'elle ne passera pas par défaut le premier opérateur qui
utilisera RPKI. Et transposé en DNSSEC, converser un record invalide, 
cela

a-t-il un sens ? Pas convaincu que ce soit une bonne idée.

Si j'ai bien compris, ces RFC apportent sécurité et substitue 
décentralisation
par centralisation. Quitte à être sûr de causer à la bonne personne, 
j'aurais préféré
passer à l'acte, vérifier que c'est bien vrai sur la base d'une crypto 
avec une
autorité _choisie_ dans une multitude d'autorités et pas une _imposé_ à 
la destination
finale, et récolter au passage quelques informations de performance, des 
fois que
ces informations de performance puissent intervenir dans le choix 
d'accepter ou

de rejeter une route.

Je regrette ce choix de centralisation face à la performance. Mais cela 
correspond

certainement à une demande qui est devenue pressante surtout depuis le
détournement de trafic par Pékin. Le routage est devenu stratégique et la
centralisation est un bon moyen d'en tenir la bride et d'intervenir 
rapidement

dans tout l'Internet.

Mon avis politique, parce que RPKI est une question politique, c'est de 
ne pas

remettre cet part de souveraineté à un autre pays. Et là, chaque AS dans le
monde cèdera une part à une entité qui pour l'immense majorité sera à
l’extérieur de son pays.

La crypto, c'est bien mais c'est une arme, et il faut éviter de se tirer 
une balle

dans le pied avec.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA

2012-02-05 Par sujet Stephane Le Men


On 02/04/2012 09:54 PM, Stephane Bortzmeyer wrote:


RIR). 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).


Est-ce que l'affaire MU a énervé suffisamment de monde pour qu'ils se 
concertent et

changent le contenue du root.cache de leur DNS ?

Ils ne sont pas fous aux FBI, ils attendront que tout le monde ait bien 
déployé, bien
testé bien validé, que ce soit rentré dans les mœurs du réseau pour 
intervenir.


Il nous manquait un habitus de révérence envers une autorité de routage, 
ben
voilà, RPKI est là. Y a plus qu'à commencer le conditionnent Pavlovien, 
vous verrez
ils sont aussi sympa qu'un bon toutou les propriétaires et les admins 
réseaux,

quand ils voient une nouvelle laisse, ils remuent la queue.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Re: La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA

2012-02-05 Par sujet Stephane Le Men


On 02/05/2012 11:46 AM, Stephane Bortzmeyer wrote:

La RPKI ne changerait pas grand'chose, de ce point de vue : « vous
bloquez l'accès à 194.71.107.0/24, par une null-route mise à la main,
ou par la RPKI, je m'en fous ». Et on doit obéir.


Les démocraties ont a appris à mettre des gants. Il est impératif que les
contraintes apparaissent comme des calamités naturelles.


Si j'ai bien compris, ces RFC apportent sécurité et substitue
décentralisation par centralisation.

Tout à fait faux. À moins que, comme les journalistes, vous confondiez
arborescent et centralisé. Mais, sur la liste Frnog, je ne pense pas
que quelqu'un puisse faire une erreur aussi énorme.


J'ai toujours cru que dans une recherche dans un arbre, la condition 
primordiale de

succès était de commencer par la racine. Topologiquement, commencer par la
racine est le point centrale du succès de la recherche. Un arbre est 
facilement

plongeable dans des cercles concentriques avec la racine au centre.

L’état major d'une armée ce n'est pas le point central de commandement 
de l'arbre

hiérarchique militaire ?



En résumé : chacun choisit à qui il fait confiance.


En Chine, je ne pense pas qu'il suffit de prendre le bon root.cache pour 
récupérer

un DNS propre, et cela à cause du routage.


Au travail. Après tout, la RPKI n'a pris que dix ans à être
développée. Il doit être possible de faire mieux. Je lirai
l'Internet-Draft avec intérêt.


Ce ne sera pas la première chose qui se passera contre ma (ou notre) 
volonté de
minoritaire. J'ai fini par m'habituer d'être dans les minoritaires. La 
hiérarchie est

plébiscité comme modèle d'organisation.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [TECH] La longue marche de la sécurité du routage Internet : une étape importante, RPKI+ROA

2012-02-05 Par sujet Stephane Le Men




Est-ce que l'affaire MU a énervé suffisamment de monde pour qu'ils
se concertent et changent le contenue du root.cache de leur DNS ?

Si quelqu'un l'a fait, ça prouve qu'il est totalement incompétent et
qu'il ne faut pas lui confier un serveur DNS. Les saisies de l'ICE ou
du FBI ont porté sur des noms sous .COM (et quelques autres comme
.TV). Changer la racine DNS (ce qu'indique le root.cache) n'aurait
donc rien changé, toutes les racines, même les plus bizarres, pointent
le .COM vers Verisign... Donc, techniquement, très mauvaise idée, on
comprend que personne ne l'ait fait.


Changer ce fichier et pointer vers une racine qui ne donne pas le .com à 
une entité

soumise aux US aurait fait comprendre au FBI que le root.cache c'est un
bulletin de vote et que tout d'un coup, le résultat des élections a 
changé.


Les gestionnaires de cette nouvelle racine comme ceux du nouveau .com 
peuvent
très bien répondre aux requêtes sur les domaines qui ne leur font pas 
confiance en
recopiant les données des originaux, et agir au final comme un proxy 
enrichi des

domaines rejetés.

Seulement la structure actuelle de la racine est appréciée pour ses 
qualités de
services rendus malgré ses défauts et donc conservée et respectée. Il y 
a aussi
le coût qui rentre en jeu dans inexistence de cette racine alternative, 
son financement.



Donc, mauvaise comparaison.


Sur le DNS, la méthode que je décris consiste à censurer un pouvoir en 
se mettant
au dessus de lui, avant lui. Elle ne sera plus possible avec le routage. 
C'est encore
plus low level que le DNS. On avait des barreaux de prison moyennement 
solides

avec le DNS, avec le routage ils vont prendre de la vigueur.


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

2012-02-04 Par sujet Stephane Le Men


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] Compte à rebours des 400 000

2012-01-13 Par sujet Stephane Le Men


On 01/13/2012 11:02 AM, Xavier Beaudouin wrote:


J'en vois pas mal qui s'amusent a annoncer des /23 ou /24 alors qu'ils ont un 
plus gros prefix alloué...

Perso ca me gonfle... :)



Quand on a grosse allocation et plein de lieux de présence, on peut préférer
que ce soit sur l'Internet que le trafic circule plutôt qu'au sein de 
son AS.

Simple question de coût, car les grosses allocations, ce n'est pas forcement
des opérateurs. Je dirais que même les opérateurs peuvent avoir cette 
politique
vis a vis de leur clients car souvent, ils ne sont pas capable de 
comprendre.


Pourquoi s'en priver quand le client est myope ou aveugle ?

Peut être que votre AS n'a pas ces caractéristiques géographiques, et c'est
ce qui vous conduit à penser cela.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] RE: IPv4 Exhaustion: RIPE NCC Update

2011-02-09 Par sujet Stephane Le Men


Il ne reste plus que les accès résidentiels, mais pour combien de temps?


C'est vendable un abo Internet grand public IPv6 only ?

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] RE: IPv4 Exhaustion: RIPE NCC Update

2011-02-09 Par sujet Stephane Le Men



Avec du NAT64, pourquoi ce ne serait pas vendable?



Aimablement, Mr G. m'a présenté la solution en privé.  Merci.

Mais je trouve la solution moche comme un pou, sans le DNS du FAI,
on ne sait pas où est la boite NAT64.
Quelqu'un pourrait expliquer pourquoi on n'a pas voulu que les ip du
block  :::ipv4 y aillent toutes seules comme des grandes ?
J'aurais preféré pouvoir me passer des services DNS du  FAI.

Je viens de regarder une conf de chez Free, NAT64 n'a pas l'air déployé.
Vous confirmez ou c'est moi qui suis manchot ? Si la réponse est non,
je trouve que dans les réseaux où NAT64 est absent, le mort ipv4 est
encore bien vivant.  Quel opérateur est ipv6 only ready ?

Et pour lien ipv6 only, je pensais surtout aux acariâtres qui voudraient
garder leurs anciennes applies ou machines v4 only.
Cela ne fera qu'un sorcier de plus à ajouter chez eux. 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] RE: IPv4 Exhaustion: RIPE NCC Update

2011-02-09 Par sujet Stephane Le Men


J'ai surement mal compris la demande originale, mais il était question
de savoir s'il était possible d'offrir un accès full IPv6 pour le grand
public.


C'était bien ma question


1. Tu veux faire communiquer un réseau de génération N+1 avec un
réseau de génération N, mais tu sera obligé d'avoir un traducteur
de ton proto de génération N+1 vers N (et vice-versa) au moins pour
les actifs n'implémentant pas (encore) la génération N+1.


J'aurais aimé me sentir supérieur en v6 qu'en v4, quand j'initie ou reçois 
une
cnx, et être superieur, c'est n'avoir strictement rien à faire sur le trafic 
v6 à

destination de l'Internet v4, si ce n'est raccourcir les ip. Et plus cette
passerelle sera loin de chez moi, mieux je me porterai, car c'est à cette
condition que le client standart comme l'opérateur abandonnera ses ipv4.


2. En se limitant aux aspects purement mathématiques de la chose,
(cf. théorie des ensembles), IPv6 a un espace largement surjectif
sur celui d'IPv4, donc tu auras besoin d'un chausse-pied
pour faire tenir quelques utilisateurs supplémentaires d'IPv6 dans IPv4.


Deuxieme déception, j'aurais aimé que le chausse pied soit le DNS, car
seul les noms sont communs aux 2 mondes. Mme Michu, client v6 only,
ne peut pas donner une ipv6 à Mr Michu, client v4, pour qu'il vienne
se connecter chez elle, mais elle peut lui donner un nom. Que le nom
soit vu depuis v4 sous differentes ipv4 (de passerelle ) peu importe
pourvu que le trafic arrive à destination.


Dans un process de migration IPv4 vers IPv6, le principe de NAT64+DNS64
permet donc de proposer un accès backward compatible à IPv4 sur un réseau
full IPv6


Pour un client v6 vers un service v4. Pas pour un client v4 vers le service 
d'un

client d'isp v6 only


(dernière étape avant l' extinction d'IPv4 si vous m'accordez
l'usage de ce terme).


C'est bien l'objectif que je trouve raté (à moins de n'avoir rien compris, 
mais
on va expliquer je pense), l'Internet v6 n'est pas un tueur de v4. Celui qui 
choisit
v6 only a plus de soucis a être joint que celui qui a une dual stack, qui a 
plus de
soucis que celui qui est v4 only. Je n'aime pas NAT64 car elle est client 
v6 centré,
et pas client/serveur v6 centré. Celui qui choisit v6 only, il est comme 
ensecté

dans v6 (*)

J'aurais aimé l'inverse, pour celui qui a v6 only, que ce soit le total 
confort pour lui,
en standart, il donne autant de noms differents à ses machines ipv6 à 
destination

des client v4 only, et ca se débrouille dans le réseau.

Tu n'aimes pas mes ipv6, voila leurs noms. Voila ce que je veux pouvoir 
dire
à mes copains v4 only. Sans cela, il ne va pas y avoir bcp de candidats à v6 
only.


Avec NAT64, il voit le v4, mais il est invisible depuis v4. Br

* Quand je parle de v6 avec des gens qui ne connaissent pas trop l'Internet,
ex Mme Michu, c'est ce qu'elle pense de moi. 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Quand on ne joue pas le jeu du réseau...

2011-01-17 Par sujet Stephane Le Men




Quelquesoit le domaine, le notre inclus, une révolution et
un changement des mentalités ne se fait pas en quelques jours.


Concernant l'Internet, la révolution a laissé quelques plaies encore
bien ouvertes.

http://www.orange.com/fr_FR/finance/financement/info-dette/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Stephane Le Men




Ce qui me gêne un peu plus c'est que c'est une des briques du grand
firewall Chinois/Iranien/Français (inutile de rayer la mention inutile : 
la Loi LOPSSI nous prépare des choses sympa dans ce domaine...).


Pas besoin d'aller si loin, tous votre trafic http sur mobile passe par un
Firewall http, mais il fire pas la police, juste la facture



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Stephane Le Men

Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et que 
peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, avec des 
nouveaux outils plus adaptés que ce qu'on a aujourd'hui.


http://en.wikipedia.org/wiki/Multilayer_switch

Et ça fait aussi avec des linux 



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] plan de reprise d'activité

2010-07-05 Par sujet Stephane Le Men


Le vendredi 02 juillet 2010 à 18:28 +0200, Frédéric Motte a écrit :


  C'est quand meme une solution qui est promis à un avenir.
  DNSSEC remettra les FAI Picsou dans le droit chemin. 
 Seulement si le DNSSEC est sur le poste client mais comme le disait 
 Stephane Bortzmeyer vendredi dernier dans sa conf, ca sera plutôt les 
 FAI qui implémenteront DNSSEC pour Mademoiselle Michue...


Mentir en DNS, et dire la verité en DNSSEC, ce n'est pas pour un FAI ,
introduire des donnés frauduleuses dans le système informatique de Melle
Michu en profitant d'un faille de la configuration de son PC , comme le
fait Billy le Kid lorsqu'il a trouvé une exploit sur un site warez ?

Si le FAI sait répondre juste en DNSSEC, pourquoi il répond faux en
DNS ?

Je me trompe peut etre, mais le déploiement de DNSSEC á l'interieur d'un
FAI devrait changer le status juridique de ses mensonges DNS, en France
tous du moins, car c'est faire preuve d'un certain manque de loyauté vis
á vis de ses clients que de maintenir une infra qui ment volontairement
cette fois ci. Volontairement, car je ne vois pas comment un DNS peut
répondre faux, si DNSSEC est présent sans avoir dispatché le trafic
entre mensonges et vérités, sans avoir écris du code pour cela, on
n'obtient pas le résultat normal. J'ai raté quelque chose ?

Et si cela passe comme une lettre á la poste, alors autant ne pas
s'arrêter en si bon chemin, autant faire des faux google, made by FAI,
présenter le dialymotion d il y a 15 jours, détourner l'ensemble du
trafic de banners vu par ses clients, l'imagination ne manque pas pour
augmenter le ROI. Et au  final, plus le client est analphabète, plus le
FAI a le droit de prendre contrôle de son PC pour maximiser ses
revenus ?

Si c'est communément admis, en France, tout est bien devenu possible.



 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] plan de reprise d'activi té

2010-07-02 Par sujet Stephane Le Men





Certains FAIs surtout, et donc potentiellement tous les clients derrière
leurs résolveurs...



C'est quand meme une solution qui est promis à un avenir.
DNSSEC remettra les FAI Picsou dans le droit chemin. 



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Pb OVH

2010-04-28 Par sujet Stephane Le Men


Le message d'Octave sur la mailing list ovh

http://pastebin.com/JkDPtzuf


Je ne comprend pas ce genre de stratégie, je veux bien être le
candide à qui on a besoin de faire un dessin pour comprendre

les packets qui sont filtrés, ils seront bien passés par une ligne avant
d'etre detruit par le routeur. Bon, il economise le reply, mais l'echo,
Octave le paye quand meme sur sa (?) ligne. Si OVH a au total 10G
de BP, et qu'il collecte 20G d'echo icmp qui bourre ses 10G, il
detruira tous les echo, mais au final, il n'améliorera rien du tous sur
ses lignes.

C'est plus vrai ce que je raconte ? Parce que cela l'a été quand
j'administrais, et je dirais meme plus (comme Dupond et Dupont)
c'est un sujet pour la neutralité et la coordination entre opérateurs.

CodeRed doit rappeller quelques souvenirs dans cette liste non ?
Un nouveau CodeRed, et tous le monde dort sur ses 2 oreilles
aujourd'hui ? Si oui, chapeau, c'est moi qui est obsolète, et je suis
curieux de savoir comment vous faites, parce que la méthode
d'Octave, elle ne marche pas, (de par mon experience)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Pb OVH

2010-04-28 Par sujet Stephane Le Men


les packets qui sont filtrés, ils seront bien passés par une ligne avant
d'etre detruit par le routeur.



Les packets passeront sur le lien entre le transitaire/peer et OVH -
mais ce que OVH protège c'est son backbone, il ne cherche pas a
réduire sa facture de transit mais a proteger ses liens internes


Pas de probleme, mais je ne suis pas sûr que le but cherché soit
atteint, le router et la ligne, c'est un ensemble, et regler le problème
seulement sur le router, ne le règle pas sur la ligne.


c'est un sujet pour la neutralité et la coordination entre opérateurs.



Non ce n'a rien a voir avec la neutralité - et je me répète chacun gère
son réseau (limite ICMP, etc.) comme il veut.


Moi je pense que si, parce que j'estime qu'un hebergement est en droit
de demander un filtrage en amont de ses peers, pour justement preserver
ses lignes. Le filtrage sur le router, c'est une thérapie homéopatique, cela
ne soulage que l'esprit. Libre aux herbegeurs de choisir le traitement 
qu'ils

veulent mais jusqu'à preuve du contraire, quand un router detruit 99% du
traffic entrant, la BP reelle est de 1% . À partir de ce constat, j'ai du 
mal

à croire que tous les investisssements que les hebergeurs peuvent faire
pour regler ce probleme leur restaureront leur BP nominale. Et c'est pour
cela que je trouve normal (mais quasi impossible à faire) de pouvoir
transmettre ses filtres à ses peers, pour faire remonter le filtrage le plus
loin possible.

Je crois que tout le monde a à y gagner, hebergeurs pour preserver
leur  visibilité, operateurs pour ne pas avoir à router du traffic qui sera
de toute façon detruit . AMHA, toutes actions entreprises au niveau de
l'hebergeur sans la participation de ses peers n'est que gesticulation.
On tente de remedier à un vrai probleme par une fausse solution.


Ce que je dirai par contre a' Octave, est : STP laisse passer
Fragmentation Needed (Type 3, Code 4)


Oui je suis aussi d'accord, mais là aussi chacun fait bien ce qu'il veut,
on est bien d'accord là dessus,


CodeRed doit rappeller quelques souvenirs dans cette liste non ?



Oui, je m'en souvient, j'avais deux machines infecte envoyant 2x100
Mb de traffic - pas drole de voir deux STM-1 saturer !!


Ben oui, je trouve que CodeRed avec d'autre comme SQLSlammer sont
des cas d'ecole, (et perso, sans critique vis à vis de qui que soit), qui
ne sont toujours pas compris.  Qu'OVH claque du blé inutilement, cela
fera plaisir à Cisco   Co, mais ce qu'il compte faire pour resoudre CE
probleme, désolé de vous le dire, c'est du placebo. Apres, chacun voit
midi à sa porte.

Un conseil, demandez un POC à vos fournisseurs et vous verrez bien.
(Signé: Saint Thomas)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Nouveau troll : qui doit payer ?

2010-03-23 Par sujet Stephane Le Men




Donc tu peux détecter les flux HTTPS P2P, et les brider si par exemple:

 - l'upload passe 2k, car des headers HTTP ne sont jamais aussi gros
 - la connection est ouverte depuis plus de 20 secondes

Les équipements DPI du commerce font ça aujourd'hui. Maintenant les règles 
réelle sont plus complique mais tu as l'idée.


Généralement, quand tu veux brider: tu priorise ce que tu peux analyser, 
si ce n'est pas analysable, c'est crypte et P2P et tu brides.
Pour cela NBAR de cisco ca suffit - je peux même poster une config si tu 
veux tester :p


montre nous comment tu fais cela pour du p2p dans un tunnel ssh  svp



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Nouveau troll : qui doit payer ?

2010-03-23 Par sujet Stephane Le Men


Le mardi 23 mars 2010 à 10:45 +, Thomas Mangin a écrit :
  Généralement, quand tu veux brider: tu priorise ce que tu peux analyser, 
  si ce n'est pas analysable, c'est crypte et P2P et tu brides.
  Pour cela NBAR de cisco ca suffit - je peux même poster une config si tu 
  veux tester :p
  
  montre nous comment tu fais cela pour du p2p dans un tunnel ssh  svp
 
 Ca donne quelque chose comme ca. Maintenant NBAR c'est vraiment la plus 
 simple des solutions DPI, les produit commerciaux spécialisé font beaucoup 
 mieux. Mais tu as l'idee.
 Sans match protocol ssh  le tunnel passe dans la classe default qui comme 
 tu peux le voir n'a pas grand chose (je suis dur ...:p)
 



Ta conf  DPI est static, et si je peux mettre en évidence un filtrage
sur un protocole particulier  par des tests de performance, je vais
direct  l'abandonner et en chercher un autre. En gros, la class-map ,
sans la connaître, peut être retrouver en testant proprement les perfs
du réseaux.

Dans ta conf Tu as mis ipsec/gre dans good-traffic, et là je n'ai même
pas besoin de récrire mon appli p2p, il me suffit de configurer la bonne
interface kivabien avec mes peers.

A ma connaissance (je veux bien qu'on apporte la preuve du contraire)
les protocoles de l'internet peuvent pratiquement tous supporter un
hidden channel. Il suffit d'avoir eu à faire face à des tunnels IP
dans icmp ou dans DNS pour comprendre ce que je veux dire. Il me semble
risqué de dire que la DPI les mettra tous en évidence.

Et vu à une echelle de temps de l'ordre de l'année, l'Internet  n'est
pas un systeme informatique, mais un système biologique . Si pour
l'instant la DPI fonctionne sur les applies existantes, elle devra
forcement s'adapter aux nouvelles applies que les programmeurs mettront
au point pour la combattre. Je pense que le cauchemar de la DPI sera
atteint quand le p2p reposera sur plusieurs protocoles standards, et non
1 seul comme ssh dans ma proposition.

En créant un canal caché réparti sur dnssec, http, https (on peut
allonger la liste comme on veux) et si l'encapsulation respecte les
propriétés statistiques des protocoles utilisés, je souhaite bonne
chance aux designers des boards et du soft pour rester dans les clous
des perfs demandées.


Chaque progrès de la DPI incitera les développeurs  à modifier les
protocoles traqués pour en augmenter la complexité. Pour l'instant la
DPI semble efficace à un coût raisonnable, mais pour combien de temps
encore ?

En gros mon avis sur la DPI est le meme avis que celui de la NSA sur
l'HADOPI version US, cela prendra plus de temps qu'avec l'HADOPI mais on
aboutira au même résultat. Dans l'imagerie militaire, on a affaire au
combat blindage contre canon et la puissance de la crypto/stegano
finira par pulvériser tous les blindages que la DPI proposera.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] l'ITU veut devenir RIR

2010-02-26 Par sujet Stephane Le Men


Le vendredi 26 février 2010 à 18:20 +0100, Raphaël Jacquot a écrit :
 http://www.ripe.net/news/2010-be-heard.html
 
 (et puis quoi encore ?)

 Détruire et effacer de nos mémoires e164.arpa.




---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Utilité des proxy http transparents en 2 010 pour un FAI

2010-02-25 Par sujet Stephane Le Men




Je ne viens ni me plaindre, ni troller, mais j'aimerai comprends
l'intérêt technique d'un tel système de nos jours, sous entendu que ce
n'est surement pas pour faire du cache.


Je n'ai plus ni abonnement 2g, ni 3g et donc je ne suis pas capable
de vérifier moi meme sur mon abonnement, mais normalement le gestionnaire
d'un reseau IP mobile veut pouvoir facturer à l'URL. En gros, l'acces à
http://monopérateur.fr   ne doit pas couter le meme prix à l'abonné que 
l'acces à

http://fandegrossecochonne.com.  Et cela, meme si le propriétaire du site
porno ne touche pas un centimes de l'argent fait lors de l'acces à son site.

Pour faire ça, le meilleur moyen c'est le proxy transparent. Tous le monde
doit passer le proxy, car c'est le choix de l'abonné de payer à l'url (ce 
n'est

pas dit comme ça dans les contrats mais signer un abonnement mobile 2g
ou 3g cela revient à ça), et les logs du proxy constitutes avec les logs
d'ouvertures sessions IP, de moches données brutes à transformer en belles
factures mensuels. C'est certainement de cette phase là que sont issus les
ratés de Orange dont un avec une facture à 150ke.

Et il existe encore une autre utilité à ce proxy. Normalement, on appelle 
plus

cela un proxy, mais vu de l'abonné il agit comme un proxy.  Le proxy ne fait
pas que  ecrire une url et une ip source dans un fichier de log, avant de
le faire, il va calculer une fonction de décision sur l'accord que 
l'opérateur

donne ou ne donne pas à l'abonné d'acceder à  telle URL. Dans un proxy
normal, cette fonction est figé au démarrage, là elle devient dynamique, 
elle

est  évaluée  à chaque URL démandée par chaque abonné. Il existe un
protocole pour faire cela, qui ne concerne pas seulement des URL http,
mais presque tout et n'importe quoi, SMS, MMS. appel voix, acces wifi
etc etc : Diameter RFC3588.  Mais dans les 3/4 du temps, ce n'est pas
diameter qui est déployé (peut etre maintenant ??)  mais une solution
propriétaire. L'interet d'un tel proxy c'est qu'il etends encore le champs
d'action de l'opérateur sur le traffic de ses abonnés :

(1)  possibilité d'offre pré-payé plutot que post-payé, cela etends le 
catalogue

de l'opérateur.
(2) - possibilité de filtrage genre hadopi
(3) - possibilité de filtrage à la tete du client, par exemple, j'ai des 
enfants,
je paye (cher) l'abo 3g à mes gosses, il est hors de question que je paye 
pour

que mes gosses aillent sur http://grossesalope.com. Monsieur l'opérateur
demerde toi pour que mes gosses n'aillent pas labas, sinon, je prends pas
l'abonnement pour eux. (c'est le genre de discours qui a un certain effet 
dans

quelques tetes de managers)
(4) possibilité d'interception légale, la police qui veut écouter untel, ce 
service
n'est qu'une version binaire de la version pré-payé: Plutot que de 
chercher un

credit dans une base, tu vas chercher un booléan écouté/pas écouté.

La liste des services que ces proxys connéctés en diameter peuvent offrir
à l'opérateur est quasi infinie et ne fait que de s'alonger de jour de en 
jour.


En fait, dans un reseau moderne, meme POST-payé, c'est normalement une
infra pré-payé qui est déployé car qui peut le plus, peut le moins. Et 
surtout,

il y a de nombreux nouveau acteurs qui s'agitent autour de ton abonnement
mobile, potentielement, tes parents, ton patron (qui payent  ton acces) , 
ton

gouvernement (qui te surbeille) ou un publicitaire qui adorait te vendre son
dernier produit.

Dans ton titre tu semblais considérer les proxys comme arrièrés, je pense 
plutot
que les opérateurs mobiles ne regardent pas l'Internet comme toi , et que tu 
n'es
pas prés de les voire diparaitre ! 



---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Quand free route les IP privées...

2009-10-23 Par sujet Stephane Le Men



ce message est à destination des admin de Free : vous routez certaines IP 
privées depuis les freebox.



$ tracepath 192.168.2.1
1:  Newton.local (192.168.107.107) 0.242ms pmtu 
1500

1:  192.168.107.254 (192.168.107.254)  1.873ms
1:  192.168.107.254 (192.168.107.254)  1.929ms
2:  88.164.197.254 (88.164.197.254)   51.582ms
3:  213.228.39.254 (213.228.39.254)   60.642ms
4:  albert-49m-1-v806.intf.routers.proxad.net (212.27.56.217)  51.620ms
5:  no reply
6:  no reply
etc.


Je pense que ce traceroute montre seulement que ces routeurs ont une 
default gateway configurée.


Cordialement.

Stéphane 



---
Liste de diffusion du FRnOG
http://www.frnog.org/

46 matches

Mail list logo