Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul -----Original Message----- From: Majdi S. Abbas [mailto:msa@latt.net] Sent: Monday, January 12, 2009 1:49 PM To: Michienne Dixon Cc: nanog@nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Mon, Jan 12, 2009 at 12:40:42PM -0600, Michienne Dixon wrote:

I'm not entirely certain what is going on but has anyone noticed some strange announcements for 174.128.31.0/24?

I received a hijack notice that my AS (AS11708) was announcing the above IP range. I verified that I was not when I started noticing some strange announcements for that range. Around 10 Am CST AS11911 was announcing it (AS_PATH: 1239 2914 3130 11911) then around 11:30 AM CST I observed AS12083 announcing it (AS_PATH: 1239 2914 3130 12083).

Interestingly enough, ARIN indicates this is a part of range they have assigned for reachability testing. http://ws.arin.net/whois/?queryinput=174.128.31.0

randy lied but no packets died enough now More seriously, this is indeed reachability research. Try emailing the AS 3130 contacts although I'd imagine Randy will see this. Thanks, --msa ---------------------------------------------------------------------------- "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."

The IAR was the source of my notice as well and is what started me down this path of cat herding. I would think that it would only be polite to notify people about what is going on so that other people do not waste their time looking for phantom issues. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org <http://www.linkcity.org/> (816) 412-7990 ________________________________ From: karlinjf@gmail.com [mailto:karlinjf@gmail.com] On Behalf Of Josh Karlin Sent: Monday, January 12, 2009 12:57 PM To: Paul Stewart Cc: Majdi S. Abbas; Michienne Dixon; nanog@nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 At some point 3130 announced these prefixes, and is now prepending other ASes to them. Pretty Good BGP (and hence the IAR) sees them as prefix hijacks. If you'd like to see the entire list of prefixes, check out: http://iar.cs.unm.edu/search.php and enter in 3130 as the "Victim AS" Josh On Mon, Jan 12, 2009 at 11:52 AM, Paul Stewart <pstewart@nexicomgroup.net> wrote: Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul

I agree with Paul and Michienne, having the courtesy to notify next time would be very much appreciated. I was headed into a family member's funeral when I received the hijack notification. I took the 15 minutes to do some quick investigation, fire off a few emails informing my colleagues of the issue and "arrived" at the funeral a bit late. Perhaps in the future it would be better not to play with my toys without asking my permission first? - - - - Joshua Fiske '03, '04 Network and Security Engineer Clarkson University, Office of Information Technology (315) 268-6722 -- Fax: (315) 268-6570 I route, therefore you are. Think before you print. CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. -----Original Message----- From: Paul Stewart [mailto:pstewart@nexicomgroup.net] Sent: Monday, January 12, 2009 2:29 PM To: Michienne Dixon; nanog@nanog.org Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 Absolutely - according to their website " No real or production prefixes or data packets are being harmed in this experiment. If you become aware that this experiment causes any actual real operational problem, please write to us immediately. " I have asked them to have some courtesy next time before wasting a lot of people's time... Paul -----Original Message----- From: Michienne Dixon [mailto:mdixon@nkc.org] Sent: Monday, January 12, 2009 2:20 PM To: nanog@nanog.org Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 The IAR was the source of my notice as well and is what started me down this path of cat herding. I would think that it would only be polite to notify people about what is going on so that other people do not waste their time looking for phantom issues. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org <http://www.linkcity.org/> (816) 412-7990 ________________________________ From: karlinjf@gmail.com [mailto:karlinjf@gmail.com] On Behalf Of Josh Karlin Sent: Monday, January 12, 2009 12:57 PM To: Paul Stewart Cc: Majdi S. Abbas; Michienne Dixon; nanog@nanog.org Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 At some point 3130 announced these prefixes, and is now prepending other ASes to them. Pretty Good BGP (and hence the IAR) sees them as prefix hijacks. If you'd like to see the entire list of prefixes, check out: http://iar.cs.unm.edu/search.php and enter in 3130 as the "Victim AS" Josh On Mon, Jan 12, 2009 at 11:52 AM, Paul Stewart <pstewart@nexicomgroup.net> wrote: Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter... If they are going to involve our AS numbers and trigger alarms it would be nice to notify us first... especially on something as major as a prefix hijacking (potentially) Paul ------------------------------------------------------------------------ ---- "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 09.01.13 03:52, Paul Stewart wrote:

