Internet Routing Security: Past, Current, and Future S. Felix Wu Computer Science Department...

Internet Routing Security: Past, Current, and Future

S. Felix WuComputer Science DepartmentUniversity of California, Davis

wu@cs.ucdavis.eduhttp://www.cs.ucdavis.edu/~wu/

11/23/2006 France Telecom 2

Outline

• Routing security• Secure Routing

Internet (1969 ~ )

• Basic datagram service between one IP address and another

Internet (1969 ~ )

• The End2End Principle

Internet (1969 ~ )

• The End2End Principle

IPsec Tunneling, MobileIP…

Internet (1969 ~ )

• Routing is quite straightforward!

Internet (1969 ~ )

• Routing: exchanging the information regarding the address space and how to reach them.– Routing versus Forwarding

Internet (1969 ~ )

• Routing: exchanging the information regarding the address space and how to reach them.

• Applications built on top of the services– QoS over the Internet, still a challenge

Internet Infrastructure

• It enables many cool applications.– Email, Web+, IM, Skype, Google, Bittorrent,

Infospace, LinkedIn,...

• We are connected, at least in the “IP address” sense!!

• Who is the “hero” to make all these possible?

“BGP”

• Border Gateway Protocol– the inter-domain routing protocol for the

Internet

“BGP”

• Autonomous System (AS):– A set of routers owned by one single system

administrative domain

• Address Prefix:

• Example:– AS6192 consists of routers in UC Davis– UC Davis owns 169.237/16

UCDavis:169.237/16

AS6192

“BGP”

• How would I let the whole world know about 169.237/16?– I announce that I owned 169.237/16

• More importantly, how would anybody else in the Internet know how to send (or route, forward) a IP packet to 169.237/16?– Others would know how to send packets to

169.237/16–

UCDavis:169.237/16

AS6192

Peering ASes

UCDavis:169.237/16

AS6192 AS11423 (UC)

AS11537 (CENIC)AS513

Peering is a local/decentralized trust based on a business contract!

AS6192

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 6192

AS6192 AS11423

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 11423 6192

AS11423 AS11537

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 1153711423 6192

AS11537 AS513

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 5131153711423 6192

Packet Forwarding

UCDavis:169.237/16

AS6192 AS11423 (UC)

an AS Path:169.237/16 5131153711423 6192

The Scale of the “Internet”

• 20464 Autonomous Systems• 167138 IP Address Prefixes announced

• Every single prefix, and their “dynamics”, must be propagated to every single AS.

• Every single AS must maintain the routing table such that it knows how to route the traffic toward any one of the 167138 prefixes to the right destination.

• BGP is the protocol to support the exchange of routing information for ALL prefixes in ALL ASes.

The “Internet”

Semi-Good News

• Aggregation works (or worked)!

• An existing issue:– Multi-homing is countering the effort

though.

• A new issue:– Routing on Flat-Labels (ROFL)

“Not so sure” news

• No hierarchy, no infrastructure, no tier-one service providers, no government censorship, no centralized managed DNS, no google, … and no nothing!!

“Not so sure” news

• No hierarchy, no infrastructure, no tier-one service providers, no government censorship, no centralized managed DNS, no google, … and no nothing!!

• And, we expect Internet works much better than today:– 40 billions nodes/ASes– The whole Internet is a giant Sensor

network

And, yet it needs to be scalable in every measure….

BGP Security Issues

Origin AS in an AS Path

• UCDavis (AS-6192) owns 169.237/16 and AS-6192 is the origin AS

• AS Path: 5131153711423 6192– 12654 13129 6461 3356 11423 6192– 12654 9177 3320 209 11423 6192– 12654 4608 1221 4637 11423 6192– 12654 777 2497 209 11423 6192– 12654 3549 3356 11423 6192– 12654 3257 3356 11423 6192– 12654 1103 11537 11423 6192– 12654 3333 3356 11423 6192– 12654 7018 209 11423 6192– 12654 2914 209 11423 6192– 12654 3549 209 11423 6192

