Large number of IPv6 bogons with spoofed ASpath

[Andree Toonk]

Hi List

Yesterday I noticed a large number of 'bogon' IPv6 announcement.
I think it was about a 100 different (IPv6) bogon prefixes [1] [2] being 
announced from a what looks a variety of origin ASns.


Being the administrator of one of these ASns, I'm quite confident that 
we were not actually announcing this prefix (f006:9000::/24).


Looking more carefully at the data. it looks like the Origin AS / 
ASpaths are spoofed. I suspect it's just one person/organization 
somewhere in  AS174 or AS3257 network which is announcing these bogons 
prepending it with different ASns.


Does anyone have an idea what this could be? Someone doing some kind of 
an experiment?


I summarized my observations here: http://bgpmon.net/blog/?p=299

If anyone has more info about this, please let me know as I am 
interested to learn more about this.


Thanks,
 Andree

[1] http://www.bgpmon.net/showbogons.php?inet=6
[2] http://bit.ly/cH1INE

Re: wikileaks unreachable

[Andree Toonk]

Seems like they moved to Amazon a few hours ago:

$ whois -h whois.bgpmon.net wikileaks.org

Prefix:  46.51.128.0/18
Prefix description:  Amazon EU AWS Dublin
Country code:IE
Origin AS:   39111
Origin AS Name:  ADSI-AS Amazon EU DC AS


.-- My secret spy satellite informs me that at 10-11-28 2:07 PM  Jeffrey 
Lyon wrote:

I wouldn't have thought that PRQ would have any significant protection in place.

Jeff


On Sun, Nov 28, 2010 at 5:03 PM, William Pitcock
neno...@systeminplace.net  wrote:

On Sun, 2010-11-28 at 16:43 -0500, Jeffrey Lyon wrote:

I'm surprised it took this long for the DDoS train to pull into the station.


Wikileaks gets DDoSed all the time.  My understanding is that PRQ
nullrouted the IP because the DDoS is much larger this time.

William

Re: Connectivity status for Egypt

[Andree Toonk]

Hi,

Looking at the BGP announcements it seems that the problem started at 
around 22:28 UTC.


Most of the Autonomous systems operating in Egypt are currently not 
announcing any or at least significantly less prefixes.

The one exception seems to be AS20928 (Noor Data Networks).

For more details also see: http://bgpmon.net/blog/?p=450

Cheers,
 Andree


.-- My secret spy satellite informs me that at 11-01-27 3:47 PM  Danny 
O'Brien wrote:

Around 2236 UCT, we lost all Internet connectivity with our contacts in
Egypt, and I'm hearing reports of (in declining order of confirmability):

1) Internet connectivity loss on major (broadband) ISPs
2) No SMS
4) Intermittent connectivity with smaller (dialup?) ISPs
5) No mobile service in major cities -- Cairo, Alexandria

The working assumption here is that the Egyptian government has made the
decision to shut down all external, and perhaps internal electronic
communication as a reaction to the ongoing protests in that country.

If anyone can provide more details as to what they're seeing, the extent,
plus times and dates, it would be very useful. In moments like this there
are often many unconfirmed rumors: I'm seeking concrete reliable
confirmation which I can pass onto the press and those working to bring some
communications back up (if you have a ham radio license, there is some very
early work to provide emergency connectivity. Info at:
http://pastebin.com/fHHBqZ7Q )

Thank you,

Re: Level 3's IRR Database

[Andree Toonk]

.-- My secret spy satellite informs me that at 11-01-30 1:22 PM  Randy 
Bush wrote:

So, what are peoples' routing policies on RPKI going to be?  Are people
going to drop prefixes with no RPKI record?  Or drop prefixes with an
incorrect RPKI record?  Or drop prefixes with a revoked status?


draft-ietf-sidr-rpki-origin-ops-04.txt


Question,
Based on this draft the recommended preference order is:

1) Validation ok
2) not found
3) Validation nok

Suppose an operator would use local-pref to achieve this.
This intention (preferring validated routes) will break, when there's a 
more specific announcement that doesn't validate.

For example the youtube incident would not have been stopped by doing this.

Are there any suggestions or recommendations for how to handle these cases?

Cheers,
 Andree

Re: Level 3's IRR Database

[Andree Toonk]

Hi Randy,

.-- My secret spy satellite informs me that at 11-01-30 11:18 PM  Randy 
Bush wrote:



so i am not sure what your point is.  please clarify with a concrete
example.


Adjusting a route's degree of preference in the selection algorithm 
based on its validation state only works if it's exactly the same prefix.


Jack already sort of explained what I meant, but here's an example

Assume that youtube's prefix had a roa like this
Origin ASN: AS36561
Prefixes:   208.65.152.0/22

Now AS17557 start to announce a more specific: 208.65.153.0/24. 
Validators would classify this as Invalid (2).
If we would only use local-prefs, routers would still choose to send it 
to AS17557 (Pakistan Telecom) as it's a more specific.


So in cases where the invalid announcement is a more specific, the only 
way to prevent 'hijacks' is to actually drop these 'invalid' 
announcement from day one.


I understand this is by design, but I can imagine some operators will be 
reluctant to actually drop routes when they start testing RPKI 
deployments in their networks.


Cheers,
 Andree

Re: Level 3's IRR Database

[Andree Toonk]

.-- My secret spy satellite informs me that at 11-01-31 12:11 PM 
Christopher Morrow wrote:



I understand this is by design, but I can imagine some operators will be
reluctant to actually drop routes when they start testing RPKI deployments
in their networks.


yes, but what is the way forward?


Not sure, that was my original question:
Are there any suggestions or recommendations for how to handle these cases?

Re: Connectivity status for Egypt

[Andree Toonk]

Hi Danny,

.-- My secret spy satellite informs me that at 11-01-31 2:41 PM  Danny 
O'Brien wrote:



Does anyone has a list of routes that are still up, and seem to correlate
with Egyptian locations? Andree's last list is here:
http://bgpmon.net/egypt-routes-jan29-2011.txt


Here's an updated list:
http://www.bgpmon.net/egypt-routes-jan31-2011.txt

Also see: http://bgpmon.net/blog/?p=450#lastupdate

Cheers,
 Andree

Re: Dreamhost hijacking my prefix...

[Andree Toonk]

Hi,
Here's a quick summary of what we saw at BGPMon.net.

At 2013-01-11 14:14:13 we saw announcements (seemingly) originated by
26347, for prefixes normally announced by other ASn's (origin change /
hijack).

This seems to have affected 112 prefixes for 110 ASn's [1], including
Rogers, Tata, Sprint, Ziggo, Verizon, KPN, Vodafone, CloudFlare, XS4ALL,
ATT, Bell Canada and many more.
Most of these were new more specific(!) announcements.

With regards to next-hop ASN's (peers). It seems this hijack was
propagated via 12 unique (AS26347) peers [1]

A quick look at the prefix that was mentioned by Jeff, 150.182.208.0/20
(more specific of 50.182.192.0/18)
The first announcement for this prefix was seen at 2013-01-11 14:14:28
and withdrawn at 2013-01-11 15:20:57.  It was detected by 42 unique peers.

some example paths:
271 6939 26347
5580 26347|
37312 5713 6939 26347
1126 24785 12989 26347

[1] I've posted some details  (Unique next-hop ASN's and affected origin
ASN's), check if your AS was affected here:
http://portal.bgpmon.net/data/hijack20130111.txt

Cheers,
 Andree




.-- My secret spy satellite informs me that at 2013-01-11 7:23 AM  Jeff
Kell wrote:
 Not sure how widespread their leakage may be, but Dreamhost just
 hijacked one of my prefixes...
 
 
 Possible Prefix Hijack (Code: 10)
 
 Your prefix:  150.182.192.0/18: 
 Update time:  2013-01-11 14:14 (UTC)
 Detected by #peers:   11
 Detected prefix:  150.182.208.0/20 
 Announced by: AS26347 (DREAMHOST-AS - New Dream Network, LLC)
 Upstream AS:  AS42861 (PRIME-LINE-AS JSC Prime-Line)
 ASpath:   8331 42861 42861 42861 26347 
 
 Anyone have a contact there?  ASinfo gives net...@dreamhost.com where I
 have submitted a report, but so far no joy...
 
 Jeff
 
 
 

Re: Dreamhost hijacking my prefix...

[Andree Toonk]

Hi Kenneth,

.-- My secret spy satellite informs me that at 2013-01-11 8:54 AM
Kenneth McRae wrote:
 Thanks for that info Andree.  The only valid peer I see on the list
 would be HE.  We do not peer with any of the others listed.

Could it be these ASns receive your routes via an IX route-server?

Below some examples that show a peering between 26347 and
5580 as well as 12989

5580 26347
http://www.ris.ripe.net/cgi-bin/lg/index.cgi?rrc=RRC031query=12arg=5580+26347

12989 26347:
http://www.ris.ripe.net/cgi-bin/lg/index.cgi?rrc=RRC031query=12arg=12989+26347

