*> Par ailleurs, je serais très très curieux de connaitre l'avis de l'ARCEP à ce sujet, c'est quand même un conflit qui entre dans les compétences de l'autorité. *
Pour répondre de manière factuelle : 1°) Sur la forme : - un tel sujet rentre a priori dans les compétences de l'ARCEP de règlement des différends relatifs à des questions d'interconnexion entre deux opérateurs (à supposer que les acteurs soient des opérateurs), ou entre un opérateur et un fournisseur de services en ligne (compétence plus récente, pour laquelle les premiers cas pourront être l'occasion de dégrossir son contour exact) ; - une des parties peut donc saisir l'Autorité, qui tranchera le différend "en équité", au terme d'une instruction contradictoire, sous un délai de quatre mois (ou de qques jours si il y a atteinte grave et immédiate et que des mesures conservatoires sont nécessaires, notamment pour "*assurer la continuité du fonctionnement des réseaux*", ce qui semble être un des sujets discutés ici) ; - un préalable à la saisine de l'ARCEP est cependant qu'il y ait eu négociation entre les deux parties et que celles-ci aient échoué, ce qui ne semble pas totalement clair ici ; - enfin, c'est bien aux acteurs de faire la démarche de saisir l'ARCEP s'ils estiment que la situation le nécessite (et non pas à l'ARCEP de s'autosaisir, dès lors que le sujet ne porte pas strictement sur le respect d'obligations légales ou réglementaires). 2°) Sur le fond : - l'ARCEP a pu indiquer dans des recommandations récentes que les pratiques de gestion du trafic devraient respecter 5 critères : pertinence (légitimité des motifs, ici la sécurité), efficacité, proportionnalité (qui semble être le cœur du débat ici), non discrimination et transparence ; - il s'agit d'une recommandation, non impérative, mais qui indique notamment quel serait a priori le raisonnement de l'Autorité si elle était amenée à devoir trancher un différend relatif à ces questions ; - de manière générale, l'Autorité n'a à ma connaissance jamais été destinataire de remontées significatives concernant des difficultés sur la mise en œuvre de mesures de protection des réseaux (type blocage de DDoS) ; - il ne saurait être question de se prononcer davantage sur le fond en l'absence d'éléments contradictoires, notamment en l'absence d'expression de l'opérateur mis en cause (qui s'est néanmoins exprimé depuis), et en l'absence de saisine. 3°) Une réaction à un élément vu plus loin dans la discussion : ANSSI ou ARCEP : c'est une bonne question ; il peut exister des procédures d'avis croisé entre autorités ; saisie d'un différend relatif à la proportionnalité de mesures anti DDoS, l'ARCEP pourrait utilement demander un avis de l'ANSSI dans la procédure ; je connais moins bien l'ANSSI mais je ne suis pas certain qu'elle ait la capacité d'arbitrer des litiges. A votre disposition pour toute discussion, Guillaume Mellier ARCEP 2012/2/13 Jérémy Martin <li...@freeheberg.com> > Bonjour, > > J'aurais un avis bien tranché sur la question mais je vais me modérer > grandement dans mes paroles car nous sommes sur un lieu public. > > Avant toute chose, je considère que dans les échanges entre opérateurs, il > doit y avoir du respect. On peut respecter OVH par rapport à ce qu'ils sont > devenu, on peut aussi respecter Gurvan pour ce qu'il construit petit à > petit. Malheureusement, le respect a disparu des échanges avec Octave > depuis bien longtemps, et c'est vraiment malheureux. > > Concernant le point de vue technique, nous sommes également victime des > problématiques d'attaques DOS UDP provenant du réseau d'OVH mais aussi > d'Online (je suis déjà venu pleurer ici pour cette raison d'ailleurs). > > Le fait est que dans notre monde de réseau giga, il est impératif de > placer des limites déontologique sur nos réseaux, et d'éviter les coupures > unilatérales qui bafoue la neutralité du net tel qu'on le voit dans le null > routage que fait Octave sur son réseau. Nous aussi nous avons notre réseau > et notre facturation qui explose à chaque fois. Et à chaque fois, le > service Abuse met 3 heures à bloquer le serveur en face. > > Par ailleurs, je serais très très curieux de connaitre l'avis de l'ARCEP à > ce sujet, c'est quand même un conflit qui entre dans les compétences de > l'autorité. > > Pour la suite, la seule solution que nous avons trouvé est de mettre en > place une community Blackhole avec nos transitaires, mais clairement, ce > n'est pas une solution parfaitement adapté. Un shapper en sortie du réseau > d'OVH ou d'Online pour bloquer les flux UDP au delà d'un certain nombre de > pk/s ou de mb/s serait tellement mieux. Mais les capacités en jeu sont > tellement élevé qu'OVH ou Online ne feront jamais les investissements pour > obtenir les équipements permettant de le faire. > > Comme d'habitude, le gros poissons nage tranquillement pendant que le > petit crève dans les sillons du premier... > > Cordialement, > Jérémy Martin > Directeur Technique FirstHeberg.com > > Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30) > Standard : 09 72 125 539 (tarif local) > Ligne directe : 03 66 72 03 42 > Mail : j.martin AT freeheberg.com > Web : http://www.firstheberg.com > > > > Le 12/02/2012 23:07, Gurvan Rottier-Ripoche a écrit : > >> Bonjour, >> >> >> Ceci n'est pas un mail pour venir pleurer/troller sur OVH mais plutôt pour >> prendre des conseils et chercher à comprendre. >> >> >> Notre réseau est régulièrement la cible d'attaques depuis des machines >> OVH. >> Indifféremment depuis des serveurs hackés participant dans des botnets que >> depuis des serveurs clients légitimes qui réalisent des attaques ciblés >> notamment via des offres low-cost "jetables". >> Je fais de nombreux report à leur service abuse qui intervient dans des >> délais raisonnables. >> >> La période des vacances a démarré et très souvent, c'est une >> grande effervescence de ce type d'attaques. >> Nous avons reçu plusieurs attaques ce Dimanche 12 Février 2012 allant >> jusqu'a 900Mbits depuis 9 serveurs OVH. (A relativiser avec notre 95 >> percentile de 100Mbits). >> J'ai twitté Octave pour lui faire part de mon mécontentement du fait du >> nombre important d'attaques en une journée. >> >> A chaque fois ses réponses sont virulentes (très proches de la >> diffamation) >> et fermés à la discussion : >> "C'est pas mon problème." >> "Tu as une activité de hackeur." >> "C'est à toi de gérer ton réseau." >> >> Alors que je suis la cible dans cette histoire et que je ne vois pas >> comment agir... >> De notre côté, nous appliquons des restrictions entrantes et sortantes >> mais >> ces nombreuses attaques ont des répercussions sur le coût du trafic >> entrant >> en amont de notre réseau. >> Notre fournisseur de transit nous fait payer malgré tout le coût de >> l'attaque et c'est logique. >> Ces attaques dépassent parfois de beaucoup (pratiquement x10) l'usage >> normal de notre bande passante. >> >> >> Ce que je ne comprend pas, c'est qu'OVH disposent bien de mécanismes de >> protections mais uniquement sur son trafic entrant. >> Par contre, ils n'appliquent pas les mêmes mécaniques en sens inverse pour >> éviter ou limiter les attaques sortantes de leur réseau. >> >> Comme seule solution, aujourd'hui suite à mes reports, Octave impose un >> blocage total entre nos deux réseaux. >> Cela gène nombre de mes clients qui ne peuvent plus opérer de redondance, >> simplement communiquer envers les deux réseaux (plus de DNS, SQL etc...) >> et >> moi-même qui ne peut plus du tout accéder aux services d'OVH que j'utilise >> également. (Ne serait-ce que le site OVH.COM...). >> J'imagine également que les clients ADSL d'OVH ne peuvent plus accéder à >> l'ensemble de mes services. >> >> Qu'en pensez-vous ? >> Un fournisseur d'accès a-t-il le droit de bloquer comme cela une partie du >> trafic internet, portant atteinte à la neutralité d'internet et aux >> recommandations de l'ARCEP sur la transparence et la non-discrimination >> des >> flux. >> Les mesures prises me semblent disproportionnées. >> Quelles sont les solutions que vous appliquez sur vos réseaux ? >> Avez-vous déjà eu ce type de problème ? >> >> Cordialement, Gurvan. >> >> --------------------------- >> 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/