2091153733564637

2914701835493333

Trust in BGP Updates

UCDavis:169.237/16

an AS Path:169.237/16 5131153711423 6192

An BGP Update message consists of a sequence of local trust relations. But, how to form the global trust?

Security of BGP

• Authentication/validation of BGP update messages

an AS Path:169.237/16 5131153711423 6192

How to validate? What to trust?

Trust Model in BGP??

an AS Path:169.237/16 5131153711423 6192

Remember…

• Internet, based on the E2E argument, has to be simple…

• BGP has to be simple…• Security & trust has to be simple…

Remember…

• Internet, based on the E2E argument, has to be simple…

• BGP has to be simple.• Security & trust has to be simple.• And, our minds have to be simple…

Trust Model in BGP

• Naïve/unconditional trust

an AS Path:169.237/16 5131153711423 6192

The bad news is…

• The Internet community (e.g., IETF, Cisco, AT&T, and their similar) won’t fix the Internet until it breaks

And, the real good news is…

• Internet will break!!– It has broken a few times GLOBALLY!!

“BGP”

• How would I let the whole world know about 169.237/16?– I announce that I owned 169.237/16

169.237/16–

UCDavis:169.237/16

AS6192

“BGP”

• How would I let the whole world know about 169.237/16?– I announce that I owned 169.237/16– Prefix hijacking

169.237/16–

UCDavis:169.237/16

AS6192

Origin AS Changes (OASC)

• Ownership: UCDavis (AS-6192) owns 169.237/16 and AS-6192 is the origin AS

• Current– AS Path: 291420911423 6192– for prefix: 169.237/16

169.237/16

• New– AS Path: 29143011273 81– even worse: 169.237.6/24

2093011

169.237/16169.237.6/24

• Which route path to use?

2093011

169.237/16169.237.6/24

• Which route path to use?• Legitimate or Abnormal??

2093011

169.237/16169.237.6/24

Let’s extend it a little bit…

Internet Global Failures

• AS7007 falsely de-aggregates 65000+ network prefixes in 1997 and the east coast Internet was down for 12 hours.

AS6192 AS11423 (UC)

169.237/16142.7.6/24204.5.68/24….

Black Hole

Active BGP Entries

Internet Global Failures

• How to fix it?

AS6192 AS11423 (UC)

169.237/16142.7.6/24204.5.68/24….

Black Hole

New Prefix Rate-limiting

• For any given time window, a BGP peer can only introduce a X number of new IP prefixes.

• But, tier-1 ISPs will not be rate-limited.

New Prefix Rate-limiting

• For any given time window, a BGP peer can only introduce a X number of new IP prefixes.

• But, tier-1 ISPs will not be rate-limited.• It worked/works, but…

• Which route path to use?• Legitimate or Abnormal??

• It won’t help if a specific prefix is hijacked!!

2093011

169.237/16169.237.6/24

BGP MOAS/OASC Events(IMW’2001, Explanation DSOM’2003)

year Median number increase rate #BGP table entries increase rate1998 683 520001999 810.5 18.7% 60000 15.40%2000 951 17.3% 80000 33.30%2001 1294 34.8% 109000 36%

Max: 10226(9177 from a single AS)

Real-Time OASC Detection

• Low level events: BGP Route Updates• High level events: OASC

– 1000+ per day and max 10226 per day– per 3-minutes window in real-time demo

• IP address blocks• Origin AS in BGP Update Messages• Different Types of OASC Events

110001110011111001111011

110000110010111000111010

00110110

Qua-Tree Representation ofIP Address Prefixes

169.237/1610101001.11101101/16

110001110011111001111011

110000110010111000111010

00110110AS#

AS# Representation

AS-7777

AS-15412

AS-6192

AS81 punched a “hole” on 169.237/16

yesterday169.237/16

today169.237/16169.237.6/24

yesterdayAS-6192

todayAS-81

victim

offender