Same here.. got a notice this morning and while it's false, I still have no response from Randy neither on this matter..

guy's gotta sleep some time. it's 04:40 here. if you wrote me directly, you would have a response by now. almost to the bottom of my mailbox. part of the experiment is to measure the difference between the amount of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we get in 2009 while not pre-announcing. :) randy

On 09.01.13 05:32, Michienne Dixon wrote:

...

guy's gotta sleep some time. it's 04:40 here. My apologizes for jumping the gun.

i demand a full refund! :) but that's about the best use for guns i can think of. randy

Might be helpful to update the WHOIS data:

arin's good folk say it will be updated in tonight's (stateside night) run. randy

Florian Weimer wrote:

I think this is over the line. You can't put other people's IDs into routing data on production networks. (Well, technically you can, obviously, but you shouldn't.)

Actually, the placement of the ASN is exactly what they need to do the test, as it is treated as a routing loop and discarded. This allows for fancy reachability tests while a portion of the network cannot see the route in question. Of course, people track their ASN usage these days and get red alarms when their ASN shows up in ways unexpected. I'm not completely sure why the ASN matters, except it's probably just a bonus service to route hijacking detection (since ASN hijacking doesn't exactly serve a purpose except to limit the route being advertised and perhaps leave someone complaining to the wrong person if the hijacker is doing bad things). Jack

On 2009-01-12, at 15:39, Florian Weimer wrote:

So does "academic" mean "unethical" these days?

I think this is over the line. You can't put other people's IDs into routing data on production networks. (Well, technically you can, obviously, but you shouldn't.)

The AS_PATH attribute is a loop-avoidance mechanism, not a signature on a cheque. AS_PATH prepending with your own and with others' AS numbers (the latter intended to effect "don't let this prefix leak into that AS") has been sitting in the inter-domain traffic engineering toolbox for years. I see no lack of ethics in the simple act of the as-path prepend as part of a route export policy. Joe

If this were not Randy doing a research project, but, say, Cogent prepending the ASN of $LATEST_DEPEERED_NETWORK on announcements to Verio, how different would the tone of this thread have been?

yep, tools can be used for both good and bad. randy

On Mon, Jan 12, 2009 at 04:51:36PM -0500, Joe Abley wrote: [snip]

In my experience prepending someone else's AS to a prefix has only been useful operationally only as a short-term, emergency measure (e.g. when trying to avoid a black-hole between two remote ASes, neither of whom shows any signs of fixing the problem).

Randy's application, and Lorenzo's before him also seem like short- term applications designed to explore answering operational questions.

Nit, weird paths (this one) and long paths (Lorenzo's) are different. There were known BGP implementations which choked and died on long as-paths, which (w|c)ould trigger outages. Weird paths which appear to involve your network triggers -at least- work.

Just because something is generally not used, or even if it's only worth using in an emergency, doesn't make it "sketchy".

Given the prevalence of BGP community-based remote control over your direct neighbor's neighbors, it has seemed to (to me) to decrease. Using a label allocated to someone else does indeed seem sketchy to many of us; while the injector knows they are doing it and the injectee can figure it out, there's a heck of a lot of other parties (and archives) without context. Encouraging the use of such approaches, rather than encouraging providers to provision customers without the ability to forge AS paths, is a step in the wrong direction.

Most knee-jerk reactions to AS_PATH manipulation sound to me like fear of the unusual.

Less fear and more annoyance; the waters are muddied and the unusual requires investigation, and in some cases explanation internally & externally. Propagating bad table hygiene doesn't promote network use, increase stability/robustness, or anything that could be viewed as best practice. All IMO, of course. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

] part of the experiment is to measure the difference between the amount ] of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we ] get in 2009 while not pre-announcing. :)

This statement is an admission that he set out to annoy people, annoy them enough they would complain on a public mailing list.

while you managed to quote the smiley, you somehow did not manage to parse it. do not leave your sense of humor at the door with your guns. randy

For us, it was annoying - we look for prefix hijackings or what appear to be. In this case it was a false alarm but one that consumed NOC resources to troubleshoot and resolve... later to find out it was an "academic test" and nothing was really going on. Paul -----Original Message----- From: Christian Koch [mailto:christian@broknrobot.com] Sent: January 12, 2009 5:34 PM To: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 <snip>

] part of the experiment is to measure the difference between the