And route views:

route-viewssh ip bgp regex 12989_26347
BGP table version is 427410275, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid,  best, i -
internal,
  r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network  Next HopMetric LocPrf Weight Path
*  64.111.96.0/19   208.74.64.40   0 19214 12989
26347 i
*  66.33.192.0/19   208.74.64.40   0 19214 12989
26347 i
*  67.205.0.0/18208.74.64.40   0 19214 12989
26347 i
*  69.163.128.0/17  208.74.64.40   0 19214 12989
26347 i
*  75.119.192.0/19  208.74.64.40   0 19214 12989
26347 i
*  173.236.128.0/17 208.74.64.40   0 19214 12989
26347 i
*  205.196.208.0/20 208.74.64.40   0 19214 12989
26347 i
*  208.97.128.0/18  208.74.64.40   0 19214 12989
26347 i
*  208.113.128.0/17 208.74.64.40   0 19214 12989
26347 i
*  208.113.200.0208.74.64.40   0 19214 12989
26347 i



Cheers,
 Andree

Re: Dreamhost hijacking my prefix...

[Andree Toonk]

.-- My secret spy satellite informs me that at 2013-01-11 10:44 AM
Kenneth McRae wrote:
 Yes, now that is possible (just no direct peering).  So that takes me
 back to my original statement about not announcing the 150.182.208.0/20
 http://150.182.208.0/20 prefix to begin with.

Here's some more data showing an announcement for
150.182.208.0/20 originated by 26347

http://www.ris.ripe.net/mt/rissearch-result.html?aspref=150.182.208.0%2F20preftype=EMATCHrrc_id=1000peer=ALLstartday=20130111starthour=00startmin=00startsec=00endday=20130111endhour=19endmin=16endsec=26outype=htmlsubmit=Search.submit=type

I can send you more data if you need it.
Just contact me off-list.

Cheers,
 Andree

Re: Dreamhost/AS26347 unauthorized bgp announcement

[Andree Toonk]

.-- My secret spy satellite informs me that at 2013-03-06 12:59 AM
Matsuzaki Yoshinobu wrote:
 According to RIPE RIS, AS26347 announced a bunch of prefixes again.
  - http://www.ris.ripe.net/dashboard/26347
 
 First suspicious announcement was started 2013-03-06 07:52:40 UTC, and
 last seen 2013-03-06 08:33:56 UTC.  195 prefixes total.
 
 It seems these unauthorized announcements have the same profile as
 before - AS26347 shrinks the prefix lenght of their received prefix
 somehow upto /20, and re-originates the prefix with origin AS26347.
 
 Any known bugs?


Sounds indeed like an exact copy of the incident on January 11:
http://seclists.org/nanog/2013/Jan/243

That time the prefixes seem to also have been learned via a route-server
in LA.

The strange thing is that the majority of the 'hijacked' prefixes (today
and in January) are new more specifics (not seen before).
(Using some kind of BGP route optimizer?).

This time it affected 203 unique prefixes and 133 ASns.
Below a list of some of the affected ASns

20115 Charter Telecom.
4837  China Unicom
8151  UNINET Mexico
11427 Roadrunner
42961 MTC GPRS  Kuwait
7303  Telecom Argentina S.A.
25135 Vodafone
7018  ATT
6389  BellSouth.net
8220  Colt
19262 Verizon
9143  ZIGGO
6830  UPC
5089  Virgin Media


Cheers,
 Andree

Re: IXP BGP timers (was: Multi-homed clients and BGP timers)

[Andree Toonk]

Hi Chris,

.-- My secret spy satellite informs me that at Mon, 25 May 2009, Chris Caputo 
wrote:

 Would going below 60-180 without first discussing it with your peers, tend 
 to piss them off?

60-180 is fairly conservative. 60-180 is the Cisco default I believe, however
Junipers defaults are 30-90. I never pissed anyone off with that ;)

Cheers,
 Andree

Re: Route table prefix monitoring

[Andree Toonk]

Hi Jason, 

.-- My secret spy satellite informs me that at Fri, 04 Sep 2009, Olsen, Jason 
wrote:

 What I'm left thinking is that it would have been great if we'd had a
 snapshot of our core routing table as it stood hours or even days prior
 to this event occurring, so that I could compare it with our current
 broken state, so the team could have seen that subnet in the core
 table and what the next hop was for the prefix.  Are there any tools
 that people are using to track when/what prefixes are added/withdrawn
 from their routing tables, or to pull the routing table as a whole at
 regular intervals for storage/comparison purposes?  

As already mentioned BGPmon.net can probably do what you're looking for. 
It will sent you a notification in cases of interesting path changes, possible 
hijacks, 
new adjacencies and new prefixes.  It will also notify you when 'many' peers 
see a
withdrawal of your prefix. This last feature might be useful for you.

I'm currently also testing a new feature that basically compares yesterday's 
routing 
table with todays table. If there are any 'interesting' changes they will be 
emailed to you.
You can think of this as a rancid for routing tables changes. 
I can include you in testing if you want to.

All of this does assume that your prefixes are globally visible though.

Cheers,
 Andree

Re: Anyone seeing BGP weirdness?

[Andree Toonk]

Hi Eric,

.-- My secret spy satellite informs me that at Thu, 08 Oct 2009, Eric Gearhart 
wrote:

 Is anyone else seeing general routing weirdness on the Internets, or at
 least can someone point me at a good BGP dashboard site that monitors the
 state of routing tables at various places?

I have not seen 'weirdness'.
You can check: http://www.ripe.net/ris/index.html
or telnet to route-views.routeviews.org and verify if there's anything strange
going on with your prefixes.

Also, http://BGPmon.net might be useful for you in this case. It will monitor 
your prefixes
from several detectors all over the world. 
Alarm / Notification messages will be sent to you in case of suspicious
announcements or instability.

Hope that helps.

Cheers
 Andree

Re: BGP noob needs monitoring advice

[Andree Toonk]

Hi,

.-- My secret spy satellite informs me that at 11-12-20 11:16 AM  Bret 
Clark wrote:

Is http://cyclops.cs.ucla.edu/ still working? I don't seem to received
emails from them anymore when we stop announcing to one of our upstream
providers. On the other hand http://bgpmon.net/ does send me emails when
an announcement disappears from an upstream, although it's usually a day
later.


Just to clarify this:
For all alert types below BGPmon.net sends out an alert within minutes:
1) prefix withdrawal (prefix disappeared)
2) new upstream
3) new prefix
4) origin AS changes
5) ASpath regex failure
6) policy violation
7) RPKI validation failure

There's one other feature, the routing-report feature, that runs only 
once a day. It's similar as the cidr report, but specific to your AS. I 
like to refer to it as a rancid for your BGP announcements.


It's basically a diff between how your routes were visible today and 
yesterday. This specific feature will also notify the user if you lost / 
gained one or more upstreams per prefix.
Also see http://bgpmon.net/blog/?p=257 for more information about that 
specific feature.


Cheers,
 Andree

Re: BGP noob needs monitoring advice

[Andree Toonk]

Hi Vinny,

.-- My secret spy satellite informs me that at 11-12-21 5:17 AM  Vinny 
Abello wrote:



Unless I'm misunderstanding something, I'm concerned regarding the IPv4 bogon 
list on http://bgpmon.net/showbogons.php?inet=4 . It clearly includes several 
/8's that should not be there. The data seems to be stale as if some job is no 
longer pulling the updated data. It states it's being pulled from 
http://www.cymru.com/Documents/bogon-bn-nonagg.txt , but that clearly does not 
contain 100/8, 5/8, 181/8, 49/8 and a few others... and hasn't for quite some 
time.


The http://bgpmon.net/showbogons.php?inet=4  page show a list of bogons 
that were announced at a certain point in time, so the page show 
historical announcements as well (check the date).


For example the last 100/8 bogons were detected on 2010-10-29, at that 
time it was still considered a bogon.


The list is not stale, there's just very few IPv4 bogons left :)
We do still see RFC1918 announcements:
http://www.bgpmon.net/showbogons.php?inet=4global=yesprivate=yes

And of course IPv6 bogons, Last month for example: 18c::/16
http://www.bgpmon.net/showbogons.php?global=yesprivate=yesinet=6

Cheers,
 Andree

Re: BGPmon regex

[Andree Toonk]

Hi Christopher,

.-- My secret spy satellite informs me that at 11-12-21 9:06 AM 
Christopher J. Pilkington wrote:

I'm trying to edit my prefixes' AS path regex in BGPmon, and when I add a
'\s' in the Regular expression field, upon save, the '\' is stripped.

Is this expected behavior?

The workaround is to insert a '\\s' instead, but one needs to remember to
do this on every edit, and I tend to forget which results in panicking the
others on our team with false positives.


I believe this should be fixed now, please try again.
Contact me directly (andree at bgpmon.net) if the problem persists or if 
you have any other bgpmon.net questions.


