Prefix-Hijack by AS7514

Hi,

does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 ....

Thanks & best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj@anexia.at<mailto:jj@anexia.at>
Web: http://www.anexia.at/>

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Seeing the same; a /19.

BGPMon reports an alert at 2015-07-17 05:29 (UTC) and that it's being accepted by 2497.

We already informed AS2497 but I have no idea if they we'll cooperate.

Best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Hi,

does anyone else see some prefix hijacks from AS7514? They started to announce some of our /24 ....

Worldwide.

-Hank

I contacted 7514. They are aware.

-Seiichi

Hi,

we also sent them an mail, but their MX is not reachable for us :frowning:

best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

We already informed AS2497 but I have no idea if they we'll cooperate.

All prefixes I see have the first octet as being 2 digits rather than 3. That is common among about 30 different alerts I have received. Curious if this is common worldwide.

-Hank

Hi,

all affected prefixes starts with 37... no other prefixes from AS42473 are affected.

Best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

I let IIJ know too, hopefully they'll filter it soon.

I let IIJ know too, hopefully they'll filter it soon.

It seems AS7514 stopped the announcements around 06:54UTC.

I am not sure how BGPmon guesses AS relationships, but it needs
improvements as it shows IIJ as an upstream of AS7514 wrongly.

any idea why error happened ?
what config needs fixing to mitigate mistake?
it was easy to see problem via ripe atlas :slight_smile:

colin

I just got brief explanation from a friend in AS7514.

A router in their network suddenly went out of control, and it seems
this somehow generated wrong routing information. They solved the
issue by disconnecting the router and are now investigating it.

even if customer router crash fault, should have been filtered via prefix list blocking to only allow customer network prefixs to be anounced onwards ? as per best practice

colin

Yes, I agree, and we have done that. How about peering partners -
which is our case this time. Is it feasible to maintain strict
inbound prefix filters for all peering relationships?

To be honest, not really.

Some countries I know do this for their exchange points. But
by-and-large, it is not scalable. Same goes for AS_PATH lists for peering.

One can be liberal at peering points but have max-prefix as a basic
protection mechanism (which is what we do).

Of course, IRR's are the other way to go.

Mark.

it does scale.
We do this for all our routeservers at all exchange points we operate.
In Frankfurt we have 745 peers on our routeservers.

(And: we are not a country but an exchange point operator :slight_smile:

best regards
Wolfgang

it does scale.
We do this for all our routeservers at all exchange points we operate.
In Frankfurt we have 745 peers on our routeservers.

So you have prefix and AS_PATH lists for each of the members you peer
with that strictly define the prefixes they will announce to your route
server?

(And: we are not a country but an exchange point operator :slight_smile:

One learns something new everyday...

Mark.

Wolfgang, it's unfair ... you do not have to deal with hardware routers :).

Install AS_PATH ACL and prefix list on a Cisco router (e.g. with an RSP720-3CXL) and you'll run into lots of pain ...

best regards

Jürgen Jaritsch
Head of Network & Infrastructure

ANEXIA Internetdienstleistungs GmbH

Telefon: +43-5-0556-300
Telefax: +43-5-0556-500

E-Mail: jj@anexia.at
Web: http://www.anexia.at

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
Geschäftsführer: Alexander Windbichler
Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

Scale has become my favorite term from vendors that sets off
alarm bells.

  The problem is usually limited by someones imagination like
"why would you have more than 1 comment/remark", or "what do you mean
a customer has 200k prefixes registered".

  it all depends on who/where and what role you play.

  We have tried prefix filtering peers before. It's an
excercise in frustration when it comes to vendors ability to
ingest the large sets and/or changes. I talked about this
privately and at things like IEPG.

http://iepg.org/2014-03-02-ietf89/ietf89_iepg_jmauch.pdf

  The situation and technology haven't substantively changed
in the interim.

  - Jared