Securing the Internet Routing System, One Network at a Time

1
Securing the Internet Routing System, One Network
at a Time

• Jennifer Rexford
• Princeton University

2
The Internet
Internet
3
The Internet is a Network of Networks

• Around 40,000 separately administered networks
• Competitive cooperation of Autonomous Systems

4
Local Control vs. Global Properties
Local Control Intradomain routing, interdomain
policies
Global Properties Performance, security,
reliability, scalability
5
The Glue That Holds the Internet Together
6
Interdomain Routing

• Work together to reach remote destinations
• No global knowledge, and no common goal
• ASes share information, and make local decisions

1
7
Border Gateway Protocol (BGP)

• Announce paths
• AS announces a path to a destination address
• Each AS adds itself to the front of the path
• Apply local policy
• Decide which path to select
• Decide which neighbors to tell

d path (2,1)
d path (1)
3
1
data traffic
data traffic
d
8
Flexible Policies

• Each node can apply local policies
• Path selection Which path to use?
• Path export Which paths to advertise?
• Examples
• Node 2 may prefer the path 2, 3, 1 over 2, 1
• Node 1 may not let node 3 hear the path 1, 2

9
Business Relationships Between ASes

• Neighboring ASes have business contracts
• How much traffic to carry
• Which destinations to reach
• How much money to pay
• Common business relationships
• Customer-provider
• Peer-peer
• Backup
• Sibling

10
Customer-Provider Relationship

• Customer needs to be reachable from everyone
• Provider ensures all neighbors can reach the
  customer
• Customer does not want to provide transit service
• Customer does not let its providers send traffic
  through it

Traffic to the customer
Traffic from the customer
d
provider
provider
traffic
customer
d
customer
11
Peer-Peer Relationship

• Peers exchange traffic between customers
• AS lets its peer reach (only) its customers
• AS can reach its peers customers
• Often the relationship is settlement-free (i.e.,
  no )

Traffic to/from the peer and its customers
peer
peer
traffic
d
12
AS Structure Tier-1 Providers

• Top of the Internet hierarchy
• Has no upstream provider of its own
• Typically has a large (inter)national backbone
• Around 10 ASes ATT, Sprint, Level 3,

peer-peer
peer-peer
peer-peer
peer-peer
13
AS Structure Other ASes

• Lower-layer providers (tier-2, )
• Provide transit service to downstream customers
• But need at least one provider of their own
• Typically have national or regional scope
• E.g., Minnesota Regional Network
• Includes a few thousand ASes
• Stub ASes
• Do not provide transit service
• Connect to upstream provider(s)
• Most ASes (e.g., 85-90)

14
Interdomain Security Vulnerabilities
15
Hijacking an Address Block
d
d
AS 1 can drop the traffic, impersonate the
destination, send spam,
16
Hijacking Part of an Address Block
d
d
All ASes direct traffic to the more specific
destination
17
Smart Attacks Forging the AS Path

• Try to look legitimate
• E.g., attacker forges a link to the real
  destination AS

d
(6 d)
18
Smart Attacks Path-Shortening Attacks

• Remove ASes from the AS path
• E.g., turn 701 3715 88 into 701 88
• Motivations
• Make the AS path look shorter than it is
• Attract sources that normally try to avoid AS
  3715
• Help AS 88 look like it is closer to the
  Internets core
• Who can tell that this AS path is a lie?
• Maybe AS 88 does connect to AS 701 directly

701
3715
88
?
19
Interception (Man in the Middle) Attacks
d
d
AS 1 can intercept the traffic en route to the
real destination
20
Two High-Profile Examples

• Pakistan Telecom hijack of YouTube
• China Telecom interception of 15 of Internet

21
February 24, 2008, YouTube Outage

• YouTube (AS 36561)
• Web site www.youtube.com
• IP address block 208.65.152.0/22
• Pakistan Telecom (AS 17557)
• Receives government order to block access to
  YouTube
• Starts announcing 208.65.153.0/24 to PCCW (AS
  3491)
• All traffic directed to YouTube gets dropped
• Mistakes were made
• AS 17557 announcing to everyone, not just
  customers
• AS 3491 not filtering routes announced by AS
  17557
• Lasted 100 minutes for some, 2 hours for others

22
Timeline (UTC Time)

• 184745
• First evidence of hijacked /24 route propagating
  in Asia
• 184800
• Several big trans-Pacific providers carrying the
  route
• 184930
• Bogus route fully propagated
• 200725
• YouTube starts advertising the /24 to attract
  traffic back
• 200830
• Many (but not all) providers are using the valid
  route

http//www.renesys.com/blog/2008/02/pakistan_hijac
ks_youtube_1.shtml
23
Timeline (UTC Time)

• 201843
• YouTube starts announcing two more-specific /25
  routes
• 201937
• Some more providers start using the /25 routes
• 205059
• AS 17557 starts prepending (3491 17557 17557)
• 205939
• AS 3491 disconnects AS 17557
• 210000
• All is well, videos of cats flushing toilets are
  available

http//www.renesys.com/blog/2008/02/pakistan_hijac
ks_youtube_1.shtml
24
April 8, 2010, China Telecom Interception

• Around 50,000 address blocks
• Addresses in 170 different countries
• Including 16,000 blocks in U.S. (including
  government)
• Small part of China Telecom (AS 23724)
• Announced the 50,000 address blocks
• While retaining a legitimate path to the
  destinations
• Mistakes were made
• AS 23724 announcing address blocks it does not
  own
• AS 4134 not filtering routes announced by AS
  23724
• Intercepted a portion of the traffic
• For a period of about 18 minutes

25
Global Impact of the Interception
http//www.renesys.com/blog/2010/11/chinas-18-minu
te-mystery.shtml
26
Lessons From the Examples

