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

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

On Tue, Jan 13, 2009 at 07:00:34AM -0800, David Barak wrote:

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

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 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Tue, Jan 13, 2009 at 07:00:34AM -0800, David Barak wrote:

...

If the concern was a Pilosov/Kapela style hijack, wouldn't the first

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 -----Original Message----- From: jim deleskie [mailto:deleskie@gmail.com] Sent: Tuesday, January 13, 2009 10:34 AM To: Jared Mauch Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 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 On Tue, Jan 13, 2009 at 11:06 AM, Jared Mauch <jared@puck.nether.net> wrote: 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...

...

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

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."

On Jan 13, 2009, at 11:53 AM, David Barak wrote:

--- On Tue, 1/13/09, Jared Mauch <jared@puck.nether.net> wrote:

...

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? -- TTFN, patrick

On Jan 13, 2009, at 1:11 PM, David Barak wrote:

--- On Tue, 1/13/09, Patrick W. Gilmore <patrick@ianai.net> wrote:

...

...

...

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? -- TTFN, patrick

Sandy Murphy wrote:

The sidr wg is working on protection of the origination of the route - so the origin AS in the AS_PATH is known to be authorized to originate routes to the prefix.

That's not full AS_PATH protection. sidr is not doing full AS_PATH protection.

Yet.

