Live data from Hacker News

Shutting Down the BGP Hijack Factory

dyn.com

31–40 of 63 posts

Re: Shutting Down the BGP Hijack Factory

#31
post #17

Earlier quoted context omitted.

It makes sense from a not-wanting-to-get-sued-for-breach-of-contract standpoint. The contract at IXPs almost universally includes a phrase like "will not engage in fraudulent announcement of routes", but proving that happened to the satisfaction of a non-profit's board of directors is difficult. You really have to have completely collinear anatidae.

> collinear anatidae I'm stealing this phrase, please and thank you.

Why? It sounds incredibly pretentious. I think most people would appreciate Plain English [0].

[0] https://en.wikipedia.org/wiki/Plain_English

Re: Shutting Down the BGP Hijack Factory

#32
post #28
post #27

Earlier quoted context omitted.

I had a conversation with a friend about this, and the outcome was the idea that BGP could be extended with functionality for this case. There needs to be a way to brand "negative" traffic or routes advertised with some sort of reputation system. In the event of a DDoS attack coming from an AS, you could have intra-AS weight for any given AS such that if an AS reports malicious traffic from a route, it's given a lowe…

How would that work in practice? If I compromise a pile of IoT devices running on Comcast users' networks, and use them to launch and attack, all Comcast users on their subnet get marked as uncool? And if we're marking them as "bad", doesn't that mean all of their BGP peers mark them as uncool and then the weights for their prefix are lower but still even, so routing still ends up the same? The only way they'd be imp…

You can see the impact of this kind of thinking in RBLs and blocklists - try to send email via your residential connection and you probably won't be able to.

Re: Shutting Down the BGP Hijack Factory

#33
post #12

I have worked for a medium size ISP for many years (3 upstream Tier-1 provider, presence on 2 IXP) and we sometimes suffer from BGP hijaking. We had developed a software that every hour checks the BGP prefix assigned to every peer and update the BGP filter automatically. It takes some time to engineering it and develop but after then, it works like a charm.

That’s a 1-hour attack window though. It should be event driven, something where peers can securely signal changes as they happen

Those are very expensive. According to apnic[1], there are 15,000 update / day in 2016. For small size ISP, the number is much lower and may be managible. But event driven can't be a general solution for larger isp.

[1] https://blog.apnic.net/2017/01/27/bgp-in-2016/

Re: Shutting Down the BGP Hijack Factory

#34
post #33
post #12

Earlier quoted context omitted.

That’s a 1-hour attack window though. It should be event driven, something where peers can securely signal changes as they happen

Those are very expensive. According to apnic[1], there are 15,000 update / day in 2016. For small size ISP, the number is much lower and may be managible. But event driven can't be a general solution for larger isp. [1] https://blog.apnic.net/2017/01/27/bgp-in-2016/

15k updates a day? how big is the payload? ...sounds negligible to someone ignorant in BGP finer details.

Re: Shutting Down the BGP Hijack Factory

#35
post #23

Earlier quoted context omitted.

Yes that’s true, most of the work and moderation is done via mailing lists (like in Linux dev or with IETF/RFCs) but when we’re talking about the infrastructure I would expect something more efficient. Sure someone must notice it and report it, but I don’t get why it takes so long. And just to avoid misunderstandings I’m not talking about censorship, but actual WTF situations as this one described in the post where i…

How do you decide whether the bad BGP announcement was an accident or malicious?

When someone accidentally announces an incorrect prefix, they're pretty up-front about it, and try to correct it as soon as possible. It's not something you really see that often either, as you don't change the prefixes you announce very often. Really only when you acquire new IP space. Otherwise, the router config is largely set-and-forget as long as the peerings are up.

So if someone does fat-finger a prefix announcement, it's followed by an email to the IX mailing lists and transit providers with an apology and a quick fix.

It starts to become apparent who made an honest mistake here and there and who's acting maliciously.

Re: Shutting Down the BGP Hijack Factory

#36
post #8
post #7

Earlier quoted context omitted.

According to a post by Job on nanog they have been known to submitted false or fabricated IRR information to RADB and RIPE: http://seclists.org/nanog/2018/Jun/379 At the end of the day, BGP is a very trusting protocol and it requires keeping the neighborhood clean and clear. IMO providers should be filtering prefixes their clients shouldn't be announcing (al la BCP38) but keeping up on the various IP blocks being shi…

BGP is still very much built on trust and reputation... At a local ix level if you were to show up at an ix like the ams-ix and regularly announce prefixes you have no right to, your company name and AS# would quickly develop the reputation of a rancid turd.

The BGP authentication method doesn't seem very secure, so how do you know who you are trusting?

Re: Shutting Down the BGP Hijack Factory

#37

Earlier quoted context omitted.

> collinear anatidae I'm stealing this phrase, please and thank you.

Why? It sounds incredibly pretentious. I think most people would appreciate Plain English [0]. [0] https://en.wikipedia.org/wiki/Plain_English

Because it's a lovely application of rhyming slang.

https://en.wikipedia.org/wiki/Rhyming_slang

Re: Shutting Down the BGP Hijack Factory

#38
post #36
post #8

Earlier quoted context omitted.

BGP is still very much built on trust and reputation... At a local ix level if you were to show up at an ix like the ams-ix and regularly announce prefixes you have no right to, your company name and AS# would quickly develop the reputation of a rancid turd.

The BGP authentication method doesn't seem very secure, so how do you know who you are trusting?

a properly implemented IX has MAC address filtering on ports. This can of course be spoofed. But there is also a level of security at OSI layer 1 for the physical fiber cross connect from an ISP's panel to the IX's panel.

For instance: If the IX is located on the 15th floor of the building. An ISP might be colocated on the 12th floor. Fiber XC from 12.501.P4.D4 (12th floor, row 5, rack 01, fiber patch panel 4, SC duplex port D4) to 15.201.P1.D4, then a fiber cable from D4 to an SFP+ port on the IX's switch. Unless somebody physically hijacks your fiber crossconnect and moves it (which would be noticed as hard down immediately) it's pretty hard to pretend to be another ISP, from the perspective of the switch fabric operator of the IX.

Re: Shutting Down the BGP Hijack Factory

#39
post #23

Earlier quoted context omitted.

Yes that’s true, most of the work and moderation is done via mailing lists (like in Linux dev or with IETF/RFCs) but when we’re talking about the infrastructure I would expect something more efficient. Sure someone must notice it and report it, but I don’t get why it takes so long. And just to avoid misunderstandings I’m not talking about censorship, but actual WTF situations as this one described in the post where i…

How do you decide whether the bad BGP announcement was an accident or malicious?

When the announcer doesn't immediately retract it in embarrassment, continues to announce it, the RIPE/APNIC/ARIN WHOIS data for the block continues to show ownership info other than the announcer, and the announcer doesn't produce a legitimate business relationship and LOA for why they should be announcing that "new" /18. It's usually pretty obvious.
Post reply on HN