Alternatively, as a replacement for \s you can also just use a white space
for example: (6327|13768|852) 271$

Cheers,
 Andree

Re: BBC reports Kenya fiber break

[Andree Toonk]

Hi Georgios,

.-- My secret spy satellite informs me that at 12-03-01 1:11 AM
Georgios Theodoridis wrote:
 Has it been known the exact time of the incident?
 I have found an article reporting that the cut occurred in the mid-day
 of Saturday 25th but nothing more precise.
 We would like to use such information for a BGP anomaly detection
 analysis that we are carrying out in our research centre.

Looking at BGP data we can see large outages for both Kenya and Uganda
starting at around 9:12 UTC on February the 25th.

Also see:
http://www.bgpmon.net/africa-feb25.png

Cheers,
 Andree

Re: Hearing Syria internet cut

[Andree Toonk]

.-- My secret spy satellite informs me that at 12-07-19 10:00 PM  George
Bonser wrote:
 Can anyone confirm? 

Yes confirmed, about 90% of the Syrian prefixes disappeared from the BGP
tables between 13:32 and 14:13 (UTC) earlier today (2012-07-19).

Cheers,
 Andree

Re: Bell Canada outage?

[Andree Toonk]

Hi,

.-- My secret spy satellite informs me that at 12-08-08 11:35 AM  Darius
Jahandarie wrote:
 On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon
 zachary.mcgibbon+na...@gmail.com wrote:
 Anyone at Bell Canada / Sympatico can tell us what's going on?  Our routing
 table is going nuts with Bell advertising a lot of routes they shouldn't be
 
 Bell leaked a full table. To add to the fun, it seems that TATA took
 the full table and releaked it.

A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the
cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems
to have happened is that they leaked routes learned from VIDEOTRON to Bell.

Based on BGP data I see that at 17:27 UTC  AS46618 ( Dery Telecom Inc)
started to leak a 'full table', or at least a significant chunk of it to
its provider Bell AS577.
Bell propagated that to it's peers. Tata was one of the ones that
accepted all of that.

I can see that Bell propagated at least 74,109 prefixes learned from
AS46618 to Tata. Tata selected 70,160 of those routes.


Cheers,
 Andree

Re: Bell Canada outage?

[Andree Toonk]

Further analysis shows that there were actually 107,409 prefixes
affected of 14,391 unique origin ASn's.

Interested if your prefixes was affected?
I've uploaded a list of prefixes and ASn's that were leaked here:
http://www.bgpmon.net/bell-leak.txt

Cheers,
 Andree



.-- My secret spy satellite informs me that at 12-08-08 12:50 PM  Andree
Toonk wrote:
 Hi,
 
 .-- My secret spy satellite informs me that at 12-08-08 11:35 AM  Darius
 Jahandarie wrote:
 On Wed, Aug 8, 2012 at 2:31 PM, Zachary McGibbon
 zachary.mcgibbon+na...@gmail.com wrote:
 Anyone at Bell Canada / Sympatico can tell us what's going on?  Our routing
 table is going nuts with Bell advertising a lot of routes they shouldn't be

 Bell leaked a full table. To add to the fun, it seems that TATA took
 the full table and releaked it.
 
 A quick analysis leads met to believe AS46618 ( Dery Telecom Inc) is the
 cause of this. AS46618 is dual homed to VIDEOTRON and Bell. What seems
 to have happened is that they leaked routes learned from VIDEOTRON to Bell.
 
 Based on BGP data I see that at 17:27 UTC  AS46618 ( Dery Telecom Inc)
 started to leak a 'full table', or at least a significant chunk of it to
 its provider Bell AS577.
 Bell propagated that to it's peers. Tata was one of the ones that
 accepted all of that.
 
 I can see that Bell propagated at least 74,109 prefixes learned from
 AS46618 to Tata. Tata selected 70,160 of those routes.
 
 
 Cheers,
  Andree
 
 
 
 
 
 
 

Re: Prefix Hijack Tool Comaprision

[Andree Toonk]

Hi all,

.-- My secret spy satellite informs me that at Thu, 13 Nov 2008, Todd Underwood 
wrote:

  that's why i recommend that prefix hijacking detection systems do 
 thresholding of
 peers to prevent a single, rogue, unrepresentative peer from reporting
 a hijacking when none is really happening.  others may have a
 different approach, but without thresholding prefix alert systems can
 be noisy and more trouble than they are worth.

For those who like to use a peer threshold, BGPmon.net now has minimum peer
threshold support.
For more information see:  http://bgpmon.net/blog/?p=88

Cheers,
 Andree

Re: Lots of prepends - AS20912 case

[Andree Toonk]

Hi,

.-- My secret spy satellite informs me that at Fri, 20 Feb 2009, Giuliano 
Peritore wrote:
 I think that the case of AS47868 is the same, because I seed the 
 modulo was involved too.

For those interested, I made an overview of longest AS paths observed per day, 
starting with February 1st.

I added a feature that checks if number of prepends matches the low-order 8 
bits of the offending AS number. 
Indicating that it's likely caused by the same Mikrotik bug/feature.

The list can be found here:
http://bgpmon.net/maxASpath.php

Interesting is that the first time this was observed was actually on February
9th (251 prepends by AS45307). Apparently the impact was not as widespread as
this week. 

Cheers,
 Andree

Re: Is it time to abandon bogon prefix filters?

[Andree Toonk]

Hi Randy,

.-- My secret spy satellite informs me that at Thu, 07 Aug 2008, Randy Bush 
wrote:

 serious curiosity:
 
 what is the proportion of bad stuff coming from unallocated space vs
 allocated space?  real measurements, please.  and are there longitudinal
 data on this?
 
 are the uw folk, gatech, vern, ... measuring?

I did some measurements in The Netherlands (SURFnet) using netflow around 1,5
years ago.  During this project around 86 million 'Bogon flows' were analyzed. 
This was not
more then 0.1% (probably even lower) of all flows during that 1 week period.
The majority of these flows were actually from/to RFC1918 address space.

One of the things (amongst others)  we looked at was SMTP traffic from / to
bogons, to verify the theory that spammers announce a bogon prefix to sent 
spam. From the 86
million bogon flows analyzed, 12 SMTP flows were found, very minimal.
Other things we looked at, were type of traffic (applications)  protocols  and
the sources of those flows.
We saw some strange (interesting) things, but that was really just a few flows
in many many many milions of flows.

Anyways, if you're interested the research report can be found here:
http://www.toonk.nl/bogon-traffic-analysis.pdf
There's also a presentation http://www.toonk.nl/presentations.php

Cheers,
 Andree

--
 Andree Toonk
 http://www.toonk.ca/blog/

Re: prefix hijack by ASN 8997

[Andree Toonk]

Hi,

.-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank 
Nussbacher wrote:

 I too spotted this via PHAS for a large number of prefixes, but have not  
 received alerts from IAR, Watchmy.Net nor does RIPE RIS show this hijack: 
 http://www.ris.ripe.net/perl-risapp/risearch.html I would have expected  
 with so many RRC boxes that RIPE RIS would have caught it.  I had thought 
 it was a false positive from PHAS but now that you and others have seen 
 it - I guess it is for real.

Not a false positive, It actually was detected by the RIS box in Moscow 
(rrc13). Strange that it's not visible in RIS search website, but it's 
definitely in the raw data files.
Looking at that raw data from both routeviews and Ripe, it looks like they 
(AS8997) 'leaked' a  full table,  i.e. :
* 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 
3267 8997)  
* 250495 seen by routeviews (ASpath: 2895 3267 8997).
(results of quick query: where AS-path contained '3267 8997' update type = 
advertisement).

I'm using another prefix monitoring tool and within a few minutes it notified 
me of this hijack for some of our prefixes:


Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin 
AS changed)
detected 1 updates for your prefix 128.189.0.0/16 AS271:
Update details: 2008-09-22 09:33 (UTC)
128.189.0.0/16
Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System),
Transit AS: AS3267 (RUNNET RUNNet)
ASpath: 2895 3267 8997

Prefix Hijack ( Code 11: Origin AS and Prefix changed (more specific) Or Origin 
AS changed)
detected 1 updates for your prefix 142.231.0.0/16 AS271:
Update details: 2008-09-22 09:34 (UTC)
142.231.0.0/16
Announced by: AS8997 (ASN-SPBNIT OJSC North-West Telecom Autonomous System),
Transit AS: AS3267 (RUNNET RUNNet)
ASpath: 2895 3267 8997

/

Cheers,
 Andree

Re: prefix hijack by ASN 8997

[Andree Toonk]

Hi Hank,

.-- My secret spy satellite informs me that at Tue, 23 Sep 2008, Hank 
Nussbacher wrote:

 Looking at that raw data from both routeviews and Ripe, it looks like they 
 (AS8997) 'leaked' a  full table,  i.e. :
 * 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 
 3267 8997)
 * 250495 seen by routeviews (ASpath: 2895 3267 8997).
 (results of quick query: where AS-path contained '3267 8997' update type = 
 advertisement).

 ASpath: 2895 3267 8997

 Is that the only ASpath that leaked it?  There are others - did they  
 filter properly and only that path failed to filter?

