Mailing List Archive: NANOG: users

Kenyan Route Hijack

Index | Next | Previous | View Threaded

danny at tcb

Mar 15, 2008, 10:57 AM

Post #1 of 22 (1816 views)
Permalink

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:

---
danny[at]pork% 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.269 ms 174.365 ms
21 ten-gige-2-2.mpr1.ams2.nl.above.net (64.125.26.69) 175.626 ms
175.381 ms 175.831 ms
22 ge-1-2-0.mpr1.ams1.nl.above.net (64.125.26.74) 174.046 ms
174.841 ms 174.388 ms
23 ten-gige-1-1.mpr1.ams2.nl.above.net (64.125.26.73) 174.861 ms
174.857 ms 175.475 ms
...

My recommendation, stay on the phone with Abovenet (via your
upstream, and their upstream if necessary) until you see a withdraw
for the route on routeviews from AS 6461:

telnet route-views.routeviews.org
sh ip bgp 194.9.82.0/24

-danny

danny at tcb

Mar 15, 2008, 1:06 PM

Post #2 of 22 (1744 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

A bit more analysis of this at the moment, and a few recommendations
and related pointers is available here:

http://tinyurl.com/2nqg2a

-danny

glen.kent at gmail

Mar 15, 2008, 9:09 PM

Post #3 of 22 (1741 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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 <danny[at]tcb.net> 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
>

nonobvious at gmail

Mar 15, 2008, 10:13 PM

Post #4 of 22 (1741 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

On Sat, Mar 15, 2008 at 9:09 PM, Glen Kent <glen.kent[at]gmail.com> 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.

randy at psg

Mar 15, 2008, 10:26 PM

Post #5 of 22 (1740 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

> 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

fergdawg at netzero

Mar 15, 2008, 10:30 PM

Post #6 of 22 (1738 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -- "Bill Stewart" <nonobvious[at]gmail.com> 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/

adrian at creative

Mar 15, 2008, 10:53 PM

Post #7 of 22 (1744 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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

glen.kent at gmail

Mar 15, 2008, 11:07 PM

Post #8 of 22 (1741 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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

fergdawg at netzero

Mar 15, 2008, 11:25 PM

Post #9 of 22 (1740 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -- "Glen Kent" <glen.kent[at]gmail.com> 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/

morrowc.lists at gmail

Mar 15, 2008, 11:36 PM

Post #10 of 22 (1738 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

On Sun, Mar 16, 2008 at 2:07 AM, Glen Kent <glen.kent[at]gmail.com> 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

fbako at africaonline

Mar 16, 2008, 1:05 AM

Post #11 of 22 (1738 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

Thank guyz for your Help.
Above.net finaly resolved the issue

Regards
Felix

Paul Ferguson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - -- "Glen Kent" <glen.kent[at]gmail.com> 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: fbako[at]africaonline.co.ke
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

matt at credibleinstitution

Mar 16, 2008, 2:41 AM

Post #12 of 22 (1726 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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" <glen.kent[at]gmail.com> 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/
>>
>>
>>
>>
>
>

kgasso-lists at visp

Mar 16, 2008, 3:42 AM

Post #13 of 22 (1729 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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

aj at sneep

Mar 16, 2008, 4:49 AM

Post #14 of 22 (1729 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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.

gstammw at gmx

Mar 16, 2008, 5:53 AM

Post #15 of 22 (1726 views)
Permalink

AW: Kenyan Route Hijack [In reply to]

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: owner-nanog[at]merit.edu [mailto:owner-nanog[at]merit.edu] Im
> Auftrag von Felix Bako
> Gesendet: Sonntag, 16. M�rz 2008 09:05
> An: Paul Ferguson
> Cc: glen.kent[at]gmail.com; nanog[at]merit.edu
> Betreff: Re: Kenyan Route Hijack
>
>
> Thank guyz for your Help.
> Above.net finaly resolved the issue
>
> Regards
> Felix
>
>
>

jlewis at lewis

Mar 16, 2008, 7:50 AM

Post #16 of 22 (1726 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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_________

john at sackheads

Mar 16, 2008, 4:32 PM

Post #17 of 22 (1725 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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.

bzs at world

Mar 16, 2008, 8:04 PM

Post #18 of 22 (1722 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

On March 16, 2008 at 06:25 fergdawg[at]netzero.net (Paul Ferguson) wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - -- "Glen Kent" <glen.kent[at]gmail.com> 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 | bzs[at]TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide
Software Tool & Die | Public Access Internet | SINCE 1989 *oo*

vixie at isc

Mar 16, 2008, 9:12 PM

Post #19 of 22 (1722 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

john[at]sackheads.org (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

ops.lists at gmail

Mar 17, 2008, 12:43 AM

Post #20 of 22 (1722 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

On 17 Mar 2008 04:12:13 +0000, Paul Vixie <vixie[at]isc.org> 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

ross at kallisti

Mar 17, 2008, 5:25 AM

Post #21 of 22 (1710 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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
ross[at]kallisti.us

"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

jaitken at aitken

Mar 17, 2008, 5:25 AM

Post #22 of 22 (1710 views)
Permalink

Re: Kenyan Route Hijack [In reply to]

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com