Announcement of Experiments

Mon May 2 19:45:07 UTC 2022

I think I get why you'd always like to opt-in rather than opt-out after 
short notice. Yet for this particular line of research, having operators 
explicitly opt-in sort of defeats the entire purpose of poisoning their 
ASN. Say you'd manipulate/eavesdrop/whatever my traffic and I 
consequently would like to poison you, then you'd surely not provide me 
with the permissions to use your ASN after I nicely asked you.

If the problem is not poisoning itself, I guess the "we just test a 
bunch of random ASNs" is the problem. Yet, figuring out how many/which 
ASNs adhere to and/or ignore poisoning is valuable for traffic 
engineering, censorship evasion, etc.

Out of curiosity: If not poisoning the path, how would you avoid that 
your traffic passes a certain ASN, especially in the reverse direction? 
To make BGP Communities a viable option, I guess there are not enough 
ASNs providing community encodings to control route redistribution 
fine-grained enough.

@Tom: I don't get the point about "announcing address space that's not 
ours." Do you mean "originating" address space or "redistributing" it? 
If the former, I think the experiment makes anouncements with paths of 
the form "47065 A B C D 47065"---the left-most is needed for peer 
checks, the right-most to pass ROV and/or IRR route-origin 
checks---i.e., your ASN would never be the origin. If the latter, I'd 
guess you'd also redistribute routes from your providers/peers (i.e., 
address space that's not yours) to your customers and vice-versa. I 
guess one could argue that you don't want to be seen next to certain 
ASNs in the path due to business relationships/politics (?) but beyond 
that, why are these things problematic?

Kind regards,

Lars

On 02.05.22 20:50, nanog at jima.us wrote:
> The real question is, does this follow "good research practice?" The responses on this list would suggest "no."
>
> FWIW: https://intra.kth.se/en/forskning/overgripande-stod/etik-och-god-forskni/avvikelse-fran-god-forskningssed-1.1112846
>
> - Jima
>
> From: NANOG <nanog-bounces at nanog.org> On Behalf Of Tom Beecher
> Sent: Monday, May 2, 2022 13:41
> To: Lars Prehn <[redacted]>
> Cc: NANOG <nanog at nanog.org>
> Subject: Re: Announcement of Experiments
>
> Short Disclaimer: I frequently use the PEERING testbed myself, so I'm
> genuinely interested in where and why people draw the boundary of what's
> fine and what's not.
>
> Fine : Experimentation.
>
> Not fine : Experimentation with number or ASN resources that are not yours without prior permission.
>
> The operations and engineering staff at my company should not have to trace down why one of our ASNs is suddenly announcing space that is not ours , and that is coming from a network that isn't under our control.
>
>
> On Mon, May 2, 2022 at 2:07 PM Lars Prehn <[redacted]> wrote:
> Short Disclaimer: I frequently use the PEERING testbed myself, so I'm
> genuinely interested in where and why people draw the boundary of what's
> fine and what's not.
>
> Iirc., the route collectors see a (drastically varying) number of
> poisoned routes (assuming everything within a loop is poisoning) in the
> DFZ at any point in time, affecting a (drastically varying) number of
> ASNs, prefixes, and paths. So why would you expect this experiment to be
> noticeable at all---I mean, compared to the day-to-day, "1% of the
> Internet is beyond broken and does Yolo things" noise? Very similar
> experiments have run in the past (e.g., [1] in 2018); did you notice them?
>
> Would poisoning be tolerated if the PEERING testbed would be, e.g., some
> security-obsessed org that wants to avoid that your infrastructure
> touches any of its precious packets during the forwarding process? I
> guess what I want to figure out is: Is it the intention behind the
> poisoning experiments that bothers people or is the act of poisoning
> itself?
>
> Kind regards,
> Lars
>
> [1] https://arxiv.org/pdf/1811.03716.pdf
>
> On 02.05.22 16:33, Raymond Dijkxhoorn via NANOG wrote:
>> Hi!
>>
>>>> If I am interpreting this correctly that you are just going to yolo a
>>>> bunch of random ASNs to poison paths with, perhaps you should consider
>>>> getting explicit permission for the ASNs you want to use instead.
>>>>
>>>> A lot of operators monitor the DFZ for prefixes with their ASN in the
>>>> path, and wouldn't appreciate random support tickets because their NOC
>>>> got some alert. :)
>>> Exatly that. How about you ask people to OPT-IN instead of you wanting
>>> people to OPT-OUT of whatever experiment you feel you need to do with
>>> other people's resources.
>>> When you the last time you asked the entire internet?s  permission to
>>> announce routes ?
>> I dont exactly understand what you try to say its not about the route
>> its about the path.
>>
>> If the insert 'my ASN' i certainly will complain wherever i can and no
>> i will not opt out from that. I will assume they just do use my ASN.
>> Weird thought?
>>
>> Bye, Raymond