We are a group of researchers from the KTH Royal Institute of Technology (Sweden).
Starting from May 9 until May 31, we plan to conduct a research study involving AS-PATH poisoning to measure how reliable route collectors are to report BGP poisoned routes.
We will use the PEERING Testbed [1] to announce the following two prefixes:
The above experimental prefixes do not host any production services, hence user traffic will not be affected.
Furthermore, we will always start the AS-PATH with the correct ASN as the origin.
Lastly, to keep the AS-PATH short, we will announce no more than four Poisoned ASNs per announcement. The frequency of the announcements will not exceed four per hour.
If, for any reason, you want to opt out from us using your ASN for our experiments, you can do so in the following form before May 9:
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.
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.
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.
Bye, Raymond.
When you the last time you asked the entire internet’s permission to announce routes ?
> 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?
When you the last time you asked the entire internet’s permission to announce routes ?
I am not suggesting that anyone ask for permission to announce routes.
I am suggesting they ask for permission to use ASNs that are not theirs in the experiment, instead of forgiveness later for any operational disruption that it would cause.
Do you really believe that it is fashionable to come here and post this short notice “you must opt-out” notice that you are going to use our resources?
I feel that as innocuous as your tests may be, you must work in reverse of how you are doing this now. Furthermore we do not have to opt-out, and tell you our ASN etc. Shall we will bill your for our valuable time? Does your experiment have a budget for that? We’re all very busy here and don’t need to do your work for you.
The number of assigned ASNs exceeds 100k, so let’s just assume your experiment causes each network operator an hour labor to notify its staff, examine the details of your experiment and fill our your opt-out form, I would expect about $7,500,000 in fees. (Based upon a small 75.00 hour fee.)
It’s unjust that you burden the world with work you should be doing.
Don’t get me wrong. I’m in support of experiments that can advance our world but they have to be done correctly. Should your experiment have unforeseen outcomes and cause major disruptions, the liability is unmeasurable.
I can however thank you for posting this here so we have a chance to rebut it.
Please read my words in a happy voice so it doesn’t come off too edgy.
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?
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.
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.
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?
I really don't see any harm with this experiment especially considering that the first AS Number on the AS_PATH will be the correct AS-PATH from which the two prefixes should be originated from. Clear whatever ASN that follows after that wouldn't matter as the internet will always forward traffic for those prefixes to the correct ASN, perhaps the question to the research team is how will the routers that within your ASN be configured to route those two ASN once traffic comes back to you?
We are a group of researchers from the KTH Royal Institute of Technology
(Sweden).
Starting from May 9 until May 31, we plan to conduct a research study
involving AS-PATH poisoning to measure how reliable route collectors
are to report BGP poisoned routes.
We will use the PEERING Testbed [1] to announce the following two
prefixes:
- 184.164.236.0/24
- 184.164.237.0/24
for our AS-path poisoning experiments.
The above experimental prefixes do not host any production services,
hence user traffic will *not* be affected.
Furthermore, we will always start the AS-PATH with the correct ASN as the
origin.
Lastly, to keep the AS-PATH short, we will announce no more than four
Poisoned ASNs per announcement. The frequency of the announcements
will not exceed four per hour.
seems quite harmless. though i am sure folk who do not really
understand AS_PATH will get their nickers in a twist.
I am not claiming any of this is official MERLIN position on the matter, these are merely my thoughts so far based on the incomplete knowledge & data I have:
IMHO, it's somewhat the same as if I made public statements that started with "Well, I talked to Randy Bush and he said XXXX". I'm clearly the one articulating that sentence, but I'm nonetheless attributing to you something that is (presumably) false.
This will, I think, taint historical time-series data (e.g. RIPEStat) for any ASNs the experimenters use, and I could easily see in my organization being called upon to ask "Why were we transiting x.x.x.x/y in May 2022?" and not having any answer.
The operational impact will probably be somewhere between zero and negligible, assuming the experiment is run correctly, but operational impacts aren't the only impacts: reputational risks are very important to some organizations.
In addition to people not fully understanding AS_PATH, which even here will be a non-zero number, there will also be a number of people (myself included in this number) who have no idea what the PEERING testbed is, nor how it works, nor the effects it can produce. I'm in alignment with several other commenters in that I should not have to go spend time to learn about Yet Another Piece of Technology just to assess the risks, operational and reputational, I now face.
Is it possible to run such an experiment ethically without tainting the data in advance by announcing it? I don't know.
you are correct, it will affect research based on as_path data from the
ris/rv collectors etc. which is why i think these researchers were kind
to warn us so we can remove data for those prefixes from in any
measurements betting on as_path which might be so sensitive so as to be
effected.
but then, removing PEERING testbed prefix data (which these are) from
your experiments is probably wise in general. you would be measuring
other researchers, not the 'normal' (whatever the heck that is:)
internet.
as a point of amusement, for a month or so in 2008 3130 had an
out-degree of approximately the entire as set. and no packets were
harmed.
[ credit where due department: as we said in the 2009 paper, i think it
was lorenzo who first used as_path poisoning in a measurement study. ]
alongside ris and/or rv, we night have a registry of both accidental and
intentional known anomalies.
We would like to thank the community for sharing both their concerns and support.
We have decided that we will NOT run the experiment for now.
We would like to clarify some of the existing concerns.
Concern #1: Risks about operational disruption.
We would have only announced an IP prefix that we control and for which the only data traffic will be the one that we generate during the experiment.
Concern #2: Reputation damage.
We did not think about this point. When talking with our testbed’s contact points, they suggested surrounding each poisoned AS with two occurrences of the testbed ASN in the AS path. As an example, when poisoning ASN_1 and ASN_2, our AS path would have looked like <ORIGIN_ASN — ASN_1 — ORIGIN_ASN — ASN_2 — ORIGIN_ASN>. In this way, any peering inference systems would only infer one relationship with ORIGIN_ASN, which can easily be filtered.
Concern #3: Poisoning usage.
As it was mentioned in a previous email, AS path poisoning can be used for steering inbound traffic away from some networks. In our experiment, this would have meant that our generated traffic would have not traversed the poisoned AS networks. There was a recent in-depth study on the level of effectiveness of poisoning for inbound traffic steering: https://www.ndss-symposium.org/wp-content/uploads/2020/02/24240-paper.pdf .