Again:
* 217.208 unique prefixes detected by the RIS server in Moscow (ASpath: 2895 
3267 8997  ASpath 2895 5431 3267 8997)
* 250495 seen by routeviews (ASpath: 3277 3267 8997).

Looks like those are the only ones, but this is just a quick egrep, awk, and 
sort on the rawdata so I might have missed something (It's getting late here, 
so no guarantees ;))

Cheers,
 Andree

Re: IP to authoritative CIDR webservices

[Andree Toonk]

Hi William,

.-- My secret spy satellite informs me that at Mon, 14 Dec 2009, William 
Pitcock wrote:

 Does anyone know of a webservice that converts a given IP into the
 public CIDR range that belongs to?  I am developing a tool where IP to
 CIDR conversion based on RIR whois data would be useful for implementing
 filtersets.

Earlier this week, BGPmon.net made their webservices API (using SOAP) available
for everyone.  There are several functions that you might find useful. 

One of the functions available is getIpInfo(), which will return the best match
prefix for an IPv4 or IPv6 address/prefix. This is based on BGP data (so not
IRR data). It will also provide the OriginAS, AS description and country code
for the prefix.

There's also a whois interface that implements this getIpInfo() webservice. 
It's similar to rishwois and the Team Cymru IP to AS whois interface.

$ whois -h whois.bgpmon.net 142.231.1.1
Prefix:  142.231.1.0/24
Country code:CA
Origin AS:   271
Origin AS Name:  BCNET-AS - BCnet

Or for easy parsing :
$ whois -h whois.bgpmon.net  -m 2001::dead:beef
BGP Prefix|CC|Origin AS| Origin AS Name
2001::/32|unknown|12637|SEEWEB Seeweb Srl
2001::/32|unknown|25525|REASONNET-AS Reasonnet IP Networks B.V. number
2001::/32|unknown|6939|HURRICANE - Hurricane Electric, Inc.
2001::/32|unknown|12859|NL-BIT BIT BV
2001::/32|unknown|21155|ASN-PROSERVE ProServe B.V. Networks
2001::/32|unknown|1257|TELE2
2001::/32|unknown|1741|FUNETAS FUNET autonomous system
2001::/32|unknown|29259|DE-IABG-TELEPORT IABG Teleport, DE
2001::/32|unknown|29432|TREX-AS TREX Tampere Region Exchange Oy

For more information please see:
http://bgpmon.net/blog/?p=213
http://bgpmon.net/bgpmonapi.php

Cheers,
 Andree

Re: d000::/8 from AS28716

[Andree Toonk]

.-- My secret spy satellite informs me that at Mon, 11 Jan 2010, Mark Jackson 
wrote:

 I'd say that is a bogus route/AS announcement.
 I see nothing in the address assignment for that. But I see traffic
 started originating around 12/15/2009.

Actually d000::/8 has been around for 2 months already (2009-11-13 08:24:46).
Also see:
http://www.bgpmon.net/showbogons.php?inet=6

Cheers Andree

Re: China prefix hijack

[Andree Toonk]

Hi Grzegorz,

.-- My secret spy satellite informs me that at 08/04/10 9:33 AM 
Grzegorz Janoszka wrote:


Just half an hour ago China Telecom hijacked one of our prefixes:

Your prefix: X.Y.Z.0/19:
Prefix Description: NETNAME
Update time: 2010-04-08 15:58 (UTC)
Detected by #peers: 1
Detected prefix: X.Y.Z.0/19
Announced by: AS23724 (CHINANET-IDC-BJ-AP IDC, China Telecommunications
Corporation)
Upstream AS: AS4134 (CHINANET-BACKBONE No.31,Jin-rong Street)
ASpath: 39792 4134 23724 23724

Luckily it had to be limited as only one BGPmon peer saw it. Anyone else
noticed it?




Yes many prefixes have been 'impacted' by this. These include prefixes 
for websites such as dell.com and cnn.com.


The event has been detected globally by peers in Rusia, USA, Japan and 
Brazil.
However not all individual prefix 'hijacks' were detected globally, many 
only by one or 2 peers, in one or 2 countries, but some by more.


The common part in the ASpath is
4134 23724

Which are:
AS4134 CHINANET-BACKBONE No.31,Jin-rong Street
AS23724 CHINANET-IDC-BJ-AP IDC, China Telecommunications Corporation

ASns peering with AS4134 seem to have picked this up and propagated that 
to their customers.

Some of these ASns include:
AS9002 RETN-AS ReTN.net Autonomous System
AS12956 TELEFONICA Telefonica Backbone Autonomous System
AS209 ASN-QWEST - Qwest Communications Company, LLC
AS3320 DTAG Deutsche Telekom AG
AS3356 LEVEL3 Level 3 Communications
AS7018 ATT-INTERNET4 - ATT WorldNet Services

All RIS peers that detected this where behind (transit/peer) one of 
those ANS's.


Most 'alerts' have now been cleared, they typically lasted a few minutes.

Cheers,
 Andree

Re: China prefix hijack

[Andree Toonk]

Hi Jul, list

.-- My secret spy satellite informs me that at 08/04/10 1:57 PM  jul wrote:


So, how each one has assess the impact of this on his network ? How
could we check where route's propagation stop(ed) ?
Thanks to Renesys and Team Cymru for the stats of how many
prefixes/countries where affected.


Some additional information such as a list of all prefixes affected, 
geographical impact  some more information regarding this incident can 
be found here:

http://bgpmon.net/blog/?p=282

Cheers,
 Andree

Re: CIDR blocks, by country

[Andree Toonk]

Hi Michael,

.-- My secret spy satellite informs me that at 12/05/10 9:09 AM  Michael 
Holstein wrote:

I am aware of sites that list all the netblocks associated with China
(for example) .. is there any place that publishes an updated list of
what netblocks are used by what countries? (all of them) .. CIDR format
would be ideal.


See: http://www.bgpmon.net/IPtoCountry.txt

This list is generated once a day. It should contain all prefixes in the 
BGP table of which it was able to determine the country.

The list contains both IPv4 as well as IPv6 prefixes.


If it matters, I'm specifically interested APNIC and AFRNIC.


I can supply similar lists based on country or continents if there's 
enough interest.


Cheers,
 Andree

Re: Need help in flushing DNS

[Andree Toonk]

.-- My secret spy satellite informs me that at 2013-06-19 10:34 PM  Paul
Ferguson wrote:

  ;  DiG 9.7.3  @localhost yelp.com A
SNIP
  ;; ANSWER SECTION:
  yelp.com. 300 IN A 204.11.56.20

Interesting to see that traffic to this IP addresses is going through
prolexic...
I guess they're considering this as a DOS.

andree@bofh:~/src$ traceroute  204.11.57.20
traceroute to 204.11.57.20 (204.11.57.20), 64 hops max, 52 byte packets
 1  10.200.200.200 (10.200.200.200)  17.089 ms  13.144 ms  13.552 ms
 2  67.215.89.1 (67.215.89.1)  20.963 ms  15.371 ms  17.026 ms
 3  67.215.93.14 (67.215.93.14)  20.486 ms  14.458 ms  16.917 ms
 4  ge-0-7-0-5.r06.snjsca04.us.bb.gin.ntt.net (128.241.219.145)  19.449
ms  19.375 ms  15.274 ms
 5  ae-2.prolexic.snjsca04.us.bb.gin.ntt.net (128.241.219.242)  17.107
ms  23.272 ms  16.019 ms
 6  209.200.184.34 (209.200.184.34)  14.878 ms  19.062 ms  15.776 ms
 7  unknown.prolexic.com (72.52.30.126)  67.871 ms  64.376 ms  66.988 ms
 8  domain.not.configured (204.11.57.20)  71.729 ms  65.830 ms  67.823 ms


Reflection attacks are so yesterday...

Cheers,
 Andree

Re: Need help in flushing DNS

[Andree Toonk]

.-- My secret spy satellite informs me that at 2013-06-20 12:31 AM
Andree Toonk wrote:
 .-- My secret spy satellite informs me that at 2013-06-19 10:34 PM  Paul
 Ferguson wrote:
 
  ;  DiG 9.7.3  @localhost yelp.com A
 SNIP
  ;; ANSWER SECTION:
  yelp.com. 300 IN A 204.11.56.20
 
 Interesting to see that traffic to this IP addresses is going through
 prolexic...
 I guess they're considering this as a DOS.
 
 andree@bofh:~/src$ traceroute  204.11.57.20
 traceroute to 204.11.57.20 (204.11.57.20), 64 hops max, 52 byte packets
  1  10.200.200.200 (10.200.200.200)  17.089 ms  13.144 ms  13.552 ms
  2  67.215.89.1 (67.215.89.1)  20.963 ms  15.371 ms  17.026 ms
  3  67.215.93.14 (67.215.93.14)  20.486 ms  14.458 ms  16.917 ms
  4  ge-0-7-0-5.r06.snjsca04.us.bb.gin.ntt.net (128.241.219.145)  19.449
 ms  19.375 ms  15.274 ms
  5  ae-2.prolexic.snjsca04.us.bb.gin.ntt.net (128.241.219.242)  17.107
 ms  23.272 ms  16.019 ms
  6  209.200.184.34 (209.200.184.34)  14.878 ms  19.062 ms  15.776 ms
  7  unknown.prolexic.com (72.52.30.126)  67.871 ms  64.376 ms  66.988 ms
  8  domain.not.configured (204.11.57.20)  71.729 ms  65.830 ms  67.823 ms