amount

] of nanog mail lorenzo drew in 2005 by pre-announcing with the amount we ] get in 2009 while not pre-announcing. :)

This statement is an admission that he set out to annoy people, annoy them enough they would complain on a public mailing list. More over, I can't see how any researcher could use "the amount of nanog mail" as a valid indicator of anything. It has as much to do with how many engineers are bored on a given day as it does with the severity of the problem.

So the goal of this research seemed to be to see how many people the researchers could panic, and then see how 10,000 people reacted to the panic. Sounds a lot like yelling "fire" in a crowded movie house just to "research" what the results might be, and then measuring success by the number of words in the article on the front page of the paper, or perhaps the number of people trampled to death, or both.

maybe not so much annoy people, rather see how many people actually noticed the announcements and were aware that their AS was being used as an origin in the path ---------------------------------------------------------------------------- "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."

Hi Randy (and the cast of characters on this thread), Could you please put in a lightning talk for this experiment? It would be great to hear more about this in .DR. We're accepting submissions now for lightning talks on Monday the 26th of January. http://www.nanogpc.org is the best place. Cheers, -ren On Mon, Jan 12, 2009 at 5:47 PM, Randy Bush <randy@psg.com> wrote:

On 09.01.13 07:42, Paul Stewart wrote:

...

For us, it was annoying - we look for prefix hijackings or what appear to be.

i think herein lies the rub. it is not prefix hijacking and in no way should it appear that way to you. i suggest tuning your detectors. i am told that path poisoning is used (futilely, we hope to show) in day to day ops by folk to try to avert dos attacks.

randy

Fair enough. Unfortunate, and I'll miss you in .DR, but understood. Now that doesn't mean other operators can't put in a lightning talk about the impact or 'event' this triggered in their own NOC environments along with what they recommend operators do to reduce the spun cycles <G> Cheers, -ren On Mon, Jan 12, 2009 at 5:57 PM, Randy Bush <randy@psg.com> wrote:

Could you please put in a lightning talk for this experiment? It would

...

be great to hear more about this in .DR. We're accepting submissions now for lightning talks on Monday the 26th of January.

a - i will not be in dr. i really wanted to support the dr meeting, but it's hard to justify after four years of service. maybe i'll make the next one.

b - we can not present results before papers are submitted.

c - we hope to present results at ops fora, nanog included, if they are good enough to warrant as opposed to just good sensationalist blah blah.

randy

On Mon, Jan 12, 2009 at 05:13:10PM -0600, Michienne Dixon wrote: [snip]

Easy - Refer all anomalies that do not the result of a direct outage to Randy. :D

...if he's the contact or expressly mentioned in the registration, that makes sense. Oh look, he is. %whonum 174.128.31.0 OrgName: American Registry for Internet Numbers OrgID: ARIN Address: 3635 Concorde Parkway Address: Suite 200 City: Chantilly StateProv: VA PostalCode: 20151 Country: US NetRange: 174.128.0.0 - 174.128.255.255 CIDR: 174.128.0.0/16 NetName: ARIN-REACHABILITY-TESTING NetHandle: NET-174-128-0-0-1 Parent: NET-174-0-0-0-0 NetType: Direct Assignment NameServer: RIP.PSG.COM NameServer: NS0.REM.COM Comment: This IP address block is being used by ARIN to conduct reachability testing in networks 173.0.0.0/8 and 174.0.0.0/8. Please contact randy@psg.com with feedback or questions on the testing. RegDate: 2008-02-27 Updated: 2008-02-27 OrgNOCHandle: ARINN-ARIN OrgNOCName: ARIN NOC OrgNOCPhone: +1-703-227-9840 OrgNOCEmail: noc@arin.net OrgTechHandle: ARIN-HOSTMASTER OrgTechName: Registration Services Department OrgTechPhone: +1-703-227-0660 OrgTechEmail: hostmaster@arin.net # ARIN WHOIS database, last updated 2009-01-11 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. % -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

Now that doesn't mean other operators can't put in a lightning talk about the impact or 'event' this triggered in their own NOC environments along with what they recommend operators do to reduce the spun cycles <G>

great idea! as i was about to send to someone else with a thinner skin than you :) path poisoning is used operationally, though we suspect somewhat ill-advisedly. but the proof of the latter will be in the pudding. imiho, alarm systems that raise a real alert about my asn being in the as path of *someone else's prefix* are systems i would repair. at most, it's a "when you're bored, take a look at this strangeness." of course, we're sorry we set off folk's broken alarm systems :-) [ sense of humor required, leo ] and, fwiw, i liked the haiku! randy