OASC Event Types

• Using different colors to represent types of OASC events

• C type: CSS, CSM, CMS, CMM• H type: H• B type: B• O type: OS, OM

“Normal”

AS15412 in April, 2001

April 6, 2001

AS15412 caused 40K+ MOAS/OASC events within 2 weeks…

April 7-10, 2001

04/07/2001 all 04/07/2001 15412 04/08/2001 all 04/08/2001 15412

04/09/2001 all 04/09/2001 15412 04/10/2001 all 04/10/2001 15412

April 11-14, 2001

04/11/2001 all 04/11/2001 15412 04/12/2001 all 04/12/2001 15412

04/14/2001 all 04/14/2001 1541204/13/2001 1541204/13/2001 all

April 18-19, 2001 – Again??

04/18/2001 all 04/18/2001 15412 04/19/2001 all 04/19/2001 15412

How to authenticate or validate?

an AS Path:169.237/16 5131153711423 6192

• PKI• Every relationship is certified by related

ASes (with some certificates issued by the CA).

Peering ASes

UCDavis:169.237/16

AS6192 AS11423 (UC)

AS6192 AS11423

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 11423 6192

AS11423 AS11537

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 1153711423 6192

AS11537 AS513

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 5131153711423 6192

PKI and Global Trust

• Certificates for everyone and everything• Verification through a chain of trust

relationship

PKI and Global Trust

• Certificates for everyone and everything• Verification through a chain of trust relationshipBUT Is it reasonable to have a global PKI or any weaker

form of centralized trust servers?Chicken and Egg problem:

which infrastructure depends on which?Internet Trust ServiceTrust Service Internet

• Distributed Registry– Checking for Topology relationship

• Similar to DNS (and many others)– Checking for binding between IP address

and name

AS513an AS Path:169.237/16 5131153711423 6192

AS6192 owns 169.237/16AS6192 peers with AS11423AS11423 peers with AS11537AS11537 peers with AS513

AS513an AS Path:169.237/16 5131153711423 6192

AS6192 owns 169.237/16AS6192 peers with AS11423AS11423 peers with AS11537AS11537 peers with AS513

Peering ASes

UCDavis:169.237/16

AS6192 AS11423 (UC)

AS6192 owns 169.237/16AS6192 peers with AS11423

AS11423 peers with AS11537AS11537 peers with AS513

AS6192 AS11423

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 11423 6192

AS11423 AS11537

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 1153711423 6192

AS11537 AS513

UCDavis:169.237/16

AS6192

AS11423 (UC)

an AS Path:169.237/16 5131153711423 6192AS6192 owns 169.237/16

AS11537 peers with AS513

SBGP vs SoBGP

• What is the difference?

Verification/Validation for the Truth

• Verifying the truth about the routing information

• SoBGP or SBGP

• But, MOAS/OASC:– Inherently, they assume that if EVERYTHING

has been verified, then MOAS/OASC is irrelevant.

Descartes BGP

• A Conflict Detection and Response Framework for Inter-Domain Routing

«au contraire de cela, même que je pensais à douter de la vérité des autres choses, il suivait très évidemment et très certainement que j'étais.»

“to the contrary, in the very act of thinking about doubting the truth of other things, it very clearly and certainly followed that I existed.”

- René Descartes (1596-1650), Le Discours de la Méthode, Quatrieme Partie

• New– AS Path: 29143011273 81– For prefix: 169.237/16

2093011

169.237/16

Origin AS Change

• Without ANY centrally managed service– DNS, PKI, BGP Certificate Authority– That is the spirit of Inter-domain Internet

• Without ANY global management!

• We do NOT know which one is correct or incorrect as the ground truth ANSWER is not being provided!– We don’t have the oracle…

• Then, how do we deal with this problem?

Descartes BGP

• Collaborative Conflict Detection and Resolution, while some of the collaborators might be malicious…

• Every IP prefix:

Agreement ConflictPersistentConflict

Prevention vs. Tolerance