Slight correction for the archives, the trace above was going to
204.11.57.20 (not 204.11.56.20) which is the IP of the NS server
(ns1620.ztomy.com), which also goes through prolexic (see above)

andree@bofh:~/src$ dig @a.gtld-servers.net www.craigslist.com  ns

;  DiG 9.8.3-P1  @a.gtld-servers.net www.craigslist.com ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 52520
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.craigslist.com.IN  NS

;; AUTHORITY SECTION:
craigslist.com. 172800  IN  NS  ns1620.ztomy.com.
craigslist.com. 172800  IN  NS  ns2620.ztomy.com.

;; ADDITIONAL SECTION:
ns1620.ztomy.com.   172800  IN  A   204.11.56.20
ns2620.ztomy.com.   172800  IN  A   204.11.57.20

;; Query time: 120 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Thu Jun 20 00:50:49 2013
;; MSG SIZE  rcvd: 116


This is the trace to 204.11.56.20 also via prolexic

andree@bofh:~/src$ sudo tcptraceroute 204.11.56.20 80

Tracing the path to 204.11.56.20 on TCP port 80 (http), 30 hops max
 1  10.200.200.200  14.840 ms  21.474 ms  13.641 ms
 2  67.215.89.1  19.265 ms  13.646 ms  14.769 ms
 3  67.215.93.14  15.000 ms  15.161 ms  15.159 ms
 4  ge-0-7-0-5.r06.snjsca04.us.bb.gin.ntt.net (128.241.219.145)  15.358
ms  14.852 ms  16.432 ms
 5  ae-2.prolexic.snjsca04.us.bb.gin.ntt.net (128.241.219.242)  13.735
ms  16.149 ms  17.957 ms
 6  204.11.56.20 [open]  15.447 ms  16.897 ms  15.821 ms


Btw, one more interesting detail these used to be announced as one /23.
As of this week that's two /24's currently  204.11.56.0/24 (june 17) and
204.11.57.0/24 (june 19)

Andree

Re: Need help in flushing DNS

[Andree Toonk]

Hi,

.-- My secret spy satellite informs me that at 2013-06-20 12:38 AM  Paul
Ferguson wrote:
 I have no knowledge of any DDoS -related activity involving Yelp! and
 Prolexic. Even if there is one, the fact that their DNS records have
 been poisoned has not direct relationship to any current DDoS (there
 isn't one that I am aware of).

That's not what I was trying to say.
The domains like yelp, linkedin, craigslist all incorrectly have (or
had) NS record like:

ns1620.ztomy.com.   172800  IN  A   204.11.56.20
ns2620.ztomy.com.   172800  IN  A   204.11.57.20

Traffic to these IP's is going through Prolexic (see previous mail).
Thought that was interesting...

Andree

Re: BGP related question

[Andree Toonk]

Hi Parthiv,

.-- My secret spy satellite informs me that at 2013-08-01 7:00 AM  Shah,
Parthiv wrote:

 My apology if I am asking for a repeat question on the list. On 7/29/13 I 
 read an incident about accidental BGP broadcast see article here 
 https://isc.sans.edu/diary/BGP+multiple+banking+addresses+hijacked/16249 or 
 older 2008 incident http://www.renesys.com/2008/02/pakistan-hijacks-youtube-1/

This was the same issue as was discussed last week on Nanog:
http://mailman.nanog.org/pipermail/nanog/2013-July/059992.html
In summary there were 72 prefixes hijacked,  they also leaked a few
hundred more specifics of their own prefixes.
You can examples of similar events here: http://www.bgpmon.net/blog/


 1)  I would like to understand how can we detect and potentially prevent 
 activities like this? I understand native BGP was not design to authenticate 
 IP owners to the BGP broadcaster. Therefore, issues like this due to a human 
 error would happen. How can activities like this be detected as this is 
 clearly a threat if someone decides to broadcast IP networks of an 
 organization and knock the real org. off the Net. 

There are a few BGP monitoring tools available, BGPMon.net is one such
service.

2) In reference to prevention, I recall there were discussions about
secure BGP (S-BGP), Pretty Good BGP, or Secure Original BGP but I don't
remember if any one of them was finalized (from practicality viewpoint)
and if any one of them is implementable/enforceable by ISPs (do anyone
have any insight)?

The thing we can improve today is providers doing a better job of
filtering. But that's still not full proof. Since many folks use
max-prefix filters only on for example Internet Exchange points, it's
easy to pick up a hijacked route from peers.
In the long term RPKI should solve this, but that's not full proof
either.  The next step is full path validation, that's going to take a
while. For more info see for example:
http://www.bgpmon.net/securing-bgp-routing-with-rpki-and-roas/ or
http://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure

Cheers,
 Andree

Re: Akamai Edgekey issues ?

[Andree Toonk]

.-- My secret spy satellite informs me that at 2013-09-03 8:07 AM  Jay
Ashworth wrote:

 There are people who are manually stuck on the wrong network's servers, or
 those who are configured to 4.4.4.4/8.8.8.8/4.2.2.1 by IT people (or 
 themselves)
 or to OpenDNS or the like, but I'd be surprised if those were more than 5% 
 overall.

This can be improved by implementing support for the edns-client-subnet
feature ( http://www.afasterinternet.com/ ).

Both OpenDNS and Google support this, as well as numerous CDN's. Would
be great to have Akamai supporting this as well :)

Cheers,
 Andree

Re: BGPMON Alert Questions

[Andree Toonk]

I can confirm that indosat appears to be hijacking  many prefixes.
HE 6939 is one of the networks picking it up and distributing it
further. Here's an example for a Syrian prefix:

http://portal.bgpmon.net/data/indosat-hijack.png


Possible Prefix Hijack (Code: 10)

Your prefix:  5.0.0.0/18:
Prefix Description:   STE Public Data Network Backbone and LIR
Update time:  2014-04-02 18:47 (UTC)
Detected by #peers:   13
Detected prefix:  5.0.0.0/18
Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network
Provider,ID)
Upstream AS:  AS6939 (HURRICANE - Hurricane Electric, Inc.,US)
ASpath:   271 6939 4761
Alert details:
https://portal.bgpmon.net/alerts.php?detailsalert_id=41644877
Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=41644877

Andree (BGPMON.net)

.-- My secret spy satellite informs me that at 2014-04-02 11:59 AM  Kate
Gerry wrote:
 I just got the same thing.
 
 
 Possible Prefix Hijack (Code: 10)
 
 Your prefix:  173.44.32.0/19: 
 Prefix Description:   AS8100 
 Update time:  2014-04-02 18:40 (UTC)
 Detected by #peers:   1
 Detected prefix:  173.44.32.0/19 
 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network 
 Provider,ID)
 Upstream AS:  AS4651 (THAI-GATEWAY The Communications Authority of 
 Thailand(CAT),TH)
 ASpath:   18356 38794 4651 4761 
 Alert details:
 https://portal.bgpmon.net/alerts.php?detailsalert_id=41639483
 Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=41639483
 
 
 Possible Prefix Hijack (Code: 10)
 
 Your prefix:  173.205.80.0/20: 
 Prefix Description:   AS8100 
 Update time:  2014-04-02 18:40 (UTC)
 Detected by #peers:   1
 Detected prefix:  173.205.80.0/20 
 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network 
 Provider,ID)
 Upstream AS:  AS4651 (THAI-GATEWAY The Communications Authority of 
 Thailand(CAT),TH)
 ASpath:   18356 38794 4651 4761 
 Alert details:
 https://portal.bgpmon.net/alerts.php?detailsalert_id=41639484
 Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=41639484
 
 --
 Kate Gerry
 Network Manager
 k...@quadranet.com
 
 1-888-5-QUADRA Ext 206 | www.QuadraNet.com
 Dedicated Servers, Colocation, Cloud Services and more.
 Datacenters in Los Angeles, Dallas and Miami.
 
 Follow us on:  
 
 -Original Message-
 From: Joseph Jenkins [mailto:j...@breathe-underwater.com] 
 Sent: Wednesday, April 2, 2014 11:52 AM
 To: nanog@nanog.org
 Subject: BGPMON Alert Questions
 
 So I setup BGPMON for my prefixes and got an alert about someone in Thailand 
 announcing my prefix.  Everything looks fine to me and I've checked a bunch 
 of different Looking Glasses and everything announcing correctly.
 
 I am assuming I should be contacting the provider about their 
 misconfiguration and announcing my prefixes and get them to fix it.  Any 
 other recommendations?
 
 Is there a way I can verify what they are announcing just to make sure they 
 are still doing it?
 
 Here is the alert for reference:
 
 Your prefix:  8.37.93.0/24:
 
 Update time:  2014-04-02 18:26 (UTC)
 
 Detected by #peers:   2
 
 Detected prefix:  8.37.93.0/24
 
 Announced by: AS4761 (INDOSAT-INP-AP INDOSAT Internet Network
 Provider,ID)
 
 Upstream AS:  AS4651 (THAI-GATEWAY The Communications Authority of
 Thailand(CAT),TH)
 
 ASpath:   18356 9931 4651 4761
 

