Announcement of Experiments
Hi NANOG, 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. 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: https://forms.gle/ZvZaodndPhCqMvR89 I remain at your disposal for any questions. Best regards, Alexandros [1] https://peering.ee.columbia.edu/
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. :) On Mon, May 2, 2022 at 10:02 AM Alexandros Milolidakis <amilolid@gmail.com> wrote:
Hi NANOG,
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.
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:
https://forms.gle/ZvZaodndPhCqMvR89
I remain at your disposal for any questions.
Best regards,
Alexandros
Hi!
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. :)
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.
On Mon, May 2, 2022 at 7:26 AM Raymond Dijkxhoorn via NANOG <nanog@nanog.org> wrote:
Hi!
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. :)
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 ?
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
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
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. Regards, Peter On Mon, May 2, 2022 at 2:10 PM Lars Prehn <lprehn@mpi-inf.mpg.de> 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
-- 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. Copyright © 2022 Accuris Technologies Ltd. All Rights Reserved. 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. Droit d'auteur © 2022 Accuris Technologies Ltd. Tous droits réservés.
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 <lprehn@mpi-inf.mpg.de> 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
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/avv... - 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
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/avv...
- 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
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? Regards Paschal Masha | Engineering Skype ID: paschal.masha ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Lars Prehn" <lprehn@mpi-inf.mpg.de> Cc: "nanog" <nanog@nanog.org> Sent: Monday, May 2, 2022 9:40:53 PM 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 < [ mailto:lprehn@mpi-inf.mpg.de | lprehn@mpi-inf.mpg.de ] > wrote: BQ_BEGIN 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 | 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
BQ_END
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. On Mon, May 2, 2022 at 10:30 AM Ca By <cb.list6@gmail.com> wrote:
On Mon, May 2, 2022 at 7:26 AM Raymond Dijkxhoorn via NANOG < nanog@nanog.org> wrote:
Hi!
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. :)
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 ?
On May 2, 2022, at 7:04 AM, Alexandros Milolidakis <amilolid@gmail.com> wrote:
Hi NANOG,
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.
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: https://forms.gle/ZvZaodndPhCqMvR89
I remain at your disposal for any questions.
Best regards, Alexandros
This is out of line. 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. 😀
On 5/1/22 23:59, Alexandros Milolidakis wrote:
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:
https://forms.gle/ZvZaodndPhCqMvR89 <https://forms.gle/ZvZaodndPhCqMvR89>
How do you intend to manage excluding tens-of-thousands of ASN's that do not want to be part of this experiment? Mark.
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. randy
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.
From my limited understanding of the experiment, I agree that opt-in would kind of defeat the purpose, but at the same time, the opt-out email bordered on insulting/careless: "hey, we're going to simulate a crime scene with your fingerprints unless you tell us not to within a week" wouldn't fly most places. If they had run their experiment without telling anyone, possibly 5 or 10 people/orgs worldwide would have noticed, assumed someone was doing something naughty (or incompetent), and gone on with their lives. But no notice would arguably have been even more wrong than the notice we did get here.
Is it possible to run such an experiment ethically without tainting the data in advance by announcing it? I don't know. Adam Thompson Consultant, Infrastructure Services MERLIN 100 - 135 Innovation Drive Winnipeg, MB R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) https://www.merlin.mb.ca Chat with me on Teams: athompson@merlin.mb.ca
-----Original Message----- From: NANOG <nanog-bounces+athompson=merlin.mb.ca@nanog.org> On Behalf Of Randy Bush Sent: Monday, May 2, 2022 3:50 PM To: Alexandros Milolidakis <amilolid@gmail.com> Cc: nanog@nanog.org Subject: Re: Announcement of Experiments
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.
randy
hi adam, 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. ran3970dy
Hi all, 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 . Best regards, Marco On Tue, 3 May 2022 at 00:22, Randy Bush <randy@psg.com> wrote:
hi adam,
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.
ran3970dy
participants (13)
-
Adam Thompson -
Alexandros Milolidakis -
Ca By -
Lars Prehn -
Marco Chiesa -
Mark Tinka -
nanog＠jima.us -
Norman Jester -
Paschal Masha -
Peter Potvin -
Randy Bush -
Raymond Dijkxhoorn -
Tom Beecher