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

[email protected]://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

A B

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”


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

12654

6192

11423

2091153733564637

2914701835493333


Trust in BGP Updates

UCDavis:169.237/16

AS513

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

AS513

an AS Path:169.237/16 5131153711423 6192

How to validate? What to trust?


Trust Model in BGP??

AS513

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

AS513

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…



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

12654

6192

11423

209

2914

169.237/16





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

12654

6192

11423

2093011

273

2914

81

169.237/16169.237.6/24






• Which route path to use?

12654

6192

11423

2093011

273

2914

81

169.237/16169.237.6/24






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

12654

6192

11423

2093011

273

2914

81

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

12654

6192

11423

2093011

273

2914

81

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


1101

1000

1001

110001110011111001111011

110000110010111000111010

00110110

AS#

Qua-Tree Representation ofIP Address Prefixes

169.237/1610101001.11101101/16


1101

1000

1001

110001110011111001111011

110000110010111000111010

00110110AS#

AS# Representation

AS-1

AS-7777

AS-15412

AS-6192

AS-81


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?


AS513

an AS Path:169.237/16 5131153711423 6192


SBGP

• 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


SoBGP

• Distributed Registry– Checking for Topology relationship

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

and name


SoBGP


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

12654

6192

11423

2093011

273

2914

81

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



12654

6192

11423

2093011

273

2914

81

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

6192114232093011273 291481

6192114232093011273 291481

6192114232093011273 291481


Detector

• Who should be the detector?

6192114232093011273 291481


6192114232093011273 291481

169.237/16

81

27381

301127381

6192

114236192

209114236192

Minimizing the detectors


Detector

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

6192114232093011273 291481


6192114232093011273 291481

169.237/16

81

27381

301127381

6192

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…





A B

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

A B

A BF

FF


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

A B

A BF

FF


Social Routers


Social Routers

Proxy


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

.

.

.

.


M

.

.

.

.

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