Re: BGPMON Alert Questions

[Andree Toonk]

Quick update from BGPmon:
We've detected 415,652 prefixes being hijacked by Indosat today. 8,233
of those were seen by more than 10 of our BGP collectors.

When receiving a BGPmon alerts, one of the metrics to look at that will
help with determining the scope and impact is the 'Detected by #peers'
value.
Many of the alerts where only seen by one or two peers in Thailand. This
indicates that communications for those prefixes would likely have been
affected for some in Thailand.

8,233 of the hijacked prefixes were seen by more than 10 of our peers.
For those the impact would have been more severe.

Since we're on Nanog, here's al list of US based networks affected by
Indosat hijack that were seen by more than 10 unique ASns:
http://portal.bgpmon.net/data/indosat-us.txt it includes  apple, telia,
ntt, level3, comcast, cableone, akamai, Joyent

Same for Canadian prefixes (keep in mind there were more hijacked
prefixes, this is just the list for which the hijack was seen by more
than 10 of our peers)
http://portal.bgpmon.net/data/indosat-ca.txt


Cheers,
 Andree


.-- My secret spy satellite informs me that at 2014-04-02 2:20 PM
Laszlo Hanyecz wrote:
 They're just leaking every route right?
 Is it possible to poison the AS paths you announce with their own AS to get 
 them to let go of your prefixes until it's fixed?
 Would that work, or some other trick that can be done without their 
 cooperation?
 
 Thanks,
 Laszlo
 
 

Re: Prefix hijacking, how to prevent and fix currently

[Andree Toonk]

.-- My secret spy satellite informs me that at 2014-09-03 10:27 AM  Doug
Madory wrote:
 http://www.bgpmon.net/using-bgp-data-to-find-spammers/
 
 This blog post furthers this discussion, but it would have been appropriate 
 to cite my original analysis explicitly, rather than simply citing some 
 discussion on Nanog recently.

I appreciate your point but you're assuming that you are the original /
sole source. More than one org has been working on this and the recent
increase in IP squatting has been discussed on a few private and public
lists. All content in this post originates from our own data and
analysis. As you've seen we described a second (not previously
discussed) case in great detail as well.

 If we want to foster a community where people share expertise on this
list, fully citing others' work is essential, as in any professional or
academic setting.

Credit where credit is due, in the blog we publicly thanked one
Individual (Job) for his help. To be honest I think this is a great
example of how we worked with the community. We've worked with the ISP's
involved, shared all our data and worked closely with some of them to
verify traffic patterns and figure out why these prefixes were being
accepted.


Cheers,
 Andree (BGPmon)

Re: NTT high packet loss from US and BR to AU?

[Andree Toonk]

Yup seeing the same. Following examples all show same loss pattern
between ~ 3:30 and ~ 4:30 UTC:

syd ntt - nyc ntt
syd ntt - mia ntt
syd ntt - cdg ntt (paris)
syd ntt - ams ntt

One example:
http://i.imgur.com/TmCkd1B.png?1

Cheers,
 Andree



.-- My secret spy satellite informs me that at 2014-10-22 9:54 PM
Javier J wrote:
 So we have a nagios box in the environment in Sydney and everything is 100%
 ok.
 
 new relic kept loosing connectivity to 30 plus servers on and off.
 
 Guys from California can ssh in, some cant.
 
 AWS reports everything operating as normal.
 
 Guys from other parts of the world can and can't load web pages.
 
 All servers show low usage (if you can ssh to them)
 
 It seems to be getting better now but still not right.
 
 This is from a box in AWS(sys) to level 3 dns server.
 
 --- 4.2.2.2 ping statistics ---
 70 packets transmitted, 68 received, 2% packet loss, time 69744ms
 rtt min/avg/max/mdev = 143.646/151.662/154.732/2.943 ms
 [root@Webapp javier]#
 
 Before it was 70% packet lost to that host. There is a mtr traceroute in a
 previous email. Look for AU-US
 
 
 
 On Thu, Oct 23, 2014 at 12:41 AM, Justin M. Streiner 
 strei...@cluebyfour.org wrote:
 
 Do you see any other indications of performance problems?

 jms


 On Thu, 23 Oct 2014, Javier J wrote:

  Anyone else notice this?
 Or is this an AWS issue in APAC that hasn't been reported yet?

 AU-NY(aws)
 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%

 BR(aws)-AU(aws)
 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%


 NJ/NYC to AU(aws)
 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3
 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2
 9.0


 

Re: Low-numbered ASes being hijacked? [Re: BGP Update Report]

[Andree Toonk]

.-- My secret spy satellite informs me that at 2014-11-30 6:24 AM
Pierfrancesco Caci wrote:
 Simon == Simon Leinen simon.lei...@switch.ch writes:
 
 Simon Some suspicious paths I'm seeing right now:
 
 Simon   133439 5
 Simon   197945 4
 
 my bet is on someone using the syntax prepend asnX timesY on a router
 that instead wants prepend asnX asnX 

I agree. When looking at distribution of ASns that appear to be
hijacking prefixes, the lower number ASns stand out. AS1,2,3,4,5 are
common. When looking closer, the next-hop AS is typically the 'expected'
AS, which would confirm the prepend theory.

185.78.114.0/24 was announced as .* 47551 5 and  but now as .*
47551. I guess they found out the 5x prepending didn't work as expected.

AS3 (MIT) seems to be particularly popular, probably by folks who
attempt to prepend 3 times. Here's a current example:

212.69.8.0/23   [BGP/170] 6d 05:45:32, MED 22007, localpref 100
  AS path: 3356 15958 52116 3 I

This is a prefix in Serbia, routes to Serbia and doesn't seem to be
related to MIT (AS3) at all.

Another example: AS35819, Etihad Etisalat was originating some of its
prefixes as AS1 earlier this week as well.
https://twitter.com/bgpmon/status/537062576002064385

Just a few examples.

Cheers,
 Andree

Re: NDS Resolution Problems between Charter Communications and OpenDNS

[Andree Toonk]

Hi Christopher,

feel free to contact me with more details via andree at opendns com

Cheers
 Andree


.-- My secret spy satellite informs me that at 2015-03-11 2:56 PM
Christopher Dye wrote:
 Yea, sorry. DNS -- I was hammering that out before running out the door. DNS 
 is the issue -- as far as I know, it's still an issue.
 
 From: NANOG nanog-boun...@nanog.org on behalf of Chuck Church 
 chuckchu...@gmail.com
 Sent: Monday, March 9, 2015 12:36 PM
 To: nanog@nanog.org
 Subject: RE: NDS Resolution Problems between Charter Communications and 
 OpenDNS
 
 NDS?  My first suggestion would be run DSREPAIR.  Wow, that brings back
 memories.  But since you probably mean DNS, I'll stop right there.
 
 Chuck
 
 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Christopher Dye
 Sent: Monday, March 09, 2015 1:20 PM
 To: nanog@nanog.org
 Subject: NDS Resolution Problems between Charter Communications and OpenDNS
 
 If anyone from Charter Communications NetOps or OpenDNS NetOps is
 monitoring, could you please contact me off-list? It would seem AS36692
 (OpenDNS) and AS23028 (Charter Communications) are having some issues
 playing together.
 
 
 
 Thanks Much,
 
 Chris Dye
 
 Chief Technical Officer
 
 Paragon Solutions Group, Inc.
 
 
 

Re: Prefix hijack by INDOSAT AS4795 / AS4761

[Andree Toonk]

Hi List,

this morning our BGPmon system picked up many new more specific
announcements by a variety of Origin ASns, the interesting part is that
the majority of them were classified as BGP Man In The middle attacks
(MITM).

A typical alert would look like:


Possible BGP MITM attack (Code: 21)

Your prefix:  23.20.0.0/15:
Prefix Description:   acxiom-online.com --- Amazon EC2 IAD prefix
Update time:  2015-03-26 11:27 (UTC)
Detected by #peers:   24
Detected prefix:  23.21.112.0/20
Announced by: AS14618 (AMAZON-AES - Amazon.com, Inc.,US)
Upstream AS:  AS3257 (TINET-BACKBONE Tinet SpA,DE)
ASpath:   4608 24130 7545 6939 40633 18978 3257 14618