I always considered AS_PATH protection to be a waste of time. It does what it does, and has minor tweaking capabilities which I hope Randy will show are mostly pointless (ie, please quit doing this because it won't actually work as you want). heh. Someone should have added "modifying AS_PATH might confuse those people attempting to route IP traffic on the Internet." Similar to RFC 1930: There are few security concerns regarding the selection of ASes. AS number to owner mappings are public knowledge (in WHOIS), and attempting to change that would serve only to confuse those people attempting to route IP traffic on the Internet. I also like this statement from same RFC: ASX knows how to reach a prefix called NET1. It does not matter whether NET1 belongs to ASX or to some other AS which exchanges routing information with ASX, either directly or indirectly; we just assume that ASX knows how to direct packets towards NET1. Likewise ASY knows how to reach NET2. ie, We care about the AS we are peered with and all beyond it doesn't really matter (exception being the use of ASN in AS_PATH for loop detections). They wouldn't have even bothered assigning ASNs except to insure uniqueness when it comes to detecting routing loops in AS_PATH and for insuring two AS's that suddenly peer are unique. It is important that an ASN be unique, or loop detection on an AS_PATH would cause a possible lack of reachability (if 2 seperate AS's use the same ASN). That being said, the person advertising a route can change the AS_PATH to effect the reachability of their network in a variety of ways (most common is prepending their own ASN, least common is probably path truncating and use of atomic_aggregator). The real quirk is, given that an AS by definition has its own routing policy and announces it to peers, is path poisoning part of that AS's policy in order to not allow some routes via certain peers to be accepted by another AS to traffic engineer. Is not the point of BGP to define a routing policy? And just because this RFC cracks me up, one last quote: However, if the criteria applied above are adhered to, then there is no immediate danger of AS space exhaustion. It is expected that IDRP will be deployed before this becomes an issue. IDRP does not have a fixed limit on the size of an RDI. Let's switch already! ISIS and IDRP for life! Jack

On Jan 13, 2009, at 1:18 PM, Matthew Kaufman wrote:

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. -- TTFN, patrick

At 11:27 AM 13-01-09 -0800, Matthew Kaufman wrote:

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.

What if, by doing some research experiment, the researcher discovers some unknown and latent bug in IOS or JunOS that causes much of the Internet to go belly up? 1 in a billion chance, but nonetheless, a headsup would have been in order. -Hank

Interesting - So as a cyber criminal - I could setup a router, start announcing AS 16733, 18872, and maybe 6966 for good measure and their routers would ignore my announcements and IP ranges that I siphoned from searching IANA? Hm... Would that also prevent them from accessing my rogue network from their network? - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Simon Lockhart [mailto:simon@slimey.org] Sent: Wednesday, January 14, 2009 2:07 AM To: Hank Nussbacher Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote:

What if, by doing some research experiment, the researcher discovers some unknown and latent bug in IOS or JunOS that causes much of the Internet to go belly up? 1 in a billion chance, but nonetheless, a headsup would have been in order.

Say we had a customer who connected to us over BGP, and they used some new experimental BGP daemon. Their announcement was "odd" in some way, but appeared clean to us (a Cisco house). Once their announcement hit the a Foundry router, it tickled a bug which caused the router to propogate the announcement, but also start to blackhole traffic. Oh dear, large chunks of the Internet have just gone belly up. Should we have given a heads up to the Internet at large that we were turning up this customer? Simon (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info@bogons.net *

Simon Lockhart [mailto:simon@slimey.org] wrote:

On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote:

...

What if, by doing some research experiment, the researcher discovers some unknown and latent bug in IOS or JunOS that causes much of the Internet to go belly up? 1 in a billion chance, but nonetheless, a headsup would have been in order.

Say we had a customer who connected to us over BGP, and they used some new experimental BGP daemon. Their announcement was "odd" in some way, but appeared clean to us (a Cisco house). Once their announcement hit the a Foundry router, it tickled a bug which caused the router to propogate the announcement, but also start to blackhole traffic. Oh dear, large chunks of the Internet have just gone belly up.

You mean like when people started using 32bit ASNs and all OpenBGPD implementations went belly up? See http://www.merit.edu/mail.archives/nanog/msg13416.html Happening clearly often. People should write proper implementations (Just in case, OpenBGPD acted correctly as it did it to the letter of the RFC, though it could have maybe warned the admins)

Should we have given a heads up to the Internet at large that we were turning up this customer?

ASN32 was known quite in advance, that doesn't mean that everybody updates or that all bugs are found. Vendors tend to deploy things into the wild which then break, simply because not all combinations of configuration can ever be tested. Infinite Monkeys etc ;)

Simon (Yes, I'm in the minority that thinks that Randy hasn't done anything bad)

Nah, I agree with Randy's experiment too. People should protect their networks better and this is clearly showing that there are a lot of vulnerable places in the core internet structure. Btw folks, when do you start implementing RPSL based filtering? Clearly a lot are using the BGP monitoring already and seem to love it, thus take the next step go full SIDR :) Greets, Jeroen

On Jan 15, 2009, at 3:54 AM, Andy Davidson wrote:

On 14 Jan 2009, at 16:06, Jeroen Massar wrote:

...

...

(Yes, I'm in the minority that thinks that Randy hasn't done anything bad) Nah, I agree with Randy's experiment too. People should protect

Simon Lockhart wrote: their networks better and this is clearly showing that there are a lot of vulnerable places in the core internet structure.

The end sometimes justifies the means, and someone in the research community discovering flaws in bgp implementation (software, protocol, or process - at the bgp stack, in my NOC tools, in the community's understanding) before hackers/spammers/fraudsters do, then I count that as a result.

We disagree. The 'researcher' does not get to decide whether the information gained by yelling fire to see how quickly people react is worth the risk of someone getting hurt, or even just missing the rest of the movie. No reputable research institution's ethics committee would allow an "experiment" to proceed which announced a prefix in such a way that every network engineer on the planet would assume the prefix traveled through $ASN even though the prefix had not, and the researcher did not even notify $ASN of the experiment. -- TTFN, patrick

Michienne Dixon wrote:

Interesting - So as a cyber criminal - I could setup a router, start announcing AS 16733, 18872, and maybe 6966 for good measure and their routers would ignore my announcements and IP ranges that I siphoned from searching IANA? Hm... Would that also prevent them from accessing my rogue network from their network?

It may or may not prevent them from accessing your rogue network. FYI, given that this is a reachability test, it sounds like this is exactly the question Randy should be able to answer in the results. The other keys are, how effective is it at traffic engineering for load shifting and partitioning anycast. Jack

Well, if you really want to pick knits you are welcome to. If I meant prepending, I would have said that. The example that I listed was setting up a router, advertising the ASNs listed and the random IP ranges gleaned from IANA. Sorry if I confused you. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: John Payne [mailto:john@sackheads.org] Sent: Wednesday, January 14, 2009 3:57 PM To: Michienne Dixon Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Jan 14, 2009, at 10:50 AM, Michienne Dixon wrote:

Interesting - So as a cyber criminal - I could setup a router, start announcing AS 16733, 18872, and maybe 6966 for good measure and their routers would ignore my announcements and IP ranges that I siphoned from searching IANA? Hm... Would that also prevent them from accessing my rogue network from their network?

What do you mean "announcing AS 16733..." ? Putting 16733 in an AS PATH is not announcing it.

- Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990

-----Original Message----- From: Simon Lockhart [mailto:simon@slimey.org] Sent: Wednesday, January 14, 2009 2:07 AM To: Hank Nussbacher Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24

On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote:

...

What if, by doing some research experiment, the researcher discovers some unknown and latent bug in IOS or JunOS that causes much of the Internet to go belly up? 1 in a billion chance, but nonetheless, a headsup would have been in order.

Say we had a customer who connected to us over BGP, and they used some

new experimental BGP daemon. Their announcement was "odd" in some way,

but appeared clean to us (a Cisco house). Once their announcement hit the a Foundry router, it tickled a bug which caused the router to propogate the announcement, but also start to blackhole traffic. Oh dear, large chunks of the Internet have just gone belly up.

Should we have given a heads up to the Internet at large that we were turning up this customer?

Simon (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) --

Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info@bogons.net *

On Jan 14, 2009, at 6:22 PM, kris foster wrote:

On Jan 14, 2009, at 2:52 PM, Michienne Dixon wrote:

...

Well, if you really want to pick knits you are welcome to. If I meant prepending, I would have said that. The example that I listed was setting up a router, advertising the ASNs listed and the random IP ranges gleaned from IANA. Sorry if I confused you.

The point I believe John is trying to make is that *ASNs are not announced*. There are no advertisements that say "this is how to get to ASN X". BGP updates specifically announce network layer reachability.

This is an important point in this discussion. There are a lot of comments being made that are just simply wrong and causing confusion because of slips in terminology regarding the path attribute.

Thanks Kris - exactly what I was getting to.

Kris

...

-----Original Message----- From: John Payne [mailto:john@sackheads.org] Sent: Wednesday, January 14, 2009 3:57 PM To: Michienne Dixon Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24

On Jan 14, 2009, at 10:50 AM, Michienne Dixon wrote:

...

Interesting - So as a cyber criminal - I could setup a router, start announcing AS 16733, 18872, and maybe 6966 for good measure and their routers would ignore my announcements and IP ranges that I siphoned from searching IANA? Hm... Would that also prevent them from accessing my rogue network from their network?

What do you mean "announcing AS 16733..." ?

Putting 16733 in an AS PATH is not announcing it.

...

- Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990

-----Original Message----- From: Simon Lockhart [mailto:simon@slimey.org] Sent: Wednesday, January 14, 2009 2:07 AM To: Hank Nussbacher Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24

On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote:

...

What if, by doing some research experiment, the researcher discovers some unknown and latent bug in IOS or JunOS that causes much of the Internet to go belly up? 1 in a billion chance, but nonetheless, a headsup would have been in order.

Say we had a customer who connected to us over BGP, and they used some

...

new experimental BGP daemon. Their announcement was "odd" in some way,

...

but appeared clean to us (a Cisco house). Once their announcement hit the a Foundry router, it tickled a bug which caused the router to propogate the announcement, but also start to blackhole traffic. Oh dear, large chunks of the Internet have just gone belly up.

Should we have given a heads up to the Internet at large that we were turning up this customer?

Simon (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) --

Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info@bogons.net *

On Jan 13, 2009, at 1:27 PM, Adrian Chadd wrote:

On Tue, Jan 13, 2009, Patrick W. Gilmore wrote:

...

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?

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. :)

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". -- TTFN, patrick

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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.