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.0.0.0/24 40 i .0/16 40 i  Sub-prefix Hijack – Valid: 10.0.0/16 10 i – Invalid: 10.0.0.0. Type of Route Hijacking  Prefix Hijack – Valid: 10.0/16 10 i – Invalid: 10.0.

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. but filtered on peering link – Detection is hard  No impact – Invalid shorter prefix advertisement – Detection is easy – Short lived BGP For spam/DoS sending.

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

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

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

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

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

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 .Research of BGP Route Hijacking in Japan  Japanese Government (Ministry of Internal Affairs and Communications) research project – 4 year term .

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

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

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

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/16 20 10 * 10.0.0.0.0.0.128/25 30 20 10 .0.0/25 * 10.0.0.0/24 30 40 * 10.0.0/24 10.0.128/25 10.0.0/24 i * 10.0.0.0.0.0.0/24 10.0.0.128/25 10.0.0/24 AS10 10.0/25 30 20 10 * 10.0.0/16 30 20 10 * 10.0/25 10.0/16 AS20 10 10.0.0/25 20 10 * 10.0/16 * 10.0.0. Specific route advertisement * 10.0.0.0.0.0/24 10.0.0.0.0.0.0/16 * 10.0/24 40 * 10.0.128/25 10 10.0/16 10 * 10.0.0.0.0.0.0.0.0.0.0/25 10.0.0.0.0.0.0.0.0.0.0.0.0/25 10 AS30 iBGP * 10.0.0/24 30 40 * 10.0.0.0/16 10.0/25 10 * 10.0.0.0/24 AS40 10.128/25 10.0.128/25 10 * 10.0/16 10.0.128/25 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. /24 . 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.

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

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.

 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.

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

0/8 10.0/8 Certificate : 10.0.0.0.0/8 : Check Origin 10 10.0.0/8 AS10 AS10 has Route announce Lookup 10.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 Validation 10.0.0.0. IRR Based Protection Prefix Registry AS10 has IRR JPNIC 10.0.0/8 AS20 50.0.0.0.0.0.0/8 authority AS10 AS20 *> 10.0.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 .

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 . APNIC  Merit IRRd RADB.3.3. JPIRR . Web (other tool) Mail. 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. VRR. Current IRR system  RIPE whoisd RIPE.0 2005/5/25 Irrd-2.

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 .Syntax check (1) Constructing DB (3) Radix ripupdate IP address search .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 .

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

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 .

if don’t have contact – More specific announcement can mitigate the impact as temporary solution  Protection – IRR base route validation. if operators know contact – Takes long time. 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 . Summary  Detection – Longer prefix Hijacking is almost easy to detect. we are using customized RIPE whoisd – We will start field trial and we doing routing implementation . we need stable / redundant IRR – For scalability.

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

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

Thank you Taka Mizuguchi Tomoya Yoshida .