On Mon, Jan 12, 2009 at 7:29 PM, Leo Bicknell <bicknell@ufp.org> wrote:

You really should make some friends Randy.

He is, on Second Life. Seriously though... I've not seen any discussion of the application of "allowas-in", a valid neighbor configuration under certain topologies/scenarios, as relates to impact today. Also, I'd agree announcing other peoples' ASNs, without their permission, is in bad form. It's okay he's doing it to you, but I bet Randy would be a lot less smiley if you were to announce random paths with 3130. Drive Slow, Paul Wall

In a message written on Tue, Jan 13, 2009 at 08:55:40AM -0500, John Payne wrote:

I guess the problem is that AS PATH is overloaded and people forget that the primary purpose is loop-avoidance. Everything else is secondary and much like reading Received headers in SMTP mail, you really should take everything after your direct neighbor's AS with a grain of salt.

Actually, I'd suggest your not looking at the primary purpose close enough. Loop detection kicks in only when there is a loop. You see your own ASN coming back to you. In the case we're discussing THERE IS NO LOOP. Someone is mis-using this feature to control the propagation of routes. Were the victim to do a show ip bgp neighbor foo receive-routes and see their own path they would be reasonable to assume that there is a loop, and someone is reflecting their own route back to them. This is a human configuring a device to lie about the loop status in the network. That is also the problem with this method, it is exactly the opposite of what the attribute was meant to convey, and thus someone on the other end who doesn't know what you're doing is virtually guaranteed to make the wrong assumption. You're going to spin up network engineers looking for routing loops, route leaks, and other issues if you use this method. I'd also suggest, as Jared pointed out, there are potential libel / trade-dress / slander implications here. Sending out an AS-Path of "ASfoo ASbar" is the technological equivalent of the English statement "foo and bar are interconnected with BGP". Just because you hide a false statement in an AS-Path doesn't make it any less of a false statement. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Jan 13, 2009, at 3:30 PM, Joe Abley wrote:

...

Were the victim

Heh, if only there was any sign of a victim.

The guy who spent time & effort investigating why his AS was misused announced it here. I'd call that at least a sign. -- TTFN, patrick

On Jan 13, 2009, at 3:36 PM, Joe Abley wrote:

On 13 Jan 2009, at 15:32, Patrick W. Gilmore wrote:

...

On Jan 13, 2009, at 3:30 PM, Joe Abley wrote:

...

...

Were the victim

Heh, if only there was any sign of a victim.

The guy who spent time & effort investigating why his AS was misused announced it here. I'd call that at least a sign.

I'd call it a sign that people need to be more selective about what they spend their time reacting to, and that pretty much wraps up the operational content of this thread, as far as I can see. Bring back the haikus!

Joe, See my earlier posts about using someone else's resources without their permission or even notifying them, then telling them it is OK because they shouldn't care anyway. Really, this is not how I expected someone of your caliber to respond. -- TTFN, patrick

On 13 Jan 2009, at 15:39, Patrick W. Gilmore wrote:

See my earlier posts about using someone else's resources without their permission or even notifying them, then telling them it is OK because they shouldn't care anyway.

I read them. Nobody is using anybody else's resources. None of the people who reacted did so because their prefixes had been hijacked. All that happened was that someone decided to attach an attribute to a non-hijacked prefix that made people scratch their heads, because to them it was an unusual use of the attribute. If I want to advertise a prefix, I'll attach whatever attributes I like to it. People can choose not to accept it if they want, as ever. What next? Am I "hijacking AS 701" if I attach the community string attribute 701:1000 to a prefix I originate, or even one I learn from a peer or customer? The fact that I choose to stick 701 in an AS_PATH attribute on a prefix I advertise in order to stop that prefix from propagating into 701 is entirely my own business, and it's a practice which, although apparently not commonplace, has been a well-known part of the IDTE toolbox for many years. The only real victims of this recent (non-)event are the people who have spent time wading through an enormous circular thread filled with people trying to convince others to change their minds about something that had no operational impact whatsoever to anybody, regardless of the fact that it's surely by now clear that nobody is interested in changing their mind.

Really, this is not how I expected someone of your caliber to respond.

