Mailing List Archive

>
> 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
>

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
>
> [1] https://peering.ee.columbia.edu/
>

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:
>
> https://forms.gle/ZvZaodndPhCqMvR89

> 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:
> >
> > https://forms.gle/ZvZaodndPhCqMvR89
>
> > 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

>
> 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:
>> >
>> > https://forms.gle/ZvZaodndPhCqMvR89
>>
>> > 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
>
> [1] https://peering.ee.columbia.edu/

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.

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/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

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

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

> 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
>