• No invalid route will be allowed.– SBGP

• The system can still work, to a certain degree, even with one or more invalid routes.

Byzantine/Persistent Failures

• Very expensive to prevent/eliminate– You will need the ground truth!!

Byzantine/Persistent Failures

• Very expensive to prevent/eliminate– You will need the ground truth!!

• An alternative approach:– We can NOT completely eliminate certain

faults.– But, those faults can not completely

eliminate our service as well.

Conflict

• Ground Truth about a prefix absolute– must rely on some centralized services

• Conflict relative– Two peers disagree but we don’t know

which one is right

Descartes BGP

AS-6192 AS-81

169.237/16169.237/16

2093011

169.237/16

6192114232093011273 291481

169.237/16

6192114232093011273 291481

169.237/16

6192114232093011273 291481

169.237/16

6192114232093011273 291481

169.237/16

6192114232093011273 291481

169.237/16

Traffic Split Line

Detectability & Detector

• Which ASes can detect the conflict?• Which ASes should raise the flag?

Who can detect??

6192114232093011273 291481

Who can detect??

6192114232093011273 291481

Who can detect??

6192114232093011273 291481

Detector

• Who should be the detector?

6192114232093011273 291481

169.237/16

301127381

114236192

209114236192

Minimizing the detectors

Detector

• The AS detects the conflict and will not use the new conflicting BGP update.

6192114232093011273 291481

169.237/16

301127381

114236192

209114236192

Detector

169.237/16

Self-Stabilization

• Detection– Who should detect it?

• Conflict resolution– Who can possibly verify better than the

detector?

6192114232093011273 291481

169.237/16

301127381

209114236192

Detector

169.237/16

CheckerChecker

6192 81

169.237/16

Local configuration and resolution

If the checkers don’t care, nobody else will.

Assuming AS81 is faulty

• AS6192 (checker) confirms with local routing policies for 169.237/16.

• AS81 (checker) realizes that it made a mistake withdraw.

6192114232093011273 291481

169.237/16

301127381

209114236192

Detector

169.237/16

CheckerChecker

6192114232093011273 291481

169.237/16

301127381

209114236192

Detector

169.237/16

CheckerAbnormal

Self-Stabilization

• Transient/Simple Faults

But, what happens…

• AS81 disagrees that it is at fault!– It even believes that AS6192 is faulty.– The basic service will NOT know the answer– We really need “outside” help to resolve the

problem “completely”.

• But, the basic service should still operate as much as possible before the resolution.

6192114232093011273 291481

169.237/16

301127381

209114236192

Detector

169.237/16

CheckerChecker

Who should the Network trust?

Skeptical“Shared” Trust

Persistent Conflict

• How to resolve?

Management

• The right information to the management plane

• Before the issue is “completely” resolved, the Internet still operates to provide the basic service.

6192114232093011273 291481

169.237/16

Detector

CheckerChecker

6192114232093011273 291481

169.237.0/17

169.237.128/17

Detector

CheckerChecker

169.237.128/17

IP Prefix P/n

n Network bits 32 – n host bits

IP Header

address restoration bitb

Local Decision

0 or 1Outbound at source AS

Inbound at destination AS

Descartes BGP Recovery

• All the ASes between AS81 & AS6192 are aware of the persistent conflict for 169.237/16.

• No further new BGP prefix announcement under 169.237/16 (e.g., 169.237.6/24) until the persistent conflict is removed by management plane.

• Application-level IP address re-mapping, based on some trust, is required.

Conflict Detection

prefix

Conflict Resolution

prefix

Persistent Conflict

prefix

Robustness against Persistent Fault

• The faults can not be eliminated completely– Due to no ground truth within the basic

service!

• But, the faults can not completely eliminate the basic service either!!– We will still have enough/some bandwidth to

run SNMP, DNS, and PKI, for instance.

# of Detectors

• AS-15412 (30,088 affected prefixes)