Then apparently you hadn't read any of my other comments in this thread (or perhaps this was intended just as weak ad-hominem wrist- slapping). Joe

On Jan 14, 2009, at 2:50 AM, Tim Franklin wrote:

On Tue, January 13, 2009 8:57 pm, Joe Abley wrote:

...

The fact that I choose to stick 701 in an AS_PATH attribute on a prefix I advertise in order to stop that prefix from propagating into 701 is entirely my own business, and it's a practice which, although apparently not commonplace, has been a well-known part of the IDTE toolbox for many years.

For whatever reason, technical, political, or pure whim, I don't want AS Y to receive any of my announcements.

What's the correct tool to do this?

Exactly the method Randy used.

Do we need a set of well-known communities XXXXX:AS that can be recognised everywhere as "do not announce to AS"?

Communities are optional transitive attributes. No one is required to act on well-known communities. Kris

Yes, but I see that Randy has switched over to 3130 <poisoned AS> 3130,

when olaf first tested our his code in lab, it was against a quagga, which would not accept that. matt petach, in private email, asked why we were not doing it. as it seemed to be in spec, olaf did it against a crisco, and it works. thanks matt. randy

Like Paul said below - On the surface it looked legit. I received a notice indicating my AS had done some wrong and that I should correct the issue. Of course I am going to investigate - Maybe I fat fingered something or one of my tech had done something like not clearing the code of a lab router when connecting it to the production network. Or....Maybe there was something nefarious going. When I attempted to contact the source of the notice and inform them that I was not hijacking IP space the message bounced. I did look up the owner of the netblock. I saw that it was an experimental range. I sent an email to Randy (sorry for the fire storm that followed) but did not receive a response. Being the reformed juvenile delinquent I am, my line of thought went to "Hm...Someone could be up to no-good. I better find out more." I could have chosen to ignore it and say "WTF, I'm not doing anything wrong. Why should I care?". Instead I chose to ask my peers, many of whom are much more knowledgeable than I am, because I feel as network engineers, administrators, and router-jocks, it is our responsibility to safe-guard internet traffic and insure reliable communication when we can. /My $.02 - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Paul Stewart [mailto:pstewart@nexicomgroup.net] Sent: Tuesday, January 13, 2009 2:52 PM To: Joe Abley; Patrick W. Gilmore Cc: NANOG list Subject: RE: Anyone notice strange announcements for 174.128.31.0/24 Ummmmm.. no. I can't speak for the others on this list who were effected like us - but we take this stuff very seriously and respectively you would too *if* you had a previous legit issue that appeared to the same **on the surface**. A cautious and indepth look at this was taken upon us hoping that history wasn't repeating itself (previously explained) and thankfully it wasn't ... but until the time is spent to make absolutely sure how do you know?? At the end of the day, it wasn't a serious operational issue but raised a number of concerns I believe.... Paul

On 2009-01-13, at 00:05, Paul Wall wrote:

Also, I'd agree announcing other peoples' ASNs,

How do you announce an ASN? Joe

On Tue, Jan 13, 2009 at 12:11 PM, Matthew Kaufman <matthew@eeph.com> wrote:

On Jan 13, 2009, at 6:34 AM, Joe Abley <jabley@hopcount.ca> wrote:

...

On 2009-01-13, at 00:05, Paul Wall wrote:

Also, I'd agree

...

announcing other peoples' ASNs,

How do you announce an ASN?

Clearly it means to use someone else's ASN without authorization in a way that is not intended by the org/person it I'd assigned to.

I think that this is really a matter of being able to opt out, preferably in, to these public network experiments. This type of thing has a correlation to events past. No reason to raise dead bodies, but we've seen this before and have dealt swiftly, and decisively all based on choice. Best, Martin -- Martin Hannigan martin@theicelandguy.com p: +16178216079

bmanning@vacation.karoshi.com wrote: [..]

there is some indication that this prefix was assigned for a specific experiment, the experiment ran, results published, and then the prefix was not properly reclaimed... and so was reused for something else.

Interresting that you say that. Still using 3ffe::/24 and ip6.int I guess? :) You clearly thought you needed to keep your 'customers' connected on the 6bone using that block of space. Yesterday I found in somebody's email the following traceroute:

2: 10gigabitethernet3-2.core1.sjc2.he.net 64.435ms 3: 10gigabitethernet3-2.core1.pao1.he.net 59.724ms 4: 3ffe:80a::b2 64.184ms 5: hitachi1.otemachi.wide.ad.jp 203.714ms

Yeah, it is alive, 6bone LIVES!!!!! [*] Gee another address-playspace of a certain someone. Seriously, some ISP's should finally after more than 2,5 years after that experiment called 6bone got closed down realize that PEERING over PAIX which is still using 6bone addresses is quite silly and routing those addresses is simply not done. Then again, don't know if Bill can do anything about this one as clearly the ISPs involved who are still using those addresses are to blame that they clearly do not care about their network, even though they very well know from over the years that 6bone was closed down and the address space returned to IANA. Then again, for those ISPs involved uRPF is also something hard to understand it seems. Greets, Jeroen -- [*] ipv6-site: ISI-LAP origin: AS4554 descr: LAP-EXCHANGE Los Angeles country: US prefix: 3FFE:800::/24 [..] contact: BM2-6BONE person: Bill Manning address: po 12317, mdr, ca. usa phone: +1.310.322.8102 e-mail: bmanning@isi.edu nic-hdl: BM2-6BONE [..]

bmanning@vacation.karoshi.com wrote:

On Tue, Jan 13, 2009 at 09:17:24AM +0100, Jeroen Massar wrote:

...

bmanning@vacation.karoshi.com wrote: [..]

...

there is some indication that this prefix was assigned for a specific experiment, the experiment ran, results published, and then the prefix was not properly reclaimed... and so was reused for something else. Interresting that you say that. Still using 3ffe::/24 and ip6.int I guess? :) You clearly thought you needed to keep your 'customers' connected on the 6bone using that block of space.

you guess wrong.

Not a guess, it is what you wrote, long live archives: http://www.mail-archive.com/nanog@nanog.org/msg00270.html has: 8<----------------------------- bmanning wrote: [..] Sure... there are only a few left. Got rid of two a couple weeks back. That said.... I will announce the prefix as long as people are using it. (whine away) [..] ----------------------------->8 Other references you probably still have unread in your mailbox. Greets, Jeroen

But isn't this method kind of related to how an network from the Mediterranean/Mid-east went about blocking what they felt was undesirable/offensive content from entering their network? - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Monday, January 12, 2009 4:47 PM To: Paul Stewart Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On 09.01.13 07:42, Paul Stewart wrote:

For us, it was annoying - we look for prefix hijackings or what appear

to be.

i think herein lies the rub. it is not prefix hijacking and in no way should it appear that way to you. i suggest tuning your detectors. i am told that path poisoning is used (futilely, we hope to show) in day to day ops by folk to try to avert dos attacks. randy

I sit corrected. I thought they had started announcing someone else's AS and network range. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Monday, January 12, 2009 5:00 PM To: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Jan 12, 2009, at 5:55 PM, Michienne Dixon wrote:

But isn't this method kind of related to how an network from the Mediterranean/Mid-east went about blocking what they felt was undesirable/offensive content from entering their network?

No. -- TTFN, patrick

On Mon, Jan 12, 2009 at 5:51 PM, Michienne Dixon <mdixon@nkc.org> wrote:

I would consider this analogous to a customer testing their home alarm system and not letting the alarm company know about the test.

It's more like one owner in a condominium deciding to "test" the fire alarm without first asking the condo association or letting the other owners know about it ahead of time. Or a charitable telemarketer demon-dialing at 5 am and, when you register your outrage, suggesting that if you don't want to be bothered you should turn off the ringer before you go to bed. On Mon, Jan 12, 2009 at 2:37 PM, Randy Bush <randy@psg.com> wrote:

These prefixes are being used in academic routing research experiments.

That's what the polling robocalls say around election time. They're just conducting research... Would you really want to harm the democratic process by insisting that they not call you? How hard is it to just hang up... Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

And yes, it applies in the network world as well. When we pre-announce "We will be doing network scans from IP address w.x.y.z", we have a lot of users who will just blindly firewall off that IP rather than fixing their real issue they know the scan will detect...

I think if this could have been the case in the network security research

Knowing the Randy's research, i am sure that Randy will be doing great work this time too. Being a network researcher I can not wait more to see results of this experiments. But, even then I dont think it was a real smart thing to do without prior permission. then we would not have some this far (though it still is not that far :) ) in the field. People have contributed specifically for research in the past and I hope will remain doing so. -- Ghulam Murtaza Lahore University of Management Sciences