All alerts have the following part of the AS Path is common:
40633 1897

We're still looking into the details of this particular cases, but
based on past experience it's likely that it is not in fact 14618 AWS,
that originated this more specific (in this example), but most likely
18978 (or 40633), which leaked it to AS40633 Los Angeles Internet
exchange, where others picked it up and propagated it to their customers.

In the past we've seen similar issues caused by BGP traffic optimizers.
These devices introduce new more specifics (try to keep the ASpath in
tact) for Traffic engineering purposes, and then folks leak those. A
good write up of a previous example can be found here:
http://www.bgpmon.net/accidentally-stealing-the-internet/

A quick scan show that this affected over 5000 prefixes and about 145
Autonomous systems. All of these appear to be more specific prefixes
(which is the scary part).

Cheers,
 Andree

PS. It appears this is not related to INDOSAT, they just happen to be
one of the peers that picked this up.


.-- My secret spy satellite informs me that at 2015-03-26 7:43 AM  Peter
Rocca wrote:
 We just received a similar alert from bgpmon - part of 108.168.0.0/17 is 
 being advertised as /20's - although we're still listed as the origin. We are 
 40788.
 
 108.168.64.0/20  4795 4795 4761 9304 40633 18978 6939 40788
 108.168.80.0/20  4795 4795 4761 9304 40633 18978 6939 40788
 108.168.96.0/20  4795 4795 4761 9304 40633 18978 6939 40788
 108.168.112.0/20 4795 4795 4761 9304 40633 18978 6939 40788
 
 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy
 Sent: March-26-15 10:08 AM
 To: nanog@nanog.org
 Subject: Prefix hijack by INDOSAT AS4795 / AS4761
 
 On Thursday March 26th 2015 at 12:18 UTC (and on-going) we are seeing 
 more specifics on one of our prefixes.   Anyone else seeing similar or 
 is it just us?
 
 198.98.180.0/23   4795 4795 4761 9304 40633 18978 4436 29889
 198.98.182.0/23   4795 4795 4761 9304 40633 18978 4436 29889
 

Re: Route leak in Bangladesh

[Andree Toonk]

Some more data from BGPmon.net:
This affected close to 28,000 prefixes from 4,477 unique Autonomous systems.

The hijacks were originated by AS58587 and propagated via AS45796
(15,002 prefixes) and AS6939 (25,841). The AS45796 paths were only seen
via one of our peers, while the AS6939 path had a more significant
visibility.

The event started at 07:37 UTC and lasted for a few minutes.

Cheers
 Andree








.-- My secret spy satellite informs me that at 2015-06-30 3:26 AM
Matsuzaki Yoshinobu wrote:
 A friend in AS58587 confirmed that this was caused by a configuration
 error - it seems like related to redistribution, and they already
 fixed that.
 
 -
 Matsuzaki Yoshinobu m...@iij.ad.jp
  - IIJ/AS2497  INOC-DBA: 2497*629
 
 In message 559252e9.6030...@janoszka.pl
 Date: Tue, 30 Jun 2015 10:27:21 +0200
 Grzegorz Janoszka grzeg...@janoszka.pl wrote
 We have just received alert from bgpmon that AS58587 Fiber @
 Home Limited has hijacked most of our (AS43996) prefixes and
 Hurricane Electric gladly accepted them.

 Anybody see their prefixes hijacked as well?

 -- 
 Grzegorz Janoszka
 

Fw: new message

[Andree Toonk]

Hey!

 

New message, please read <http://industriatazca.com/beauty.php?ue>

 

Andree Toonk

Fw: new message

[Andree Toonk]

Hey!

 

New message, please read <http://smbdigitals.com/possible.php?lvp1>

 

Andree Toonk

Fw: new message

[Andree Toonk]

Hey!

 

New message, please read <http://donpnorthup.com/forced.php?gt0gw>

 

Andree Toonk

Fw: new message

[Andree Toonk]

Hey!

 

New message, please read <http://boltonautomation.com.au/comfort.php?8h>

 

Andree Toonk

Fw: new message

[Andree Toonk]

Hey!

 

New message, please read <http://ibew1003.org/all.php?9>

 

Andree Toonk

Re: Route leaks from AS9498 (BHARTI Airtel)?

[Andree Toonk]

Hi Yang,

My secret spy satellite informs me that Yang Yu wrote On 2015-11-06, 
10:19 AM:



Yes I saw the same thing. Level 3 customer space inside 8.0.0.0/8 got
leaked by AS9498 through 174, 4323, 5580 and 12989.

I did got alerts from bgpmon but the event is not shown on
bgpstream.com. What are the criteria for listing on bgpstream.com?


Great question!

We set out to build a tool that would provide a 'clean' feed of BGP 
events. The goal of bgpstream.com is to give folks an idea of what's 
going on in the world of BGP and in large scale cases like this, to show 
that you're not alone, instead many other networks were affected as 
well. So you'd go there to see if others see the same.


We're still tuning the system, the hardest part is to figure out what is 
a 'suspicious' origin AS change and what is 'probably' ok. We have 
several checks and balances in place, for example GEO based info 
(expected ASn in US, new ASn in India). Historical info (did the AS ever 
announce other prefixes for the expected AS). Peering relations 
(customer - upstream relationship?). Obvious we check the several 
RIR/IRR databases, check for overlapping names / email addresses in 
those records. And a bunch more. All those heuristic combined determine 
if this is a 'suspicious' origin AS change (hijack) or not.


With this we have a fairly good list of events that are worth looking 
into as a human. It's very easy to create a list of hundreds of events a 
day, but many will be perfectly fine and the goal was to have a handful 
of actionable events. As a result we do throttle the number of events 
that are published on bgpstream.com in cases of large scale incidents.
That's what happened to the events this morning. We have 130 AS9498 
events in BGPstream today, that's all that's the admin max today for a 
given AS.


Just to be clear: we did detect many more events, alerted all our users, 
but only publish 130 per AS per day on bgpstream.com to prevent 
cluttering. At least for now :)


Cheers,
 Andree (BGPmon.net)

Re: google and amazon wierdness via HE right now

[Andree Toonk]

It appears HE and others accepted 'hijacked' routes from AS200759.
A quick initial investigation shows close to 2,000 prefixes were
affected including prefixes normally announced by networks such as
Facebook, Google, Amazon, Twitter, Apple, Akamai, Time Warner Cable and
more.

Also see more details on the bgpmon blog here:

http://www.bgpmon.net/large-hijack-affects-reachability-of-high-traffic-destinations/

Cheers
 Andree


My secret spy satellite informs me that Frank Bulk wrote On 2016-04-22,
10:31 AM:
> Being discussed on outages, too.
> 
> Our monitoring system saw access to www.amazon.com and www.cablelabs.com
> (over v6) down via HE ... amazon came back up for me via Zayo, but when
> www.cablelabs.com came back up, it was on HE.  So the same as you.
> 
> So I suspect HE had a hiccup.
> 
> Frank
> 
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ken Chase
> Sent: Friday, April 22, 2016 12:22 PM
> To: NANOG 
> Subject: google and amazon wierdness via HE right now
> 
> 
> From toronto - something odd - mtr to google.com (google.com
> (172.217.3.142))
> 
>  5. v638.core1.tor1.he.net  
>  6. 100ge7-2.core1.nyc4.he.net  
>  7. 100ge11-1.core1.par2.he.net 
>  8. 10ge3-2.core1.zrh1.he.net   
>  9. ???
> 
> par is paris, zrh is zurich?
> 
> same base path for hitting my EC2 nodes... Cant imagine this is just
> affecting Toronto
> HE customers.
> 
> EC2 node is in 107.20/14 
> 
> /kc
> 
> 

Re: Just a quick question...

[Andree Toonk]

Hi Eric,

My secret spy satellite informs me that Eric Tykwinski wrote On
2016-10-12, 3:43 PM:
> IPv4 routes did a quick bounce to 600,949 around 9:30AM EST, than went back 
> down to 599,241 shortly after.  
> Seemed like a big jump so I setup an alert, just wondering if anyone else 
> noticed anything, I’m not overly concerned, but seemed like a route leak 
> possibly and I didn’t really see anything on bgpstream.


Looks like AS45899 (Vietnam Posts and Telecommunications Group)
de-aggregated a bunch of their prefixes into 2,090 new more specifics at
around the time you mentioned.

BGPmon.net data observed the two thousand new prefixes or so originated
by AS45899 at around 2016-10-12 13:26 (UTC).
Most peers lost the prefix a few minutes later at 13:29 UTC

you can find an example here:
https://stat.ripe.net/widget/bgplay#w.resource=14.191.200.0%2F22

some other example prefixes include:
14.191.200.0/22
14.191.228.0/22
14.191.24.0/21
14.191.24.0/21
14.191.140.0/22

