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.

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

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 .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.

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

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

0.0.0.0.0/16 30 20 10 > 10.0.0.0/16 20 10 10.0.0/16 10.0.0.0/16 10 AS30 iBGP 10.0.0.0/16 AS40 10.0/16 10.0.0.0/16 10.0.0/16 Local Impact .0/16 10.0/16 > 10. Case-3 > 10.0.0.0.0.0.0.0.0/16 40 AS20 10.0.0/16 10.0.0.0/16 30 40 >10.0/16 i AS10 10.0.0/16 10 * 10.0/16 > 10. Hijacking .0.0.0.0.0.0.0.

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

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

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 . 2006/4 .

Filtering Receive correct .Check routing.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 .Longer Prefix advertise Routes only Protection .  Recovery -IRR registry Start taking action: -Configuration file I.e.

– 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. 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. 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.

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. SNMP trap etc . alerting by email. syslog.

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/24 30 40 * 10.0.0.0.0.0/25 10.0.0.0.0.0/16 AS20 10 10.0. Specific route advertisement * 10.0/24 i * 10.0/25 * 10.0.0.0.0.128/25 10.0/25 20 10 * 10.0.0/24 10.0.0.0/16 10.0/24 AS10 10.0.0.128/25 10 10.0.0.0.0.0.0.0/16 30 20 10 * 10.0.0.0.0.128/25 10.0.0/24 40 * 10.0.0.0.0.0/16 10 * 10.0/24 AS40 10.0.0.0/25 10 * 10.0.0.0.0.0.0.0.0/16 * 10.0.0.0/16 * 10.0/16 10.0.0.0/24 10.0.0.0.128/25 10 * 10.0.0/25 30 20 10 * 10.0.0.0/25 10.0/16 20 10 * 10.0.0.0.0/25 10 AS30 iBGP * 10.128/25 30 20 10 .0/24 30 40 * 10.128/25 20 10 10.128/25 10.0.0.0.0/24 10.0.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 .

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.e. /24 .

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

/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 (1)  2004/6  Originatedfrom Japanese ISP  Longer prefix / Invalid origin – /24 x2.

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 .

escalate own upstream ISP • Filtering on Upstream ISP first • Origin AS stop announcement  Impact: about 16 hours . 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.

/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 . Real Hijacking Case (5)  2006/11  Originated from Indonesian ISP  Same prefix length / invalid origin – /17 x 2.

/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.

 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 don’t have contact – More specific announcement can mitigate the impact as temporary solution . if operators know contact (Peer/Local ISP) – Takes long time.

soBGP. 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. pgBGP. psBGP • Router should implement these protocol # Router CPU high-load .

0.0/8 Certificate : 10.0.0. IRR Based Protection Prefix Registry AS10 has IRR JPNIC 10.0.0.0/8 : Check Origin 10 10.0.0/8 authority AS10 AS20 *> 10.0.0.0/8 Validation 10.0/8 AS20 50.0.0.0.0/8 10.0.0.0.0.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/8 AS10 AS10 has Route announce Lookup 10.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 .0 2005/5/25 Irrd-2. VRR. 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. 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 .3.3. APNIC  Merit IRRd RADB. Web (other tool) Mail. Current IRR system  RIPE whoisd RIPE.

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 .

determine actions (2) Send objects to ripupdate (3) INSERT. UPDATE. web) Clustering (1) Sanity check. 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. 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 .

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. Summary  Detection – Longer prefix Hijacking is almost easy to detect. we need stable / redundant IRR – For scalability. we are using customized RIPE whoisd – We will start field trial and we doing routing implementation . if operators know contact – Takes long time.

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

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

Thank you Taka Mizuguchi Tomoya Yoshida .