This was a test using unassigned IP block, unless I'm reading it wrong. If a noc alerted on this it should have still be a low priority issue. I don't see any issues with the way this was carried out at all.
-jim
The alerts we got were because our AS number was showing up somewhere
else in the world. Whether it's "legit" IP space or not - it still
warrants investigation on a high priority from my perspective.
I have nothing against Randy or anyone else involved with this project
.. to be quite honest I'd be interesting in seeing/hearing the results
... but I believe a more careful approach is in order with consideration
for the folks effected.
Paul
Paul Stewart wrote:
The alerts we got were because our AS number was showing up somewhere
else in the world. Whether it's "legit" IP space or not - it still
warrants investigation on a high priority from my perspective.
Given the use of the ASN, I'm surprised that you place high priority of it showing up in other AS Paths. Of course, I can understand the issue of it indicates that a network has definitely isolated itself on purpose from your network (if your network runs without a default).
I suspect part of this test is to determine if there are enough defaults to allow traffic through even though the route isn't being processed by certain networks (ie, it does not good to poison AS_PATH if defaults in general will allow DOS traffic to continue).
Path poisoning has been around awhile and is even taught in classes of some router vendors as a way to alter traffic patterns. Of course, your AS may never have come up in such a situation. What Randy is doing, I suspect, is seeing if it does have any applicable uses, or if their assumptions are wrong.
I have nothing against Randy or anyone else involved with this project
.. to be quite honest I'd be interesting in seeing/hearing the results
... but I believe a more careful approach is in order with consideration
for the folks effected.
What you request would probably cost more money and time than the project can afford. Not saying that such time and money shouldn't be spent, but it is what it is. For you, an email to nanog might suffice, but I doubt that every ASN which is being path poisoned is going to have representatives on nanog, or even reading mail at their whois contacts.
Jack
A suggestion I made to Randy at APRICOT in early 2007 when he was presenting his BGP beacon bogon filter detection stuff[1] was that he could use AS_PATH poisoning to detect broken filters and topology between two ASes, not just the best route back to him from each AS.
I think he thought it was a silly idea at the time, probably because of the massive amount of BGP updates that it would need. Maybe he changed his mind?
But yes, your suggestion seems reasonable as well - detect the existence of access lists, as opposed to prefix lists. The announcement is required to all the intermediary ASNs because of uRPF.
Nathan Ward wrote:
A suggestion I made to Randy at APRICOT in early 2007 when he was presenting his BGP beacon bogon filter detection stuff[1] was that he could use AS_PATH poisoning to detect broken filters and topology between two ASes, not just the best route back to him from each AS.
I think a lot of the work done actually provided good results. AS_PATH poisoning might have provided a few more clues on the return path.
One thing I didn't see in the interpretation was that while some AS's were inconsistent with outbound probes, this leads one to believe that the IPs selected for the probes were most likely firewalls providing bogon filtering, and not bogon-filtering at an AS level.
Having dealt with quite a few reachability issues in 69/8, I got to talk to some really redneck organizations that barely knew a thing about their firewall.
This promises to be a much more interesting study, though I suspect it's heavily scoped due to the time it takes to run tests without being dampened. I presume there's at least one route acting as an anchor to detect dampening. If not, we can send Randy off to do it again. 
Jack
I completely agree with Jim: I have no idea why alert thresholds are set to a level of sensitivity which would cause this to become a "must be dealt with this minute" sort of issue. What exactly is the threat potential of someone else's IP space being announced with your ASN prepended?
If the concern was a Pilosov/Kapela style hijack, wouldn't the first thing you'd check be what the address range was? That would lead you straight to Randy, and that should have cleared up the matter straightaway. Remember: the owner of the IP space is the victim, not the ASN which gets prepended into the path...
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
No, they are both victims. If I inject a path that purports
there is an edge between two networks which are engaged in a bitter
dispute, (i'll use cogent & sprint as an example) - _1239_174_ that may
create a situation where someone asserts that their routes are
being filtered when infact no connectivity exists.
Does that mean that I hijacked their identiy and forged it? What
level of trust do you place in the AS_PATH for your routing, debugging and
decision making process?
Personally, I would be upset if someone injected a route with my
ASN in the AS_PATH without my permission.
- Jared
Once upon a time, David Barak <thegameiam@yahoo.com> said:
I completely agree with Jim: I have no idea why alert thresholds are
set to a level of sensitivity which would cause this to become a "must
be dealt with this minute" sort of issue. What exactly is the threat
potential of someone else's IP space being announced with your ASN
prepended?
The threat that it is the first prefix like that and maybe not the last.
It could be an accidental (or intentional) mistake, and should be
tracked down ASAP to make sure that is the only such prefix.
Jared,
Fine which makes it an interesting data point and something to look
at after lunch when I'm not doing something else kinda issue. Not
something I'm going to treat as a P1 and drop everything work or real
life related for. I'm not say it shouldn't be looked it, just that in
the grand scheme of the thing its not a huge issue. Kinda like when
people feel the need to tune IGP time sub second convergence but do
impactful maint on routers or circuits 3-4 times a yr. If you lock
the doggie door but leave the front door open the bad guys can walk
right in. 
-jim
Hi Jim...
We treated it with P1 until we realized it was a total waste of our
time. It was the point of it too...
About 6 months ago we had a similar alarm (on the surface) where someone
in Europe was advertising our AS number. After some careful checking it
seemed to be simply a typo error but after about 20 minutes of it
showing up in a path it disappeared and they started actually
advertising one of our IP blocks and were able to do so due to lack of
proper filtering on their upstream. If we had not been paying attention
to this "little detail" it would have taken us more time to react and
trace down what we going on - by paying attention we had several details
already accounted for. The whole issue lasted about 30 minutes at which
point their upstream provider had been notified and cut off their
customer until proper filtering was put back into place.
I'll admit that was the only time we've ever had an issue or until this
new incident an alarm condition. So, now for "academic purposes" we see
another alarm and fear the worst.
Yes, treating it as a P1 makes sense for us so far - we're batting 50/50
for legit problems with this stuff.
Paul
No, they are both victims. If I inject a path that
purports
there is an edge between two networks which are engaged in
a bitter
dispute, (i'll use cogent & sprint as an example) -
_1239_174_ that may
create a situation where someone asserts that their routes
are
being filtered when infact no connectivity exists.
That's a theoretical possibility, but who would be the one doing the asserting? I would argue that it would either be the owner of the announced space or someone trying to reach it. In this case, nobody was trying to reach the /24 in question, and the owner was the one doing the experiment. Victimless crime, at most.
Does that mean that I hijacked their identiy and forged
it? What level of trust do you place in the AS_PATH for your
routing, debugging and
decision making process?
AS_PATH != identity, and I would not recommend loading the latter onto the former.
Personally, I would be upset if someone injected a route
with my ASN in the AS_PATH without my permission.
Why? Is this a theoretical "because it's ugly" complaint, or is there a reason why manipulating this particular BGP attribute in this particular way is so bad? Organizations do filtering and routing manipulation all over the place. Is there something worse about doing it this way than others?
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
No, they are both victims. If I inject a path that
purports
there is an edge between two networks which are engaged in
a bitter
dispute, (i'll use cogent & sprint as an example) -
_1239_174_ that may
create a situation where someone asserts that their routes
are
being filtered when infact no connectivity exists.That's a theoretical possibility, but who would be the one doing the asserting? I would argue that it would either be the owner of the announced space or someone trying to reach it. In this case, nobody was trying to reach the /24 in question, and the owner was the one doing the experiment. Victimless crime, at most.
Interesting. You think it is OK to use my my ASN for things as long as no one is trying to do those things?
Does that mean that I hijacked their identiy and forged
it? What level of trust do you place in the AS_PATH for your
routing, debugging and
decision making process?AS_PATH != identity, and I would not recommend loading the latter onto the former.
We disagree. When I am researching something, I frequently look at ASNs in the path to figure out not just where but who controls the path.
Personally, I would be upset if someone injected a route
with my ASN in the AS_PATH without my permission.Why? Is this a theoretical "because it's ugly" complaint, or is there a reason why manipulating this particular BGP attribute in this particular way is so bad? Organizations do filtering and routing manipulation all over the place. Is there something worse about doing it this way than others?
Filtering and other manipulation happened on your router, prepending my ASN is putting that information into every router. That seems to be a serious qualitative difference to me. Do you disagree?
This thread has been interesting & educational. So many people seem to be happy to explain why they should be allowed to use globally unique identifiers they do not own in ways which were not intended, then explain to the people who do own those identifiers how they should react, which alarms should go off, and even which priority the alarms should have.
As I have repeated probably hundreds of times: Your network, your decision. I have yet to hear a credible argument against that stance. What you do _inside_ your network is _your_ decision. When it leaves your network, however, things change.
Announcing an ASN which is not yours to eBGP peers means it is leaving your network, which means it is not just your business. Doing so and then telling the ASN owner that they should not worry about it afterwards - and in fact arguing when the owner repeatedly tells you this caused them problems - does not seem to be the proper course of action.
I mentioned earlier in the thread if Cogent prepending Sprint's ASN to Verio, people would react differently. Randy said tools can be used for good or bad, obviously implying he's the good guy. He is not the good guy. He used someone else's resources without their permission and without even notifying them, costing them time & effort. Randy doesn't get to decide if the ASN owner should have alerted or investigated or whatever, and neither do any of you unless it is your ASN.
How can anyone seriously argue the ASN owner is somehow wrong and keep a straight face? How can anyone else who actually runs a network not see that as ridiculous?
> AS_PATH != identity, and I would not recommend loading
the latter onto the former.We disagree. When I am researching something, I frequently
look at ASNs in the path to figure out not just where but
who controls the path.
Oh, I certainly think that there is a loose coupling there, and the relationship is highly valuable from a troubleshooting point of view. However, I would counsel anyone investigating AS_Path relationships to remember that do not completely characterize the relationship between any two organizations, let alone the multipolar relationships between all organizations.
It's a good first-cut, but it doesn't have the level of authority that you're implying. I'm not aware of any ASNs being trademarked...
>> Personally, I would be upset if someone injected
a route
>> with my ASN in the AS_PATH without my permission.
>
> Why? Is this a theoretical "because it's
ugly" complaint, or is there a reason why manipulating
this particular BGP attribute in this particular way is so
bad? Organizations do filtering and routing manipulation
all over the place. Is there something worse about doing it
this way than others?Filtering and other manipulation happened on your router,
prepending my ASN is putting that information into every
router. That seems to be a serious qualitative difference
to me. Do you disagree?
This is qualitatively similar to an ASN announcing de-aggregated routes - it may be nice if they don't, and you don't have to accept them, but are they permitted?
This thread has been interesting & educational. So
many people seem to be happy to explain why they should be
allowed to use globally unique identifiers they do not own
in ways which were not intended, then explain to the people
who do own those identifiers how they should react, which
alarms should go off, and even which priority the alarms
should have.As I have repeated probably hundreds of times: Your
network, your decision. I have yet to hear a credible
argument against that stance. What you do _inside_ your
network is _your_ decision. When it leaves your network,
however, things change.
Exactly! Provider RB announces $WEIRD. A bunch of providers receive alarms about the existence of $WEIRD, and they treated this as $IMPORTANT. The bunch of providers who treated this as $IMPORTANT are informing all of us about their monitoring thresholds and their responses to this threshold being met. Their networks, their decisions.
It should be pointed out that pre-provisioned AS_Path filters and prefix-lists would actually be effective at defeating this and preventing someone who is actually malicious from using this technique. This is an excellent argument for implementing SIDR...
Announcing an ASN which is not yours to eBGP peers means it
is leaving your network, which means it is not just your
business. Doing so and then telling the ASN owner that they
should not worry about it afterwards - and in fact arguing
when the owner repeatedly tells you this caused them
problems - does not seem to be the proper course of action.
Understood, but if this is viewed as problematic, there is a very simple solution: don't allow a BGP customer (or peer!) to prepend someone else's ASN.
I mentioned earlier in the thread if Cogent prepending
Sprint's ASN to Verio, people would react differently.
Randy said tools can be used for good or bad, obviously
implying he's the good guy. He is not the good guy. He
used someone else's resources without their permission
and without even notifying them, costing them time &
effort. Randy doesn't get to decide if the ASN owner
should have alerted or investigated or whatever, and
neither do any of you unless it is your ASN.How can anyone seriously argue the ASN owner is somehow
wrong and keep a straight face? How can anyone else who
actually runs a network not see that as ridiculous?
Are any providers going to implement ^ASN filtering as a result of this experiment? This could turn out to be a very inexpensive lesson, which is far preferable to more expensive lessons...
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
Patrick W. Gilmore wrote:
Filtering and other manipulation happened on your router, prepending my ASN is putting that information into every router. That seems to be a serious qualitative difference to me. Do you disagree?
I think the basic disagreement is whether you think that "your stuff" is "select from internet where ASN is mine AND IP_ADDRESS is mine" or your stuff is "select from internet where ASN is mine OR IP_ADDRESS is mine".
The person conducting the experiment clearly thought it was ok to use "your ASN" as long as it was "his address" that was being announced, since as long as it is "his address" he's allowed to put whatever he wants in the AS PATH he announces to the world for it. ("I can list whatever I want as my age, it is my profile after all")
Others clearly think it is not ok to use "their ASN" with *any* address, and that even though it is "his address" he is only allowed to put numbers in the AS PATH that he has permission to put there. ("The terms of service say you must state your actual age in your profile so that state laws about what minors can/can't do/see can be complied with")
And of course nobody cares about the *other* integers that are involved in announcements, just the 32-bit ones that represent IP addresses and the 16- and 32-bit ones that represent ASNs. People who don't understand (like jurors) would probably be confused and/or think we're all crazy for arguing about this stuff.
Matthew Kaufman
Personally, I would be upset if someone injected
a route
with my ASN in the AS_PATH without my permission.
Why? Is this a theoretical "because it's
ugly" complaint, or is there a reason why manipulating
this particular BGP attribute in this particular way is so
bad? Organizations do filtering and routing manipulation
all over the place. Is there something worse about doing it
this way than others?Filtering and other manipulation happened on your router,
prepending my ASN is putting that information into every
router. That seems to be a serious qualitative difference
to me. Do you disagree?This is qualitatively similar to an ASN announcing de-aggregated routes - it may be nice if they don't, and you don't have to accept them, but are they permitted?
No it is not. You own the prefix in question, so you own the deaggregates of it. You do not own the ASN in question.
That you do not see the difference explains a great deal.
This thread has been interesting & educational. So
many people seem to be happy to explain why they should be
allowed to use globally unique identifiers they do not own
in ways which were not intended, then explain to the people
who do own those identifiers how they should react, which
alarms should go off, and even which priority the alarms
should have.As I have repeated probably hundreds of times: Your
network, your decision. I have yet to hear a credible
argument against that stance. What you do _inside_ your
network is _your_ decision. When it leaves your network,
however, things change.Exactly! Provider RB announces $WEIRD. A bunch of providers receive alarms about the existence of $WEIRD, and they treated this as $IMPORTANT. The bunch of providers who treated this as $IMPORTANT are informing all of us about their monitoring thresholds and their responses to this threshold being met. Their networks, their decisions.
Wow. Just .. wow.
"Exactly, even though I do something with your resources, announcing to the whole world, that cause you issues, you shouldn't tell me about because the alarms are inside your network."
Again, this explains a great deal.
It should be pointed out that pre-provisioned AS_Path filters and prefix-lists would actually be effective at defeating this and preventing someone who is actually malicious from using this technique. This is an excellent argument for implementing SIDR...
Finally we agree. Although I am not certain SIDR is the optimal answer, we agree it would solve the problem.
Announcing an ASN which is not yours to eBGP peers means it
is leaving your network, which means it is not just your
business. Doing so and then telling the ASN owner that they
should not worry about it afterwards - and in fact arguing
when the owner repeatedly tells you this caused them
problems - does not seem to be the proper course of action.Understood, but if this is viewed as problematic, there is a very simple solution: don't allow a BGP customer (or peer!) to prepend someone else's ASN.
How do you suppose I stop Randy from prepending my ASN?
> Does that mean that I hijacked their identiy and forged
> it? What level of trust do you place in the AS_PATH for your
> routing, debugging and
> decision making process?AS_PATH != identity, and I would not recommend loading the latter
onto the former.
But it does represent an interesting thing. Many people treat
AS_PATH as identiy, when infact it's not congruent.
> Personally, I would be upset if someone injected a route
> with my ASN in the AS_PATH without my permission.Why? Is this a theoretical "because it's ugly" complaint, or is there a
reason why manipulating this particular BGP attribute in this particular
way is so bad? Organizations do filtering and routing manipulation all
over the place. Is there something worse about doing it this way than others?
This is not "because it's ugly", but more complex to understand
the interaction.
People have asserted that injecting an as-path with 2914 will
utilize the loop-detection mechanisim to prevent reachability if your
transit is from 1239 or 174.
Except that 174 filters out these asns from their customers.
I've noticed zero complaints since my 'detecting routing leaks by
counting' system was presented at nanog that were not actual leaks when
too many SFI (tier-1?) asns showed up in a path.
While most of the challenge could be uneducated readers of an
as-path, without the protocol being changed, it really depends on the
elements in the path being genuine. Without this trust, we should all
configure our routers to allow our own as in, or work to make it the new
default, and ask providers to change their filtering of other SFI asns
from their customer as-paths.
- jared
Speaking purely as an outsider who hasn't had to pull such jack moves
with his tiny corner of the world these days, I've frequently seen people
pull exactly these jack moves for Traffic Engineering.
So either they're not talking and wish to remain nameless, or they're
talking and being hypocritical. But they do exist, and I'm pretty sure
they see it as another way of "hacking" the routing system to achieve
goals the original implementors didn't explicitly define, but have
operational relevance today.
But they're out there, injecting routes to peers to control traffic.
I remember the first time I saw it and said "uhm wtf?" followed by
"evil but clever." Much like other BGP tricks.
(Ah, how the internet seems to have grown up. Sniff.)
Adrian
Patrick W. Gilmore wrote:
Filtering and other manipulation happened on your router, prepending my ASN is putting that information into every router. That seems to be a serious qualitative difference to me. Do you disagree?
I think the basic disagreement is whether you think that "your stuff" is "select from internet where ASN is mine AND IP_ADDRESS is mine" or your stuff is "select from internet where ASN is mine OR IP_ADDRESS is mine".
There is no disagreement here. If you believe the ASN assigned to me for which I paid is not mine, you are confused.
The person conducting the experiment clearly thoughght it was ok to use "your ASN" as long as it was "his address" that was being announced, since as long as it is "his address" he's allowed to put whatever he wants in the AS PATH he announces to the world for it. ("I can list whatever I want as my age, it is my profile after all")
Randy is well aware it was not his ASN, no matter whose prefix it was.
Others clearly think it is not ok to use "their ASN" with *any* address, and that even though it is "his address" he is only allowed to put numbers in the AS PATH that he has permission to put there. ("The terms of service say you must state your actual age in your profile so that state laws about what minors can/can't do/see can be complied with")
And of course nobody cares about the *other* integers that are involved in announcements, just the 32-bit ones that represent IP addresses and the 16- and 32-bit ones that represent ASNs. People who don't understand (like jurors) would probably be confused and/or think we're all crazy for arguing about this stuff.
Fortunately, people who run networks are not clueless ("jurors"?). Or at least they are not supposed to be clueless.
An ASN is a well defined resource, with publicly available ownership information. If anyone on this list does not understand this, I suggest they do some more studying.
The idea that you can do something and get away with it sometimes makes it OK all the time is erroneous.
Extreme example: Sprint probably wouldn't post to NANOG or even complain if a little network announced one of their prefixes. Does that make it OK for any network to announce anyone else's prefix? Obviously not.
The fact is someone -did- notice, and instead of saying "I'm sorry, I won't do it again", Randy just said "I'm a good guy, doing an experiment" and implied it could not possibly be wrong. Worse, others actually berated the ASN owner for spending time & effort on the issue.
If you use my ASN for an experiment or anything else without permission, do not act surprised when I notice. And certainly do not try to act like it is just no big deal. Use your own autonomous system numbers if you want it to be "no big deal".
Patrick W. Gilmore wrote:
Fortunately, people who run networks are not clueless ("jurors"?). Or at least they are not supposed to be clueless.
If Randy were to be charged under any of the various computer abuse statutes (which, given the history of their (ab)use, he certainly could be), jurors are who would be trying to figure out whether or not it was ok to use "your" integer in a specific place in the BGP announcement he made.
That's why *I* wouldn't have run such an experiment myself, because there's just too many cases these days where people have gotten convicted of doing things like putting the wrong integer in their MySpace profile.
An ASN is a well defined resource, with publicly available ownership information. If anyone on this list does not understand this, I suggest they do some more studying.
It is an integer. Under ARIN policy you certainly don't "own" it, you just use it. In some places, that integer has meaning. How important that meaning is, and whether or not someone else can use the same integer in a similar place where it has that meaning without getting charged with a crime, we don't know. What we *do* know is that some people think it is valuable to try it out to get some experimental data, and other people are all up in arms about it.
Matthew Kaufman