<div dir="ltr">In my honest opinion, it's the fact that they're going to be using random AS's without prior consent from those that hold said AS's, and only giving operators a week to opt-out of something that they never opted into in the first place.<br><div><br></div><div>Regards,</div><div>Peter<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 2, 2022 at 2:10 PM Lars Prehn <<a href="mailto:lprehn@mpi-inf.mpg.de">lprehn@mpi-inf.mpg.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Short Disclaimer: I frequently use the PEERING testbed myself, so I'm <br>
genuinely interested in where and why people draw the boundary of what's <br>
fine and what's not.<br>
<br>
Iirc., the route collectors see a (drastically varying) number of <br>
poisoned routes (assuming everything within a loop is poisoning) in the <br>
DFZ at any point in time, affecting a (drastically varying) number of <br>
ASNs, prefixes, and paths. So why would you expect this experiment to be <br>
noticeable at all---I mean, compared to the day-to-day, "1% of the <br>
Internet is beyond broken and does Yolo things" noise? Very similar <br>
experiments have run in the past (e.g., [1] in 2018); did you notice them?<br>
<br>
Would poisoning be tolerated if the PEERING testbed would be, e.g., some <br>
security-obsessed org that wants to avoid that your infrastructure <br>
touches any of its precious packets during the forwarding process? I <br>
guess what I want to figure out is: Is it the intention behind the <br>
poisoning experiments that bothers people or is the act of poisoning <br>
itself?<br>
<br>
Kind regards,<br>
Lars<br>
<br>
[1] <a href="https://arxiv.org/pdf/1811.03716.pdf" rel="noreferrer" target="_blank">https://arxiv.org/pdf/1811.03716.pdf</a><br>
<br>
On 02.05.22 16:33, Raymond Dijkxhoorn via NANOG wrote:<br>
> Hi!<br>
><br>
>> > If I am interpreting this correctly that you are just going to yolo a<br>
>> > bunch of random ASNs to poison paths with, perhaps you should consider<br>
>> > getting explicit permission for the ASNs you want to use instead.<br>
>> ><br>
>> > A lot of operators monitor the DFZ for prefixes with their ASN in the<br>
>> > path, and wouldn't appreciate random support tickets because their NOC<br>
>> > got some alert. :)<br>
><br>
>> Exatly that. How about you ask people to OPT-IN instead of you wanting<br>
>> people to OPT-OUT of whatever experiment you feel you need to do with<br>
>> other people's resources.<br>
><br>
>> When you the last time you asked the entire internet?s  permission to <br>
>> announce routes ?<br>
><br>
> I dont exactly understand what you try to say its not about the route <br>
> its about the path.<br>
><br>
> If the insert 'my ASN' i certainly will complain wherever i can and no <br>
> i will not opt out from that. I will assume they just do use my ASN. <br>
> Weird thought?<br>
><br>
> Bye, Raymond<br>
</blockquote></div>

<br>
<div><font color="#000000">The information contained in this message may be privileged, confidential and protected from disclosure. This message is intended only for the designated recipient(s). It is subject to access, review and disclosure by the sender's Email System Administrator. If you have received this message in error, please advise by return e-mail so that our address records can be corrected and please delete immediately without reading, copying or forwarding to others. Any unauthorized review, use, disclosure or distribution is prohibited.</font></div><div><font color="#000000">Copyright © 2022 Accuris Technologies Ltd. All Rights Reserved.</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">L'information contenue dans ce message pourrait être de nature privilégiée, confidentielle et protégée contre toute divulgation. Ce message est destiné à l'usage exclusif du(des) destinataire(s) visé(s). Le gestionnaire de système du courrier électronique de l'expéditeur pourrait avoir accès à ce message, l'examiner et le divulguer. Si ce message vous est transmis par erreur, veuillez nous en aviser par courrier électronique à notre adresse, afin que l'on puisse corriger nos registres, puis veuillez le supprimer immédiatement, sans le lire, le copier ou le transmettre à des tiers. Tout examen, toute utilisation, divulgation ou distribution non autorisé de cette information est interdit.</font></div><div><font color="#000000">Droit d'auteur © 

2022 
<span><span><span><span>Accuris Technologies Ltd</span></span></span></span>. Tous droits réservés.</font></div>