You are on page 1of 40

Inter-Domain Routing Security

 ~BGP Route Hijacking~

Mar 1 2007 in APRICOT 2007

NTT Communications Corp.
Taka Mizuguchi
Tomoya Yoshida

What’s BGP Route Hijacking?
 Invalid BGP route announcement
 Traffic diverting by BGP route hijacking,
unreachable…
 Detection is not so easy…
 Recovery is very hard…
 Not frequently, but it occurs
 Easy outbreak, but big impact
 Not only global, but localized outbreak

Definition of Hijacking
> 10.0.0.0/8 100 10.0.0.0/8 200 100
10.0.0.0/8 300 400 > 10.0.0.0/8 400

10.0.0.0/8
AS200 AS300
10.0.0.0/8

10.0.0.0/8 10.0.0.0/8

AS100 AS400
10.0.0.0/8 10.0.0.0/8

 AS100 is advertising their owned route(10.0.0.0/8) : Victim AS
 AS400 is advertising invalid route(10.0.0.0/8) : Hijacking AS
 AS300 is infected by Hijacking : Infected AS
 AS200 is Influenced but not infected by Hijacking : Influenced AS

Impact by Hijacking
 Network Unreachable/Service failure
– Traffic divert to other network (Hijacked Network)
– Service failure / Failure of Application
i.e. DNS: Root-server address hijacking
 Leak of Information
– By traffic diverting and Packet capture
– Looks like Phishing…
 Temporary hijacking
– Generating DoS Traffic
– Sending SPAM
#Impact is not only infected network, but all
other user can’t access infected sites.

0/16 40 i  Sub-prefix Hijack – Valid: 10.0.0/16 10 i – Invalid: 10.0. Type of Route Hijacking  Prefix Hijack – Valid: 10.0/16 10 i – Invalid: 10.0.0.0.0.0.0.0/24 40 i .

Extent of the impact by BGP Route Hijacking  Global impact – Invalid longer prefix advertisement – Detection is easy  Local impact – Invalid same prefix advertisement – Invalid longer prefix. but filtered on peering link – Detection is hard  No impact – Invalid shorter prefix advertisement – Detection is easy – Short lived BGP For spam/DoS sending. Phishing .

0/24 30 40 > 10.0/24 i 10.0/16 AS10:Customer of AS20 AS40:Customer of AS30 AS20 and AS30 is peering Global Impact .0.0.0/16 > 10. Hijacking .0/16 30 20 10 10.0.0.0.0/24 40 AS20 10.0.0.0/24 30 40 10. Case-1 > 10.0/16 20 10 > 10.0/24 AS10 10.0/16 10.0/16 10 > 10.0.0.0.0/24 AS40 10.0.0.0.0.0.0.0.0.0.0/24 10.0.0.0.0.0/24 10.0.0.0.0/16 > 10.0.0.0.0.0.0.0/24 > 10.0/16 10 AS30 iBGP > 10.0.0.

0/8 30 40 > 10.0.0/16 10.0.0/16 10 AS30 iBGP > 10. Case-2 > 10.0.0.0.0.0/16 > 10.0.0.0/16 > 10.0.0.0/16 10 > 10. Hijacking .0.0/8 40 AS20 10.0.0.0.0/8 > 10.0.0/8 10.0.0.0.0.0/8 30 40 10.0/16 No Impact .0.0.0.0.0.0/8 10.0/16 30 20 10 10.0.0/8 i AS10 10.0.0.0.0.0.0.0.0/16 20 10 > 10.0/8 AS40 10.

0/16 AS40 10.0.0/16 10 * 10.0.0.0.0.0/16 10.0.0.0.0.0/16 > 10.0/16 10.0/16 i AS10 10.0/16 30 20 10 > 10.0. Hijacking .0.0/16 30 40 >10.0.0/16 10.0.0.0/16 Local Impact .0.0.0.0/16 10.0.0.0/16 10.0.0.0. Case-3 > 10.0.0/16 20 10 10.0.0.0/16 > 10.0.0.0.0.0.0/16 10 AS30 iBGP 10.0/16 40 AS20 10.0.0.

0/16 i AS20 10.0.0.0/16 Local Impact .0.0. Case-4 *> 10.0/16 10.0.0/16 10 AS30 10. Hijacking .0.0.0.0/16 iBGP 10.0.0.0.0.0/16 > 10.0.0/16 .0.0.0/16 10.0.0.0.0 10 10.0/16 30 10. 0 / 16 .0.0/16 10.0.0.0.0.0/16 > 10.0/16 30 i > 10.0.0.0.0.0.0/16 30 20 10 AS10 AS40 10. 0.0/16 10 i > 10.0.0.0.0/16 10.0.0/16 20 10 >10.