• BGP is incredibly vulnerable
• Local actions have serious global consequences
• Propagating misinformation is surprisingly easy
• Fixing the problem required vigilance
• Monitoring to detect and diagnose the problem
• Immediate action to (try to) attract the traffic
  back
• Longer-term cooperation to block/disable the
  attack
• Preventing these problems is even harder
• Require all ASes to perform defensive filtering?
• Automatically detect and stop bogus route?
• Require proof of ownership of the address block?

27
Securing Interdomain Routing
28
Challenges to Securing BGP

• The protocol was designed based on trust
• Lying is easy, and it works!
• BGP is often misconfigured
• New network operators who make mistakes
• Fat fingering easily leads to incorrect
  messages
• Good security relies on wide participation
• Maintaining an accurate registry of address
  ownership
• Switching to a secure variant of BGP
• Solutions need to be incrementally deployable
• Backwards compatibility works with existing
  protocols?
• Incentives provides benefits to early adopters?

29
Three Main Approaches

• Defensive filtering
• AS filters update messages from neighbors
• E.g., address ownership, unexpected AS path, etc.
• Not very effective for routes originated far away
• Anomaly detection
• Monitor BGP update messages and detect anomalies
• Report anomalies, or even filter/depreference the
  routes
• Incrementally deployable and reasonably effective
• Secure extensions to BGP
• Require originating AS to prove it owns the
  addresses
• Cryptographically signing the BGP update messages

30
Anomaly Detection Flagging Bogus Routes

• Build a view of correct announcements
• Prefix ownership (e.g., AS 88 owns
  128.112.0.0/16)
• AS-level edges or sub-paths (e.g., Sprint
  provides transit for ATT to Ebone, so 7018 1239
  1755 is valid)
• Ways to construct this view
• Regional Internet Registry data
• Past history of BGP update messages
• Flag BGP announcements in violation
• IAR http//iar.cs.unm.edu/
• PHAS http//phas.netsec.colostate.edu/
• http//cyclops.cs.ucla.edu/
• Network operators learn about problems quickly

31
Anomaly Detection Avoiding Bogus Routes

• Detection after the fact may be too late
• Many attacks are short-lived (e.g.,
  misconfiguration)
• Doesnt take long to snoop, do identity theft,
  etc.
• Better to avoid bogus routes in the first place
• Detect anomalous routes in real time
• Prefer normal routes over anomalous ones

32
Anomaly Detection Partial Deployment

• Anomaly detection works in partial deployment
• Even a single AS can avoid bogus routes
• Implementable as a change to BGP decision process
• Especially useful if deployed by large ISPs
• Large ASes learn many routes for each prefix
• More likely to have at least one normal route
• Large ASes disseminate routes to others
• Even non-participating ASes benefit significantly
• Participants could be even more aggressive!
• Hijack the hijacker by announcing each others
  prefixes
• and directing traffic to the legitimate
  destination

33
Secure BGP

• Origin Authentication
• Claim the right to originate a address block
• Signed and distributed out-of-band
• Checked through delegation chain from ICANN
• Public Key Infrastructure approach
• Path Verification
• Validates that the AS path really indicates
• the order of ASes traversed by the
  announcement
• Uses digital signatures and public key
  infrastructure

33
34
Route Attestations in Secure BGP
If AS a announced path abP then b announced bP to
a
Public Key Infrastructure
Princeton
ATT
IBM
Local ISP
Comcast
Public Key Signature Anyone who knows IBMs
public key can verify the message was sent by IBM.
35
Secure BGP Deployment Challenge

• Complete, accurate registries
• E.g., of ownership of address blocks
• Public Key Infrastructure
• To know the public key for any given AS
• Efficiency issues
• E.g., route attestations make BGP messages longer
• Need to compute public key operations quickly
• Difficulty of incremental deployment
• Hard to have a flag day to deploy S-BGP
• Expensive (and useless) for a single node to
  upgrade

35
36
Incentivizing Secure BGP Deployment

• Let the market drive S-BGP deployment
• Help participating ASes make more money
• By attracting more revenue-generating traffic
• Secure ASes break ties in favor of secure paths
• Participants are 1, 3, and 4
• So, 1 prefers (1 3 4) over (1 2 4)
• So, AS 2 makes less
• And wants to participate!
• Secure ASes not harmed
• Still consider business andperformance concerns
  first!

1
2
3
4
d
http//www.cs.bu.edu/fac/goldbe/papers/sbgpTrans.h
tml
37
Market-Driven Deployment

• A few ASes are early adopters of S-BGP
• E.g., a handful of large Internet Service
  Providers
• Perhaps subsidized by the government
• Participating ASes consider security
• As a tie-breaking step when selecting routes
• Boot-strapping stub customers with simplex
  S-BGP
• Other ASes have an incentive to adopt
• To attract back the traffic lost to their
  competitors
• Take advantage of economic incentives and the
  topological structure of the Internet!

38
Stepping Back

• The Internet routing system is very vulnerable
• Built on an assumption of trust
• Local actions have global consequences
• These concerns are not merely hypothetical
• Several major high-profile outages
• Malicious actors can cause major headaches
• Rational actors have economic incentives to cheat
• Most proposed solutions are hard to deploy
• Defensive filtering, anomaly detection, secure
  protocols
• Incremental deployment is the key
• Clear security and economic benefits to adopters

39
Backup Slides
40
Data-Plane Attacks
41
Saying One Thing, Doing Another

• Interdomain routing security
• An AS cannot announce a route it did not receive
• The list of ASes in the path did send the BGP
  message
• But, an AS can say one thing and do another
• An AS learns multiple ways to reach a destination
• An AS can announce one path, but use another