• 933 detectors totally• Average 8.88 per prefix• AS-3549 detected 77%

140.113.0.0/16 NCTU,Taiwan2001/04/06/5pm GMT

140.113.0.0/16 NCTU,Taiwan2001/04/07/1am GMT

Fault Line

73 BGP msg73 BGP msg

83 BGP msg83 BGP msg40 D-BGP msg40 D-BGP msg

Descartes BGPthe principle of ABCD

• A: Anomalous Advertiser• B: Blocker• C: Checker• D: Detector

Routing SecuritySecure Routing

• Routing security– Make sure the basic IP service work

correctly!

• Secure Routing– Enhance Internet security via a better

routing service!

• Many other forms of connections:– Peer2Peer, Friend2Friend, community

• It enables many cool applications.• It enables many cool attacks.

– David Clark on Morris Worms to DARPA in 1988

– David Clark on Morris Worms to DARPA in 1988 “Internet is doing exactly what it supposed to do”

We can not blame everything to Microsoft!

– Worm, DDoS, spamming, phishing,… (the list is still growing)

Related to our Inter-domain routing today…

Is “end2end security” the right abstraction?

– Spyware (I mainly blame Microsoft for this, but can we do something in the Internet infrastructure to ensure the information accountability across domains?)

“BGP”

169.237/16–

UCDavis:169.237/16

AS6192

“BGP”

169.237/16– DDoS, Spam – no receiver/owner controllability

UCDavis:169.237/16

AS6192

DSL (Davis Social Links)

Principle:– Communication should reflect the (social)

relationship between the sender and the receiver, and the receiver should have ways to control that.

Design:– Route discovery based on social keywords

and their potential aggregation– Separation of identity and routability– Penalty and Reputation framework

The same message content

• “M” from Felix Wu

• “M” from Felix Wu via an IETF mailing list

• “M” from Felix Wu via Herve Debar

The same message content

• “M” from Felix Wu Probably a spam• “M” from Felix Wu via an IETF mailing

list Probably not interesting• “M” from Felix Wu via Herve Debar Do I seriously want to keep the job?

This is nothing new!

Principle:– Communication should reflect the (social)

relationship between the sender and the receiver, and the receiver should have ways to control that.

Design:– Route discovery based on social keywords

and their potential aggregation– Separation of identity and routability– Penalty and Reputation framework

Social Routers

Social Router Identity

Identity: an X-bits stringwith a public key

Social Router Identity

Identity: an X-bits stringwith a public key

The identity doesn’t have to be globally unique.

There are many “Felix Wu” in this world, but Herve won’t be confused under different social contexts.

Go beyond HIP

• Host Identity Protocol– Separation of host identity and routable

addresses

Go beyond HIP

• Host Identity Protocol– Separation of host identity and routable

addresses

• Host Person/Object• “Identification” should be an application

issue.• Routing only provides services to

forward packets to the IP address which can be mapped to the identity by the application!

A Social Link

representing a trust relationship

A Social Link

Without a social link, messages will be either dropped or lower prioritized in the “networking” layer

A Social Link

The link can be revoked or downgraded at any time!

Social Keywords

Soccer, BGP, Davis, California, Intrusion Detection,…

Social Keywords

Soccer, BGP, Davis, California, Intrusion Detection,…

Social keywords represents your interests and the semantic/social interpretation of you (and your identity).

Social Keywords

BGP, Intrusion Detection

Soccer, Davis, California

Social Keywords

Soccer, BGP, Davis, California, Intrusion Detection, Liechtenstein

Social keywords represents your interests and the semantic/social interpretation of you (and your identity).Sometimes, it can be anything you like!

Incoming Route Discovery Messages

AND/OR expression

Incoming Route Discovery Messages

AND/OR expression

Soccer, BGP, Davis, California, Intrusion Detection, Liechtenstein+ a few extra

{ a bag of expected words}

Accepted or not??

Routing Information Exchange

AND/OR expressions of keywords

Scalable, scalable, scalable???