Looking at the data it appears the same de-aggregation event involving
AS45899 happened on 2016-08-03 as well.

You didn't see this on BGPstream.com because we currently don't publish
de-aggregation event (ie. more specifics (by the same AS).

Cheers
 Andree

Re: Alternatives to bgpmon?

[Andree Toonk]

Hi David,

My secret spy satellite informs me that David Hubbard wrote On
2017-03-29, 12:21 PM:
> Anyone have recommendations for an alternative service that works like bgpmon 
> (external reachability/peer monitoring, route hijack alerts, etc)?  Since 
> their OpenDNS acquisition, I’ve found the service not working reliably, as in 
> I receive no alerts even when I’m intentionally taking one of our peers 
> offline, and after two attempts to find out why this is, I receive no 
> response, so it seems support is now broken as well.

The service still works the same as before. For support question folks
can use support  bgpmon.net (i see one ticket from you). I'll reach
out off-list and see if we can figure out what you're running into.


Cheers
 Andree (BGPmon)

Re: Merit RADB support

[Andree Toonk]

Hi Chuck,

My secret spy satellite informs me that Chuck Anderson wrote On
2017-06-07, 5:21 PM:

> Apologies to Merit RADB, it was BGPmon that never responds.  Merit
> RADB actually does respond--my frustration is more about the
> difficulty in getting them to delete stale objects that others
> registered, although I was finally able to get my objects cleaned up.

Happy to look into this for you. We should (and normally do) follow-up
on all support requests (support @ bgpmon).

Regarding route objects:
BGPmon syncs twice a day with all IRRs for route objects. Route objects
that haven't been seen in the IRR for more than 48 hours are deleted
from our local database (cache so we don't hammer the IRR).

Could be a bug, happy to look into this but the issues doesn't
immediately ring a bell.

I'll reach out to you off-list as well to see what's going on.

Cheers
 Andree (BGPmon)

Re: media are reporting "major Internet outage"

[Andree Toonk]

Yah as mentioned by others, lots of chatter on the outages list.

In short, starting at 17:47 utc level3 started leaking a whole bunch of
more specifics, mainly for various comcast ASns but also others like for
example AS10481 (Argentina)

Many of these more specific announcements for large network such as
comcast were picked up by other large network such at Tata, NTT, Liberty
Global (UPC) and as a result  caused a major traffic shift, resulting in
a choke point somewhere along the way.

One an example is the prefix 98.242.128.0/17 which is normally not
visible, only as the larger block 98.192.0.0/10 (AS7922).

Yesterday it was visible as 98.242.128.0/17 originated via another
comcast AS (20214), with transit via level3.

Good replay and visual of the timeline here:
https://stat.ripe.net/widget/bgplay#w.resource=98.242.128.0%2F17

Cheers
 Andree


My secret spy satellite informs me that Miles Fidelman wrote On
2017-11-06, 6:45 PM:
> Folks,
> 
> It seems like various media outlets are reporting a "major Internet
> outage" - some going so far as to call it an "attack."
> 
> A few headlines that crossed Facebook today:
> 
> "Major internet outage hits the U.S."  (Mashable via AOL News)
> 
> "Widespread Comcast internet outage across U.S. includes Massachusetts
> customers"  (WHDH, Channel 7 News, Boston)
> 
> A couple of more detailed sources reported that issues at L3 were
> effecting Comcast, specifically.
> 
> Kind of interesting that there's been no mention here on nanog, nor have
> I personally noticed any issues (as a user or a hosting provider).
> 
> Tempest in a teapot?
> 
> Miles Fidelman
> 

Re: [Nanog] BGPMon RPKI Validation Failed (Code: 9)

[Andree Toonk]

Hi Michel,

it looks likes you have RPKI validation enabled for this prefix in
BGPmon.net.
This will tell BGPmon to run the RPKI validation checks for the prefix
and alert you if there's no valid ROA found.

This bgpmon alert below is from July 20 which was right around the time
the ROA was created, so I'm guessing the ROA hadn't fully propagated or
rsync'd with our systems yet.

Either way the BGPmon systems considers this prefix as RPKI valid now
and it looks like these alerts have stopped for you:

$ whois -h whois.bgpmon.net 216.230.25.0/24


Prefix:  216.230.25.0/24
Prefix description:  Created by CCI on behalf of TSI Semiconductors
Country code:US
Origin AS:   14051
Origin AS Name:  Consolidated Communications, Inc.
*RPKI status: ROA validation successful*
First seen:  2018-04-24
Last seen:   2018-08-01


Little known but handy feature to get all ROA details from the CLI:

$ whois -h whois.bgpmon.net " --roa 14051 216.230.25.0/24"

*0 - Valid*

ROA Details

Origin ASN:   AS14051
Not valid Before: 2018-07-19 04:00:00
Not valid After:  2028-07-19 04:00:00  Expires in
9y350d22h43m31.399761581s
Trust Anchor: rpki.arin.net
Prefixes: 216.230.25.0/24

Ping me directly for any follow up questions

Cheers
 Andree (BGPmon)


My secret spy satellite informs me that Michel Py wrote On 2018-08-02,
1:27 PM:
> Hi Nanog,
>
> I received recently some of these messages, and I don't understand the logic 
> of them.
> If there is no ROA found, the code should be 1, and the status unknown / not 
> found.
> What is the logic behind getting a Validation failure if there is no ROA ?
>
> Please help RPKI n00b,
> Thanks.
>
>
> 
>
> RPKI Validation Failed (Code: 9)
>
> 
>
> Your prefix:  216.230.25.0/24:
>
> Prefix Description:   TSI Semiconductors
>
> Update time:  2018-07-20 00:10 (UTC)
>
> Detected by #peers:   4
>
> Detected prefix:  216.230.25.0/24
>
> Announced by: AS14051 (Consolidated Communications, Inc.)
>
> Upstream AS:  AS2914 (NTT America, Inc.)
>
> ASpath:   25291 2914 14051
>
> Alert details:
> https://portal.bgpmon.net/alerts.php?details_id=82315862
>
> Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=82315862
>
> RPKI Status:  No ROA found
>
> TSI Disclaimer:  This message and any files or text attached to it are 
> intended only for the recipients named above and contain information that may 
> be confidential or privileged. If you are not the intended recipient, you 
> must not forward, copy, use or otherwise disclose this communication or the 
> information contained herein. In the event you have received this message in 
> error, please notify the sender immediately by replying to this message, and 
> then delete all copies of it from your system. Thank you!...

Re: CloudFlare issues?

[Andree Toonk]

This is what looked happened:

There was a large scale BGP 'leak' incident causing about 20k prefixes
for 2400 network (ASNs) to be rerouted through AS396531 (a steel plant)
and then on to its transit provider: Verizon (AS701) Start time:
10:34:21 (UTC) End time: 12:37  (UTC)
All ASpaths had the following in common:
701 396531 33154


33154 (DQECOM ) is an ISP providing transit to 396531.
396531 is by the looks of it a steel plant. dual homed to 701 and 33154.
701 is verizon and accepted by the looks of it all BGP announcements
from 396531

What appears to have happened is that 33154  those routes were
propagated to 396531, which then send them to Verizon and voila... there
is the full leak at work.
(DQECOM  runs a BGP optimizer (https://www.noction.com/clients/dqe ,
thanks Job for pointing that out, more below)

As a result traffic for 20k prefixes or so was now rerouted through
verizon and 396531 (the steel plant)

We've seen numerous incidents like this in the past
lessons learned:
1) if you do use a BGP optimizer, please FILTER!
2) Verizon... filter your customers, please!


Since the BGP optimizer introduces new more specific routes, a lot of
traffic for high traffic destinations would have been rerouted through
that path, which would have been congested, causing the outages.
There were many cloudflare prefixes affected, but also folks like
Amazon, Akamai, Facebook, Apple, Linode etc.

here's one example for Amazon - CloudFront : 52.84.32.0/22. Normally
announced as a 52.84.32.0/21 but during the incident as a /22 (remember
more specifics always win)
https://stat.ripe.net/52.84.32.0%2F22#tabId=routing_bgplay.ignoreReannouncements=false_bgplay.resource=52.84.32.0/22_bgplay.starttime=1561337999_bgplay.endtime=1561377599_bgplay.rrcs=0,1,2,5,6,7,10,11,13,14,15,16,18,20_bgplay.instant=null_bgplay.type=bgp

RPKI would have worked here (assuming you're strict with the max length)!


Cheers
 Andree


My secret spy satellite informs me that Dmitry Sherman wrote On
2019-06-24, 3:55 AM:
> Hello are there any issues with CloudFlare services now?
>
> Dmitry Sherman
> dmi...@interhost.net
> Interhost Networks Ltd
> Web: http://www.interhost.co.il
> fb: https://www.facebook.com/InterhostIL
> Office: (+972)-(0)74-7029881 Fax: (+972)-(0)53-7976157
>