– Cyber Terrorism . Cause of Route Hijacking  Operational Fault – Automatic route advertisement – Configuration error • Filtering error (leaking local/private use address) • Fat finger ^^). (wrong address/mask)  Intentional Fault – Unfair use of IP address – For Spam/DDoS/Phishing….

2006/4 .Research of BGP Route Hijacking in Japan  Japanese Government (Ministry of Internal Affairs and Communications) research project – 4 year term .2010/3 – to develop detect/recover/protect function – NTT Communications in charge of this project  Telecom-ISAC Japan – Research by volunteers from Japanese ISPs – Activity of BGP working group since 2004 .

Longer Prefix advertise Routes only Protection .e. .Filtering Receive correct .  Recovery -IRR registry Start taking action: -Configuration file I.Functions of Anti-BGP route hijacking  Detection Detection Recovery Compare b/w Routing update and correct routing After detect the hijacking. registry IRR  Protection Agent/ Sensor Routing Info Lookup Registration + IRR LIST Lookup BGP Update .Check routing.

– Alerting by email or to your own syslog server  PHAS (Prefix Hijack Alert System) – UCLA – uses BGP data (with 3 hours' delay) from Oregon-Univ RouteViews – Checking origin. lasthop and sub-allocation set change – Alerting by email  IAR (Internet Alert Registry) – Using PGBGP (Pretty Good BGP) – Alerting by email or search on the web  ENCORE (an inter-AS diagnostic ENsemble system using COoperative REflector agents) – NTT Media Innovation Laboratories – Putting multi-point agents on Multi-AS. Monitoring owned prefixes on the agent – Alerting by email  Keiro-Bygyo (Route magistrate) – Telecom-ISAC Japan BGP-WG – Comparing local info (from IRR and manual maintain) and BGP UPDATE – Alerting by email .Detection systems in the World  RIPE NCC MyASN Service – A part of RIPE NCC RIS (Routing Information Service) – Checking a prefix is announced with an incorrect AS path.

Detection system Router IRR Looking Glass BGP Configure file BGP peer UPDATE -Prefix -Origin ASN -AS-Path : : Operator Alert  Monitoring BGP update – Having BGP peer with multiple Routers – Checking a prefix between last ASN in the AS path attribute announced by BGP and origin AS in IRR – When expected to hijack. syslog. SNMP trap etc . alerting by email.

Recovery flow  Checking extent of the impact – Global Impact? Local Impact?  Howto recover (temporary and permanent)? – Hijacking AS should stop advertising invalid route advertisement (permanent) – Request route filtering on infected AS (temporary) – Announce more specific route (temporary) .

0.0.128/25 10 * 10.0/25 10.0.0/25 20 10 * 10.0/25 10.0.0/25 * 10.0/24 40 * 10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0/16 AS20 10 10.0.0.0.0/24 30 40 * 10.128/25 10.0/25 10 AS30 iBGP * 10.0/16 10.0.0.0/16 10.0.0/24 i * 10.0/25 30 20 10 * 10.0.0.0.0/24 10.0.0.0.0.0/24 AS40 10.0.0/24 10.0.0.128/25 20 10 10.0/16 * 10.0.0.0.0/24 AS10 10.0.0/16 * 10.128/25 30 20 10 .0.0.0.0.0.0.0.0.128/25 10.0.0.0.0/16 20 10 * 10.0/24 10.0.0/25 10 * 10.0. Specific route advertisement * 10.0/16 10 * 10.128/25 10 10.0/24 30 40 * 10.0.0.0.0.0.0.0.128/25 10.0.0/16 30 20 10 * 10.0.0.

Recovery flow by Reverse Hijacking  Decision of advertise route(More Specific route)  IRR registry (option)  Request to upstream ISP for opening prefix route filtering  Start advertise Specific route (Specific prefix advertisement via upstream)  Checking the trouble resolution as temporary fix  Request to Hijacked AS  Stop advertisement from Hijacked AS  Stop advertisement of Reverse Hijacking route .

e. Problems of Recovery  Redundancy – Detection System/Email receipt address should have redundant  How to contact/request Hijacked AS – Don’t have direct connection (Customer/peer/Upstream ISPs) – Don’t know contact phone/email address  Problem of specific route advertisement – Upstream should open prefix filter(exact match) • Request based filter • IRR registry based filter – Convergence time for global recovery – Can’t accept specific route • ISP has route filtering policy i. /24 .

SANOG. then …. AFNOG …)  Specific route advertisement . IAR. PHAS.  Upstream ISP – Can contact their peers. JANOG. Useful tools for Recovery  Detection System – MyASN. ENCORE. BUGYO….  Operator community – nsp-security/nsp-security-xx – xNOG (NANOG.

Real Hijacking Case (1)  2004/6  Originatedfrom Japanese ISP  Longer prefix / Invalid origin – /24 x2. /25 x1. /29 x1  Detected 1/1 AS  Action – Contacted originated AS operator – Origin AS stopped invalid announcement  Impact : about 150 minutes .

Real Hijacking Case (2)  2004/9  Originatedfrom Korean ISP  Longer prefix / Invalid origin – /24 x 2  Detected 1/1 AS  Action – Escalate peer ISP • Filtering on peer ISP • Origin AS stop announcement  Impact : about 2 days .

Real Hijacking Case (3)  2005/2  Originatedfrom Japanese ISP  Longer prefix / Invalid origin – /22 x 1  Detected 1/1 AS  Action – Escalate peer ISP • Reverse Hijacking  Impact : about 1 hour .

Real Hijacking Case (4)  2006/11  Originatedfrom Korean ISP  Longer prefix / Invalid origin – /27 x 1  Detected 6/7 ASes on Keiro-Bugyo  Action – Couldn’t contact to origin AS operator. escalate own upstream ISP • Filtering on Upstream ISP first • Origin AS stop announcement  Impact: about 16 hours .

Real Hijacking Case (5)  2006/11  Originated from Indonesian ISP  Same prefix length / invalid origin – /17 x 2. /14 x 1  Detected 1/7 AS on Keiro-Bugyo  Action – Not have been taken any action (Withdrawn soon)  Impact : about 5 minutes  By after analysis. we found this AS originated many other invalid routes at the same time .

/30 x14  Detected just 1/7 AS on Keiro-Bugyo – Almost ISP at Keiro-Bugyo adopted the prefix-length filtering  Action – Contacted originated AS operator  Impact : about 23 minutes . Real Hijacking Case (6)  2006/12  Originatedfrom Japanese ISP  Longer prefix / Invalid origin – /32 x15.

if don’t have contact – More specific announcement can mitigate the impact as temporary solution .  Summary of these cases  Detection – Longer prefix Hijacking • /24 or shorter is almost easy to detect • /25 or longer is hard to detect – Depends on the ISP filtering policy – Same Prefix length Hijacking • Hard to detect – Many sensors in wide locations would be better  Recovery – It’s not takes long time (Less than 2 hours). if operators know contact (Peer/Local ISP) – Takes long time.

psBGP • Router should implement these protocol # Router CPU high-load . Protection Valid Route Invalid Route  Don’t received invalid route!! – What is valid and what is invalid – How to block invalid prefix?  Protection method – IRR base route validation • Guarantee origin AS • JPIRR (trial) Our research • Router lookup IRR (irrzebra is working) – BGP base route validation • Guarantee Origin AS and AS-PATH • sBGP. soBGP. pgBGP.

0/8 10 Authentication Process of Route Requirement of IRR  Operator  IRR system – registry IRR – Stable IRR system – Announce Valid Route prefix (Redundancy)  IRR – Performance – Authenticate by CA (JPNIC) – Scalability – Store valid Prefixes only – Secure mirroring  Router  (Valid) IRR data – lookup IRR registry – Filtering of invalid Route – Authenticate by CA .0.0/8 authority AS10 AS20 *> 10.0/8 Certificate : 10.0. IRR Based Protection Prefix Registry AS10 has IRR JPNIC 10.0/8 10.0.0.0.0.0.0.0.0.0.0/8 Validation 10.0.0/8 AS10 AS10 has Route announce Lookup 10.0.0/8 : Check Origin 10 10.0.0/8 AS20 50.0.0.

Idealized IRR System •Log management Management Management •Configuring •UI IRR X1 Sync IRR X2 Data management Object Object Object Object Mirror Mirror Mirror Mirror Lookup Lookup Registry Registry (Input) (Input) (Get) (Get) Other Other IRR Other IRR IRR A IRR B1 IRR B2 Lookup Register (Router/Operator) (Operator) “Reliability” and “Stability” needed .

JPIRR . APNIC  Merit IRRd RADB. Current IRR system  RIPE whoisd RIPE. VRR. other ISP’s IRR Items RIPE Whoisd Merit IRR Install method Compile from source Package install (PORTS) Structure Modularized Monolithic Data management RDBMS (MySQL) Text file Object registry Mail.3 2006/11/6 . Web (other tool) Mail.3.0 2005/5/25 Irrd-2. Web (other tool) Mirroring protocol NRTM NRTM RPSL correspondense RPSLng (RFC4012) RPSLng (RFC4012) Error check Strict (Sequence check) Loose System Scalability Yes (RDBMS) No Backup mechanism No No Latest version Whoisd-3.3.

Syntax check (1) Constructing DB (3) Radix ripupdate IP address search . RIPE whoisd Ready for registry (0) object .Radix tree update tree -DB update (2) (5) (4) Data management mysql whoisd (6) (7) object (0) Object registry by Operator (1) Send Object to ripupdate for Database constructing Registry (2) Update “MySQL Database” Process (3) Constructing “Radix Tree” (4) Whois query (5) Check address (IP Prefix check) Lookup (6) Database search Process (7) Whois reply .Authentication dbupdate .

RIPE whoisd redundancy (1) machine1 (0) object dbupdate (1) machine2 Radix Radix Tree is (3) Radix ripupdate ripupdate tree tree not updated (2) (6) (7) (5) mysql whoisd mysql whoisd (4) No Object Clustering (NDB Cluster) (0) Object registry by Operator (1) Send Object to ripupdate for Database constructing Registry (2) Update “MySQL Database” Process (3) Constructing “Radix Tree” (4) Database sync (5) Whois query Lookup (6) Check address (IP Prefix check) Process (7) Database search .

RIPE whoisd redundancy (2) machine1 (0) object dbupdate (1) (1) machine2 (3) (3) Radix Radix ripupdate ripupdate tree tree (2) (6) (7) (5) mysql whoisd mysql whoisd (4) object Clustering (NDB Cluster) (0) Object registry by Operator (1) Send Object to ripupdate for Database constructing Registry (2) Update “MySQL Database” Process (3) Constructing “Radix Tree” (4) Database sync (5) Whois query Lookup (6) Check address (IP Prefix check) Process (7) Database search .

web) Clustering (1) Sanity check. determine actions (2) Send objects to ripupdate (3) INSERT. DELETE from database mysql (4) Fetch updated data from DB (5) Check update periodically Machine2 (6) Send updates to NRTM client (master STB) (7) Update Radix Tree (8) Updates Radix Tree and store data into local DB (9) Reply for users’ queries . RIPE whoisd redundancy (3) machine1(master ACT) (0) object dbupdate (2) (1) machine3 (Lookup) Whoisd (7) Radix ripupdate (5) (NRTM tree (3) client) Whoisd (4) (6) (8) (9) (NRTM mysql mysql server) object NDB (0) Objects registration (mail. UPDATE.

Current Issues of our IRR system  Performance – Memory issue 4G is not enough for NDB cluster ---> change configuration – Radix Tree issue More than 5 minutes for booting ---> Service interruption by blocking – Scalability • Clustering with many server • Redundancy b/w far location  Field trial – IRR lookup function will be separate – Redundancy test b/w Tokyo and Osaka  Router implementation – 4byte ASN support… – Should start talking with NIR/RIRs and Vender .

but /25 or longer is hard to detect – Same Prefix length Hijacking is hard to detect – Many sensors in wide locations would be better  Recovery – It’s not takes long time . if don’t have contact – More specific announcement can mitigate the impact as temporary solution  Protection – IRR base route validation. we are using customized RIPE whoisd – We will start field trial and we doing routing implementation . we need stable / redundant IRR – For scalability. Summary  Detection – Longer prefix Hijacking is almost easy to detect. if operators know contact – Takes long time.

Kimura. Special Thanks  Telecom-ISAC BGP-WG  JPNIC – Mr. Mr. Okada  NTT Communications – Anti-Route Hijacking team .

co. Reference  RIPE/NCC http://www.cs.netsec.jp/ja/materials/irr/20051207/kimura-20051207.jp/meeting/janog19/2007/01/_meets_jpirr.colostate.ripe.unm.pdf  NSP-SEC http://puck.net/myasn.gr.nether.jp/mirai/organization/organization0204.html  Merit http://www.ntt.nether.net/  PHAS http://phas.html (Japanese only)  JANOG http://www.html  JPNIC http://jpnic.jp/ (Japanese only) .telecom-isac.edu/  IAR http://www.edu/~karlinjf/IAR/  NTT Media Innovation Laboratories http://www.ris.janog.net/mailman/listinfo/nsp-security-jp (Japanese only)  Telecom-ISAC (Keiro Bugyo) https://www.irr.net/mailman/listinfo/nsp-security  NSP-SEC-JP http://puck.

Thank you Taka Mizuguchi Tomoya Yoshida .