• 40 billions of ASes or nodes• “Lots” of keywords and keyword

expressions

Keyword Aggregation

AND/OR expressions of keywords

Limited Resources

Keywords and aggregated keywords

“content addressable emails”

DSL Route Discovery& Trust Management

DSL Forwarding Plane

Remarks

• Routing security involves several complex issues without good definitive answers..

• We should really think about “communication” first, and then worry about the best routing framework to support it.– E.g., P2P applications, hijacking, fairness, spam,

phishing, penalty, matching with social networks, identity and receiver control…

Internet Routing Security: Past, Current, and Future S. Felix Wu Computer Science Department...

Documents

Transcript of Internet Routing Security: Past, Current, and Future S. Felix Wu Computer Science Department...

01/04/2006ecs236 winter 20061 Intrusion Detection ecs236 Winter 2006: Intrusion Detection #2: Vulnerability Analysis Dr. S. Felix Wu Computer Science Department.

APDNews - apage.org · Felix Zano Manila, ... Anthony Wu, GBS, JP, Chairman of the Hospital Authority, Hong Kong. ... cover.pdf Author: allenbad Created Date:

Davis Social Links FIND: Facebook-based INternet Design S. Felix Wu Computer Science Department University of California, Davis wu@cs.ucdavis.edu .

NC STATE UNIVERSITY / MCNC Protecting Network Quality of Service Against Denial of Service Attacks Douglas S. Reeves S. Felix Wu Fengmin Gong Talk:

Materials Technology - Overview · Materials Technology - Overview. June 6, 2016. Felix Wu ... between physical properties, mechanical properties, ... and testing procedures for magnesium

Software Analysis Tools Felix Wu University of Hong Kong Northeast Asian Power Grid Interconnection Shenzhen ， May 7, 2002.

A MapReduce-Based Maximum-Flow Algorithm for Large Small-World Network Graphs Felix Halim, Roland H.C. Yap, Yongzheng Wu.

Minos: A Tool for Capturing and Analyzing Novel Worms for Unknown Vulnerabilities Jedidiah R. Crandall Frederic T. Chong, Zhendong Su, S. Felix Wu Computer.

Atmospheric monitoring of CO2 emissions: an innovative ... Wu... · Atmospheric monitoring of CO2 emissions: an innovative solution for cities Lin Wu, Grégoire Broquet, Felix Vogel,

ECS129 Information and Fluctuations of Information Patrice Koehl E-mail: koehl@cs.ucdavis.edu.

1 Davis Social Links S. Felix Wu Computer Science Department University of California, Davis wu@cs.ucdavis.edu wu

Estimating the Size of Online Social Networks Shaozhi Ye* S. Felix Wu

1 Davis Social Links Social Network Kernel for Future Internet Design Norm Matloff, Michael Neff, S. Felix Wu, Computer Science Diane Felmlee Sociology.

02/15/2007ecs2361 Tracing & Traceability S. Felix Wu UC Davis wu wu@cs.ucdavis.edu.

04/05/20011 ecs298k: Routing in General... lecture #2 Dr. S. Felix Wu Computer Science Department University of California, Davis wu

04/12/2006ecs150 Spring 20061 Operating System ecs150 Spring 2006 : Operating System #2: Scheduling and Mutual Exclusion (chapter 4) Dr. S. Felix Wu Computer.

04/03/2001ecs298k spring 20011 lecture #1 ecs298k: Internet Architecture lecture #1 Dr. S. Felix Wu Computer Science Department University of California,

1 Tools and techniques for understanding and defending real systems Jedidiah R. Crandall crandall@cs.ucdavis.edu.

Stepping Stone Tracing and IDS Evaluation S. Felix Wu Computer Science Department University of California, Davis.

Positional Normalization - Cornell Vision Pages...Positional Normalization Boyi Li 1;2, Felix Wu , Kilian Q. Weinberger , Serge Belongie1;2 1Cornell University 2Cornell Tech {bl728,