nanog mailing list archives

Re: Announcement of Experiments


From: Lars Prehn <lprehn () mpi-inf mpg de>
Date: Mon, 2 May 2022 21:45:07 +0200

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 () 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 () nanog org> On Behalf Of Tom Beecher
Sent: Monday, May 2, 2022 13:41
To: Lars Prehn <[redacted]>
Cc: NANOG <nanog () 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


Current thread: