Re: Operators Penalized? (was Re: Kenyan Route Hijack)
On Mon, 17 Mar 2008, Larry J. Blunk wrote: RFC2827 is about source address filtering which is not really the same as BGP route announcement filtering. Unfortunately, I have not come across any RFC's with a thorough discussion of route filtering. It is mentioned briefly in RFC 3013, but section 4.5 only suggests filtering routes for private address space. RFC 4778 also mentions it, but again, there is no in depth discussion. Perhaps it is time for an RFC dedicated to route filtering practices? This provides half a page summary of what can be done without sweating too much: http://tools.ietf.org/html/draft-savola-rtgwg-backbone-attacks-03#section-3.2 Applying a (secure) IRR database to build filters for peers and transits has not (AFAIK) been very well documented anywhere. But on the other hand, not too many people are using it either. Unless a better place or a new document is found for that, I can add some verbiage to the abovementioned draft. (Currently, however, it is not obvious to me if that draft is going to progress, and if so which IETF WG or similar forum would be the right place to develop it.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Operators Penalized? (was Re: Kenyan Route Hijack)
On Mon, Mar 17, 2008 at 8:48 PM, Larry J. Blunk <[EMAIL PROTECTED]> wrote: >RFC2827 is about source address filtering which > is not really the same as BGP route announcement > filtering. Unfortunately, I have not come across Yup, radb etc for that. Not fully awake when I wrote that, and hit send too soon. The PTCL thing was deliberate origination of a bogus prefix, meant for consumption by Pakistani ISPs . Abovenet too - they surely intended SOMETHING (no idea what) - announcements dont come tagged with communities (and communities with maybe 130 odd prefixes out of the huge number that abovenet advertises) simply by accident.Leaking that prefix out might be accidental - or it was not leaked at all, abovenet is massive, lots of transit customers. PTCL leaking youtube prefixes out to the world rather than pakistani ISPs was an accident. And their upstream PCCW not filtering weird and wonderful route advertisements from downstream customers was .. well, a decision that PCCW took (or rather, chose not to take) That wasnt the first bogus announcement PTCL made .. about a day or so after l'affaire youtube, I looked up PTCL's AS17557 on cidr-report, which also lists allocations announced and withdrawn in the past week. One interesting allocation .. 22.22.22.0/24 22.0.0.0/8 Prefixes added and withdrawn by this origin AS in the past 7 days. - 22.22.22.0/24 Withdrawn That's nic.mil IP space - and that sounds a lot like someone with enable at PTCL probably meant 202 or something similar, but is in the habit of typing new routes directly into production routers, rather than pasting it into a text editor and doing some syntax checking first, using cvs or svn for routes etc. There are enough calls for sBGP and such - but a lot can be accomplished before then simply by doing all the mom and apple pie best practice stuff (and by carrot-and-sticking other SPs into doing them, more importantly - especially any that fit the "large carrier upstream of multiple smaller ISPs with less than clued admins" type places. http://www.apnic.net/meetings/22/docs/tut-routing-pres-bgp-bcp.pdf for example. srs
Re: Operators Penalized? (was Re: Kenyan Route Hijack)
Glen Kent wrote: Do ISPs (PTA, AboveNet, etc) that "unintentionally" hijack someone else IP address space, ever get penalized in *any* form? The net only functions as a single entity because sp's intentionally DONT hijack space and the mutual trust in other sp's rational behavior. Since the sp behavior is financialy driven by user's desires, this is actually fairly easy to predict. The entire stability of the net is due to Nash Equilibrium/MAD Principle. This is an ecosystem which functions because it is in everybodies best _practical_ interest to keep it so. Punitive actions will most likely be viewed as impractical, dampened and staunched as quickly as practically possible +- human tendencies such as ego and similar. Actions that disturb equilibrium must be punitive in and of themselves, either by direct consequence or by predictable side effect and chain reaction. So yes, the penalties must already exist in sufficient form, otherwise this mailing list wouldnt. The jitter in the system is caused by the imperfections in the system, that would be the human element. The system functions because of the imperfections, not in spite of them. I cant see how any imposition of authority could ever change the dynamic, seeing as how it requires the buy in of all, in other words it would function simply as an inefficient version of what already exists. I think its worth consideration that possibly what we have now is the best it will ever be.
Re: Operators Penalized? (was Re: Kenyan Route Hijack)
Suresh Ramasubramanian wrote: On Mon, Mar 17, 2008 at 6:38 PM, Jeff Aitken <[EMAIL PROTECTED]> wrote: IMHO a better use of our time would be to solve the underlying technical issue(s). Whether it's soBGP, sBGP, or something else, we need to figure out how to make one of these proposals work and get it implemented. Start with "implement RFC 2827 yourself, and start pushing other SPs to implement it" maybe? srs RFC2827 is about source address filtering which is not really the same as BGP route announcement filtering. Unfortunately, I have not come across any RFC's with a thorough discussion of route filtering. It is mentioned briefly in RFC 3013, but section 4.5 only suggests filtering routes for private address space. RFC 4778 also mentions it, but again, there is no in depth discussion. Perhaps it is time for an RFC dedicated to route filtering practices? -Larry Blunk Merit
Re: Operators Penalized? (was Re: Kenyan Route Hijack)
On Mon, Mar 17, 2008 at 6:38 PM, Jeff Aitken <[EMAIL PROTECTED]> wrote: > IMHO a better use of our time would be to solve the underlying technical > issue(s). Whether it's soBGP, sBGP, or something else, we need to figure > out how to make one of these proposals work and get it implemented. Start with "implement RFC 2827 yourself, and start pushing other SPs to implement it" maybe? srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Operators Penalized? (was Re: Kenyan Route Hijack)
On Mon, Mar 17, 2008 at 03:48:07PM +0530, Glen Kent wrote: > Do ISPs (PTA, AboveNet, etc) that "unintentionally" hijack someone > else IP address space, ever get penalized in *any* form? Not usually. I remember an incident (while working at AboveNet, ironically) back in 98/99 where 701 "accidentally" announced some of our address space. The reason in that case was that a customer who had left 701 under questionable circumstances signed up for service with us... and 701 wanted to punish them. It got at least as far as threats of legal action before they stopped. Not sure if anyone who has more details still reads this list... rs, ser, or dlr might remember more; I don't know who was involved on the uu side of things. > So, is there anything that can be done to discourage such mishaps? Capture data and sue for damages seems to be about the only recourse now. Of course, that can be extremely difficult when you're talking about organizations on opposite sides of the planet, different jurisdictions, etc. IMHO a better use of our time would be to solve the underlying technical issue(s). Whether it's soBGP, sBGP, or something else, we need to figure out how to make one of these proposals work and get it implemented. --Jeff
Re: Operators Penalized? (was Re: Kenyan Route Hijack)
On Mon, Mar 17, 2008 at 3:48 PM, Glen Kent <[EMAIL PROTECTED]> wrote: > Do ISPs (PTA, AboveNet, etc) that "unintentionally" hijack someone > else IP address space, ever get penalized in *any* form? Depending > upon whom and what they hijack, and who all get affected, it sure can PTA's ASN actually did get disconnected for several hours by PCCW (which was leaking the youtube prefixes that PTA announced, and which shut off all of PTA's ASN rather than just filtering out the bogus announcements) Though, I am not too convinced that wasnt simply laziness at PCCW rather than a desire to punish PTA Nobody's blackholed abovenet yet that I know of. And if they did do that, they'd feel the effects real soon. --srs
Re: Kenyan Route Hijack
On Mon, Mar 17, 2008 at 01:13:04PM +0530, Suresh Ramasubramanian wrote: > anybody see similar routing loops for those other prefixes that'd make > it look like 5999 is a blackhole community at abovenet, so this dude > is seeing what ORBS saw way back when (2000, right) - that is, he had > abuse issues, was downstream of a downstream of abovenet and got his > /24 blackholed? No, 6461:5999 is definitely not a blackhole community. I'm seeing prefixes tagged 5999 that are reachable. See for example 62.80.96.0/19. The only common factors I can see with these prefixes: 1) They are all announced with an AS path of 6461. 2) A large number seem to be related to dyanmic IP internet service. Some are registered to wireless providers, some have reverse DNS that indicates there's DSL behind them. But then there's some stuff that looks to be non-ISP: 204.227.66.0/24 is registered to "Ann Taylor Stores Corp", is part of ARIN assigned 204.227.64/19. However, none of the rest of that /19 is there. Puzzling... -- Ross Vandegrift [EMAIL PROTECTED] "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
Re: Kenyan Route Hijack
On Sat, Mar 15, 2008 at 11:57:50AM -0600, Danny McPherson wrote: > An interesting bit is that the current announcement on routeviews > directly from AS 6461 has Community 6461:5999 attached: > ... > 6461 > 64.125.0.137 from 64.125.0.137 (64.125.0.137) > Origin IGP, metric 0, localpref 100, valid, external, best > Community: 6461:5999 > ... > > According to this, that community is used for "internal prefixes": > > http://onesc.net/communities/as6461/ > > "6461:5999 internal prefix" > > A "sh ip bgp community 6461:5999" currently yields 130 prefixes > with Origin AS of 6461 and that community. Hi Danny, Unless things have changed since I left in '05, 6461:5999 is the outbound community set on internally-originated prefixes. You would expect to see it on prefixes "owned" by AS6461 (such as 216.200/16) as well as address space announced on behalf of customers (i.e., prefixes "belonging" to customers who have no ASN and/or no desire to run BGP). Prefixes learned from another customer would have :5998 and those learned from a peer would have :5997, IIRC. These outbound translations are/were only performed on customer BGP sessions, which makes sense in this case since the session to route-views is/was configured like any other customer session. All it really tells you is that for whatever reason, that prefix was "manually" injected into BGP, most likely as a redist'ed static. Anyway, it's possible that this was intended due to an AUP issue but it's unlikely that they'd intentionally propagate the /24 in that case. At least when I was there, AboveNet had a separate system for injecting routes into BGP (for TE, abuse, etc) that automatically set no-export on those routes. In addition to making the process a lot less error-prone it helped contain any mistakes due to the automatic no-export. The only time you added a static route was when you WANTED to announce it. Beyond that, I have no idea why 6461 would have originated this route. My guess would be that someone who didn't understand the implications of their action added it as a static route for whatever reason, but that's nothing more than a guess. Seems like I've heard Randy voice an opinion on the local/global thing once before. :-) --Jeff
Operators Penalized? (was Re: Kenyan Route Hijack)
> > > > Usually unintentional. See Pakistan Telecom for recent example. > > Pakistan's blackhole was semi-unintentional, kind of like you tried to > shoot your spouse but the bullet went through the wall and > "unintentionally" hit a neighbor. Do ISPs (PTA, AboveNet, etc) that "unintentionally" hijack someone else IP address space, ever get penalized in *any* form? Depending upon whom and what they hijack, and who all get affected, it sure can get them lot of (undesired) publicity - news, articles, nanog discussions/presentations, ietf discussions, blogs - but, it doesnt really hurt them much, does it? AboveNet, unlike PTA, got a lot less publicity for their achievement, primarily because they didnt put millions off, from watching imbecilic videos of cats jumping the cars, and people slipping in snow - a simple google test corroborates this. While you get pages and pages of sites that talk about "PTA Youtube", you only get a handful when you do "Abovenet Africa Online". So, is there anything that can be done to discourage such mishaps? What do we do if an ISP, again accidentally, hijacks another address block or blackholes them? Would it pain them if their announcements were suppressed, or reachability (more specifically origination information) is damped for some time? I understand, this is opening up a pandora's box, because this ISP could be providing transit services to other ISPs, and this might inadvertently affect them. So, i am not suggesting a solution - i am seeking suggestions on what can be done about this? And before this, if there is anything that we as a community want to do about this? Affably, Glen
Re: Kenyan Route Hijack
On 17 Mar 2008 04:12:13 +, Paul Vixie <[EMAIL PROTECTED]> wrote: > i think, at this stage and at this date, that bringing up the ORBS/abovenet > debacle constitutes a "canard", and should be avoided, for the good of all. Completely unrelated to l'affaire ORBS of course, but in this more recent example, was uunet kenya a transit customer (or customer of a customer) of abovenet? And quoting from a previous email - An interesting bit is that the current announcement on routeviews directly from AS 6461 has Community 6461:5999 attached: ... 6461 64.125.0.137 from 64.125.0.137 (64.125.0.137) Origin IGP, metric 0, localpref 100, valid, external, best Community: 6461:5999 ... According to this, that community is used for "internal prefixes": http://onesc.net/communities/as6461/ "6461:5999 internal prefix" A "sh ip bgp community 6461:5999" currently yields 130 prefixes with Origin AS of 6461 and that community. Nothing more specific than a /24, although many many adjacent prefixes that would presumably be aggregated normally are announced as well. --- anybody see similar routing loops for those other prefixes that'd make it look like 5999 is a blackhole community at abovenet, so this dude is seeing what ORBS saw way back when (2000, right) - that is, he had abuse issues, was downstream of a downstream of abovenet and got his /24 blackholed? srs
Re: Kenyan Route Hijack
[EMAIL PROTECTED] (John Payne) writes: > > I think it was Abovenet that blackholed a /24 of (I want to say MAPS, > > but that's not right) an anti-spam-RBL sometime pre-1999? > > ORBS, and the only reason it became such a big deal was that Abovenet was > the upstream of ORBS' upstream. And that's something people still > haven't gotten over. this was a simple AUP violation, blown way out of proportion because two of abovenet's executives were also owners of MAPS. without that element, this would just have been a matter of ORBS doing forced open relay scans of the internet and especially of abovenet's other customers, and noone would have been shocked or surprised to see abovenet blackhole them, citing chapter and verse of the abovenet AUP, as well as many equivilent examples. i think, at this stage and at this date, that bringing up the ORBS/abovenet debacle constitutes a "canard", and should be avoided, for the good of all. -- Paul Vixie
Re: Kenyan Route Hijack
On March 16, 2008 at 06:25 [EMAIL PROTECTED] (Paul Ferguson) wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - -- "Glen Kent" <[EMAIL PROTECTED]> wrote: > > >If its done intentionally then it would only make sense if theres a > >DOS attack coming from that address block, or if theres something > >"blasphemous" put up there. If none of these, then why locally > >blackhole traffic? > > > > Usually unintentional. See Pakistan Telecom for recent example. Pakistan's blackhole was semi-unintentional, kind of like you tried to shoot your spouse but the bullet went through the wall and "unintentionally" hit a neighbor. -- -Barry Shein The World | [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
Re: Kenyan Route Hijack
On Mar 16, 2008, at 2:36 AM, Christopher Morrow wrote: I think it was Abovenet that blackholed a /24 of (I want to say MAPS, but that's not right) an anti-spam-RBL sometime pre-1999? ORBS, and the only reason it became such a big deal was that Abovenet was the upstream of ORBS' upstream. And that's something people still haven't gotten over.
Re: Kenyan Route Hijack
On Mon, 17 Mar 2008, Alastair Johnson wrote: Correct. A particularly interesting case, since ORBS' transit provider was also a transit customer of Above.net. Said transit provider would announce their /16s, of which ORBS sat in a /24 or two of, and have their traffic blackholed. IIRC they punched /24s via their other transit providers to partly resolve the issue. But the rest of the story - let's not go there. Why not? We _used_ to be an Above.net OC3 customer. Back around 2003, we ran into issues with Above.net deciding for us which parts of the internet should be accessible. We got customer complaints that certain web sites were unreachable through us, but worked fine on other internet services. I eventually got Above.net to give me a list of the several dozen /24's they were null routing. This was particularly annoying because they had nothing setup to notify customers of these null routes or allow us to choose not to send them traffic they'd null route. To me, this seemed rather inappropriate behavior for a transit provider. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
AW: Kenyan Route Hijack
Helo Felix, If I were you I'd ask above.net for a _very detailed_ explanation that includes a statement of their management as well as a plan how to avoid such a situation in the future. Fell free to sue them for "stealing" your prefix and disturbing your connectivity. 20 hours of outage... Whoah.. expensive! Gunther > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im > Auftrag von Felix Bako > Gesendet: Sonntag, 16. März 2008 09:05 > An: Paul Ferguson > Cc: [EMAIL PROTECTED]; nanog@merit.edu > Betreff: Re: Kenyan Route Hijack > > > Thank guyz for your Help. > Above.net finaly resolved the issue > > Regards > Felix > > >
Re: Kenyan Route Hijack
Kameron Gasso wrote: Christopher Morrow wrote: I think it was Abovenet that blackholed a /24 of (I want to say MAPS, but that's not right) an anti-spam-RBL sometime pre-1999? If I'm not mistaken, that was ORBS. Correct. A particularly interesting case, since ORBS' transit provider was also a transit customer of Above.net. Said transit provider would announce their /16s, of which ORBS sat in a /24 or two of, and have their traffic blackholed. IIRC they punched /24s via their other transit providers to partly resolve the issue. But the rest of the story - let's not go there.
Re: Kenyan Route Hijack
Christopher Morrow wrote: > I think it was Abovenet that blackholed a /24 of (I want to say MAPS, > but that's not right) an anti-spam-RBL sometime pre-1999? If I'm not mistaken, that was ORBS. > perhaps they had a significant number of complaints about the address > block and no reaction from the owner(s)? or the address block (or > hosts in it) were scanning their infrastucture, or dos'ing it or??? Such action has always been a last-ditch when I've had to deal with severe network abuse/denial of service. Doing it on routers at the network core and not just at the edge where the affected systems or customers interconnect seems pretty severe, though. > There are a whole host of reasons one might conjecture. In ALL cases > you'd never put in a /24 but a pair of /25 so that you didn't become > the best path for the rest of the internets... Even then, one would hope filters would be in place to keep it from traversing outside of their local AS, at least in a more perfect world. Of course, another recent incident disproving that theory comes to mind... -Kam
Re: Kenyan Route Hijack
Did they provide a reason for the outage? If so, please let us know what the issue was. Felix Bako wrote: Thank guyz for your Help. Above.net finaly resolved the issue Regards Felix Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- "Glen Kent" <[EMAIL PROTECTED]> wrote: If its done intentionally then it would only make sense if theres a DOS attack coming from that address block, or if theres something "blasphemous" put up there. If none of these, then why locally blackhole traffic? Usually unintentional. See Pakistan Telecom for recent example. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFH3L1Pq1pz9mNUZTMRAr9aAKDWAsFl1x92MHitc3vZ4FLF2oHXzgCg9ykS HMfSKSozgOcWVgAUOV1N8xU= =iNQ9 -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Kenyan Route Hijack
Thank guyz for your Help.
Above.net finaly resolved the issue
Regards
Felix
Paul Ferguson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -- "Glen Kent" <[EMAIL PROTECTED]> wrote:
If its done intentionally then it would only make sense if theres a
DOS attack coming from that address block, or if theres something
"blasphemous" put up there. If none of these, then why locally
blackhole traffic?
Usually unintentional. See Pakistan Telecom for recent example.
- - ferg
-BEGIN PGP SIGNATURE-
Version: PGP Desktop 9.6.3 (Build 3017)
wj8DBQFH3L1Pq1pz9mNUZTMRAr9aAKDWAsFl1x92MHitc3vZ4FLF2oHXzgCg9ykS
HMfSKSozgOcWVgAUOV1N8xU=
=iNQ9
-END PGP SIGNATURE-
--
"Fergie", a.k.a. Paul Ferguson
Engineering Architecture for the Internet
fergdawg(at)netzero.net
ferg's tech blog: http://fergdawg.blogspot.com/
--
Best Regards,
Felix Bako
Network Engineer
Africa Online, Kenya
Tel: +254 (20) 27 92 000
Fax: +254 (20) 27 100 10
Email: [EMAIL PROTECTED]
Aim:felixbako
* Africa Online Disclaimer and Confidentiality Note *
This e-mail, its attachments and any rights attaching hereto are, unless
the context clearly indicates otherwise, the property of Africa Online
Holdings (Kenya) Limited and / or its subsidiaries ("the Group"). It is
confidential and intended for the addressee only. Should you not be the
addressee and have received this e-mail by mistake, kindly notify the
sender, delete this e-mail immediately and do not disclose or use the
same in any manner whatsoever. Views and opinions expressed in this
e-mail are those of the sender unless clearly stated as those of the
Group. The Group accepts no liability whatsoever for any loss or
damages, however incurred, resulting from the use of this e-mail or its
attachments. The Group does not warrant the integrity of this e-mail,
nor that it is free of errors, viruses, interception or interference.
For more information about Africa Online, please visit our website at
http://www.africaonline.com
Re: Kenyan Route Hijack
On Sun, Mar 16, 2008 at 2:07 AM, Glen Kent <[EMAIL PROTECTED]> wrote: > > Paul, > > > > Also: I have seen instances where a static route points to a next > > hop that (inadvertently) may be "redistribute-static" injected into > > BGP. This happens occasionally due to ad hoc configurations, back- > > hole null routing, etc. > > And why would an ISP locally try to blackhole traffic bound to some > other legitimate address space? Wouldnt this result in this service I think it was Abovenet that blackholed a /24 of (I want to say MAPS, but that's not right) an anti-spam-RBL sometime pre-1999? > provider's customers to lose connectivity to whatever websites fall > behind the IP address block in question? Or is that the intention? > perhaps they had a significant number of complaints about the address block and no reaction from the owner(s)? or the address block (or hosts in it) were scanning their infrastucture, or dos'ing it or??? There are a whole host of reasons one might conjecture. In ALL cases you'd never put in a /24 but a pair of /25 so that you didn't become the best path for the rest of the internets... > If its done intentionally then it would only make sense if theres a > DOS attack coming from that address block, or if theres something dos attack mitigation works best on destinations, not sources... urpf-loose aside a filter would have solved that form of problem quicker. > "blasphemous" put up there. If none of these, then why locally > blackhole traffic? > once upon a time we had a noc person null route a 210.x.x.0/24 block because someone used their email address in the 'from' for a spam run... a swift 'discussion' ensued and they learned there was a better solution to their problem. (swift after the owners of the ip space got a little irrate :( ) -Chris
Re: Kenyan Route Hijack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- "Glen Kent" <[EMAIL PROTECTED]> wrote: >If its done intentionally then it would only make sense if theres a >DOS attack coming from that address block, or if theres something >"blasphemous" put up there. If none of these, then why locally >blackhole traffic? > Usually unintentional. See Pakistan Telecom for recent example. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFH3L1Pq1pz9mNUZTMRAr9aAKDWAsFl1x92MHitc3vZ4FLF2oHXzgCg9ykS HMfSKSozgOcWVgAUOV1N8xU= =iNQ9 -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Kenyan Route Hijack
Paul, > Also: I have seen instances where a static route points to a next > hop that (inadvertently) may be "redistribute-static" injected into > BGP. This happens occasionally due to ad hoc configurations, back- > hole null routing, etc. And why would an ISP locally try to blackhole traffic bound to some other legitimate address space? Wouldnt this result in this service provider's customers to lose connectivity to whatever websites fall behind the IP address block in question? Or is that the intention? If its done intentionally then it would only make sense if theres a DOS attack coming from that address block, or if theres something "blasphemous" put up there. If none of these, then why locally blackhole traffic? Thanks, Glen
Re: Kenyan Route Hijack
On Sat, Mar 15, 2008, Danny McPherson wrote: > > > A bit more analysis of this at the moment, and a few recommendations > and related pointers is available here: > > http://tinyurl.com/2nqg2a Its a good writeup. :) It almost sounds like Felix should talk to some friendly SP's and organise /25 origination + tunneling into various places into the US. Or is this concept reminiscent of my exposure to this world circa 1999? :) Adrian
Re: Kenyan Route Hijack
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- "Bill Stewart" <[EMAIL PROTECTED]> wrote: >I've seen two popular reasons for doing it accidentally >- Fat fingers when configuring IP addresses by hand >- Using old routing protocols such as IGRP or RIP and autosummarizing >routes, > usually done by a customer of an ISP that doesn't bother filtering > carefully. > This doesn't give you a /24 address by accident, > but it lets you take two /24 subnets of a Class B or Class A > and turn them into an advertisement for the whole network. Also: I have seen instances where a static route points to a next hop that (inadvertently) may be "redistribute-static" injected into BGP. This happens occasionally due to ad hoc configurations, back- hole null routing, etc. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFH3LBoq1pz9mNUZTMRAm8qAJwLWej/LjWQo8svLbgmOhe3kOOMCwCg7XZ/ V8/XCEkVEu0h2MAndAIpZ5g= =jQfu -END PGP SIGNATURE- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Kenyan Route Hijack
> A popular reason from longer ago was enterprises that used > arbitrary addresses for their internal networks, > which was safe because they'd never be connected to the real internet. > RFC1918 has made that problem mostly go away, > but as recently as 1995 I had a customer who was a bank that was > using University of Toronto IP addresses internally. > We were working on their databases, not their networks, > so while we strongly recommended they renumber some time soon, > it wasn't happening during our project. italian isps are notorious for using us military and other non-announced networks for infrastructure. i get a bit of a giggle out of it now. but boy was i shocked when i first did a traceroute from some public network in bologna years back. randy
Re: Kenyan Route Hijack
On Sat, Mar 15, 2008 at 9:09 PM, Glen Kent <[EMAIL PROTECTED]> wrote: > Unlike the Youtube outage where PTA had issued a directive asking all > ISPs to block Youtube - What is the reason most often cited for such > mishaps? The reason i ask this is because the ISPs that > "inadvertently" hijack someone elses IP space, need to explicitly > configure *something* to do this. So, what really are they trying to do > there? I've seen two popular reasons for doing it accidentally - Fat fingers when configuring IP addresses by hand - Using old routing protocols such as IGRP or RIP and autosummarizing routes, usually done by a customer of an ISP that doesn't bother filtering carefully. This doesn't give you a /24 address by accident, but it lets you take two /24 subnets of a Class B or Class A and turn them into an advertisement for the whole network. A popular reason from longer ago was enterprises that used arbitrary addresses for their internal networks, which was safe because they'd never be connected to the real internet. RFC1918 has made that problem mostly go away, but as recently as 1995 I had a customer who was a bank that was using University of Toronto IP addresses internally. We were working on their databases, not their networks, so while we strongly recommended they renumber some time soon, it wasn't happening during our project. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Re: Kenyan Route Hijack
Unlike the Youtube outage where PTA had issued a directive asking all ISPs to block Youtube - What is the reason most often cited for such mishaps? The reason i ask this is because the ISPs that "inadvertently" hijack someone elses IP space, need to explicitly configure *something* to do this. So, what really are they trying to do there? Thanks, Glen On Sun, Mar 16, 2008 at 1:36 AM, Danny McPherson <[EMAIL PROTECTED]> wrote: > > > A bit more analysis of this at the moment, and a few recommendations > and related pointers is available here: > > http://tinyurl.com/2nqg2a > > -danny >
Re: Kenyan Route Hijack
A bit more analysis of this at the moment, and a few recommendations and related pointers is available here: http://tinyurl.com/2nqg2a -danny
Kenyan Route Hijack
[more accurate subject line] On Mar 14, 2008, at 1:33 PM, Felix Bako wrote: Hello, There is a routing loop while accesing my network 194.9.82.0/24 from some networks on the Internet. | This is a test done from lg.above.net looking glass. 1 ten-gige-2-2.mpr2.ams2.nl.above.net (64.125.26.70) 4 msec 0 msec 0 msec 2 ten-gige-2-2.mpr1.ams2.nl.above.net (64.125.26.69) [MPLS: Label 78 Exp 0] 0 msec 0 msec 0 msec 3 ge-1-2-0.mpr1.ams1.nl.above.net (64.125.26.74) 8 msec 8 msec 0 msec 4 ten-gige-1-1.mpr1.ams2.nl.above.net (64.125.26.73) [MPLS: Label 80 Exp 0] 0 msec 4 msec 0 msec 5 ten-gige-2-2.mpr2.ams2.nl.above.net (64.125.26.70) 4 msec 0 msec 0 msec 6 ten-gige-2-2.mpr1.ams2.nl.above.net (64.125.26.69) [MPLS: Label 78 Exp 0] 0 msec 0 msec 4 msec 7 ge-1-2-0.mpr1.ams1.nl.above.net (64.125.26.74) 64 msec 0 msec 4 msec 8 ten-gige-1-1.mpr1.ams2.nl.above.net (64.125.26.73) [MPLS: Label 80 Exp 0] 0 msec 4 msec 0 msec 9 ten-gige-2-2.mpr2.ams2.nl.above.net (64.125.26.70) 4 msec 0 msec 0 msec 10 ten-gige-2-2.mpr1.ams2.nl.above.net (64.125.26.69) [MPLS: Label 78 Exp 0] 0 msec 4 msec 0 msec 11 ge-1-2-0.mpr1.ams1.nl.above.net (64.125.26.74) 4 msec 0 msec 4 msec| According to RIPE BGP play data looks to me like AS 6461 (Abovenet) began announcing 194.9.82.0/24 about 10 hours ago, pulling traffic away from AS 39615 and triggering your reachability problems (Note times are UTC): # 1/361 2008-03-15 03:05:27 Path Change from 29636 6461 2914 8513 25228 36915 rrc01 195.66.224.132 to 29636 2914 6461 # 2/361 2008-03-15 03:05:27 Route Announcement 20485 2914 6461 rrc01 195.66.224.212 About 17 minutes later AS 6461 they withdrew the route announcement: # 41/361 2008-03-15 03:22:56 Route Withdrawal ( 4777 2497 2914 6461 ) rrc06 202.249.2.20 And another 12 minutes or so later they began announcing it again: # 42/361 2008-03-15 03:35:26 Path Change from 29636 6461 2914 8513 25228 36915 rrc01 195.66.224.132 to 29636 2914 6461 ... Seemed to be a bunch more instability with this prefix around 5:53: # 66/361 2008-03-15 05:53:40 Route Announcement 25462 6461 rrc07 194.68.123.157 ... And then some withdraws around 7:43: # 183/361 2008-03-15 07:43:48 Path Change from 8468 6453 6461 rrc01 195.66.224.151 to 8468 3491 25228 25228 25228 25228 25228 36915 ... With considerable oscillation for around 40 minutes between the legit path via AS 36915 and the path via AS 6461. And the latest was this transition from AS 6461 back to the 36915 path about 2 hours ago, but only by a few ASNs, I suspect because those ASNs explicitly modified policy (either preference or filtering) to de_prefer the AS 6461 path. This is illustrated pretty nicely with BGP play: # 335/361 2008-03-15 14:59:43 Route Withdrawal ( 1916 3549 6461 ) rrc15 200.219.130.4 # 361/361 2008-03-15 15:00:27 Path Change from 13645 3356 6461 rrc11 198.32.160.150 to 13645 3491 25228 25228 25228 25228 25228 36915 BGP Play applet here: http://www.ris.ripe.net/bgplay/applet.html? Although most folks are definitely still preferring the AS 6461 path. An interesting bit is that the current announcement on routeviews directly from AS 6461 has Community 6461:5999 attached: ... 6461 64.125.0.137 from 64.125.0.137 (64.125.0.137) Origin IGP, metric 0, localpref 100, valid, external, best Community: 6461:5999 ... According to this, that community is used for "internal prefixes": http://onesc.net/communities/as6461/ "6461:5999 internal prefix" A "sh ip bgp community 6461:5999" currently yields 130 prefixes with Origin AS of 6461 and that community. Nothing more specific than a /24, although many many adjacent prefixes that would presumably be aggregated normally are announced as well. The closest adjacent prefix to 194.9.82/24 they're announcing is 194.9.40/24, which is one of their prefixes: *> 194.9.40.0 64.125.0.137 0 0 6461 i *> 194.9.82.0 64.125.0.137 0 0 6461 i Unfortunately, the AS6461 forwarding loops still exists, and most ASNs still appear to be preferring their path over yours per BGP AS path route selection rules: --- [EMAIL PROTECTED] date Sat Mar 15 11:55:27 MDT 2008 ... 14 ge-1-2-0.mpr1.ams1.nl.above.net (64.125.26.74) 188.278 ms 172.714 ms 174.984 ms 15 ten-gige-1-1.mpr1.ams2.nl.above.net (64.125.26.73) 176.234 ms 174.013 ms 174.109 ms 16 ten-gige-2-2.mpr2.ams2.nl.above.net (64.125.26.70) 173.230 ms 172.892 ms 174.765 ms 17 ten-gige-2-2.mpr1.ams2.nl.above.net (64.125.26.69) 174.721 ms 175.256 ms 174.738 ms 18 ge-1-2-0.mpr1.ams1.nl.above.net (64.125.26.74) 174.437 ms 220.815 ms 180.961 ms 19 ten-gige-1-1.mpr1.ams2.nl.above.net (64.125.26.73) 177.564 ms 181.966 ms 174.771 ms 20 ten-gige-2-2.mpr2.ams2.nl.above.net (64.125.26.70) 176.028 ms 174
