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

11/23/2006France Telecom2 Outline Routing security Secure Routing

11/23/2006France Telecom3 Internet (1969 ~ ) Basic datagram service between one IP address and another

11/23/2006France Telecom4 Internet (1969 ~ ) Basic datagram service between one IP address and another The End2End Principle

11/23/2006France Telecom5 Internet (1969 ~ ) Basic datagram service between one IP address and another The End2End Principle AB IPsec Tunneling, MobileIP…

11/23/2006France Telecom6 Internet (1969 ~ ) Basic datagram service between one IP address and another Routing is quite straightforward!

11/23/2006France Telecom7 Internet (1969 ~ ) Basic datagram service between one IP address and another Routing: exchanging the information regarding the address space and how to reach them. –Routing versus Forwarding

11/23/2006France Telecom8 Internet (1969 ~ ) Basic datagram service between one IP address and another 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

11/23/2006France Telecom9 Internet Infrastructure It enables many cool applications. – , Web+, IM, Skype, Google, Bittorrent, Infospace, LinkedIn,...

11/23/2006France Telecom10 Internet Infrastructure It enables many cool applications. – , Web+, IM, Skype, Google, Bittorrent, Infospace, LinkedIn,... We are connected, at least in the “IP address” sense!!

11/23/2006France Telecom11 Internet Infrastructure It enables many cool applications. – , 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?

11/23/2006France Telecom12 “BGP” Border Gateway Protocol –the inter-domain routing protocol for the Internet

11/23/2006France Telecom13 “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 /16 UCDavis: /16 AS6192

11/23/2006France Telecom14 “BGP” How would I let the whole world know about /16? –I announce that I owned /16 More importantly, how would anybody else in the Internet know how to send (or route, forward) a IP packet to /16? –Others would know how to send packets to /16 – UCDavis: /16 AS6192

11/23/2006France Telecom15 Peering ASes UCDavis: /16 AS6192AS11423 (UC) AS11537 (CENIC) AS513 Peering is a local/decentralized trust based on a business contract!

11/23/2006France Telecom16 AS6192 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /

11/23/2006France Telecom17 AS6192  AS11423 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /  6192

11/23/2006France Telecom18 AS11423  AS11537 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /   6192

11/23/2006France Telecom19 AS11537  AS513 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /    6192

11/23/2006France Telecom20 Packet Forwarding UCDavis: /16 AS6192AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /    6192

11/23/2006France Telecom21 The Scale of the “Internet”

11/23/2006France Telecom22 The Scale of the “Internet” Autonomous Systems 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 prefixes to the right destination. BGP is the protocol to support the exchange of routing information for ALL prefixes in ALL ASes.

11/23/2006France Telecom23 The “Internet”

11/23/2006France Telecom24 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)

11/23/2006France Telecom25 “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!!

11/23/2006France Telecom26 “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….

11/23/2006France Telecom27 BGP Security Issues

11/23/2006France Telecom28 Origin AS in an AS Path UCDavis (AS-6192) owns /16 and AS-6192 is the origin AS AS Path: 513    6192 – – – – – – – – – – –

11/23/2006France Telecom29 Trust in BGP Updates UCDavis: /16 AS513 an AS Path: /    6192 An BGP Update message consists of a sequence of local trust relations. But, how to form the global trust?

11/23/2006France Telecom30 Security of BGP Authentication/validation of BGP update messages AS513 an AS Path: /    6192 How to validate? What to trust?

11/23/2006France Telecom31 Trust Model in BGP?? AS513 an AS Path: /    6192

11/23/2006France Telecom32 Remember… Internet, based on the E2E argument, has to be simple… BGP has to be simple… Security & trust has to be simple…

11/23/2006France Telecom33 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…

11/23/2006France Telecom34 Trust Model in BGP Naïve/unconditional trust AS513 an AS Path: /    6192

11/23/2006France Telecom35 The bad news is… The Internet community (e.g., IETF, Cisco, AT&T, and their similar) won’t fix the Internet until it breaks

11/23/2006France Telecom36 And, the real good news is… The Internet community (e.g., IETF, Cisco, AT&T, and their similar) won’t fix the Internet until it breaks

11/23/2006France Telecom37 And, the real good news is… The Internet community (e.g., IETF, Cisco, AT&T, and their similar) won’t fix the Internet until it breaks Internet will break!! –It has broken a few times GLOBALLY!!

11/23/2006France Telecom38 “BGP” How would I let the whole world know about /16? –I announce that I owned /16 More importantly, how would anybody else in the Internet know how to send (or route, forward) a IP packet to /16? –Others would know how to send packets to /16 – UCDavis: /16 AS6192

11/23/2006France Telecom39 “BGP” How would I let the whole world know about /16? –I announce that I owned /16 –Prefix hijacking More importantly, how would anybody else in the Internet know how to send (or route, forward) a IP packet to /16? –Others would know how to send packets to /16 – UCDavis: /16 AS6192

11/23/2006France Telecom40 Origin AS Changes (OASC) Ownership: UCDavis (AS-6192) owns /16 and AS-6192 is the origin AS Current –AS Path: 2914  209   6192 –for prefix: / /16

11/23/2006France Telecom41 Origin AS Changes (OASC) Ownership: UCDavis (AS-6192) owns /16 and AS-6192 is the origin AS Current –AS Path: 2914  209   6192 –for prefix: /16 New –AS Path: 2914  3011  273  81 –even worse: / / /24

11/23/2006France Telecom42 Origin AS Changes (OASC) Ownership: UCDavis (AS-6192) owns /16 and AS-6192 is the origin AS Current –AS Path: 2914  209   6192 –for prefix: /16 New –AS Path: 2914  3011  273  81 –even worse: /24 Which route path to use? / /24

11/23/2006France Telecom43 Origin AS Changes (OASC) Ownership: UCDavis (AS-6192) owns /16 and AS-6192 is the origin AS Current –AS Path: 2914  209   6192 –for prefix: /16 New –AS Path: 2914  3011  273  81 –even worse: /24 Which route path to use? Legitimate or Abnormal?? / /24

11/23/2006France Telecom44 Let’s extend it a little bit…

11/23/2006France Telecom45 Internet Global Failures AS7007 falsely de-aggregates network prefixes in 1997 and the east coast Internet was down for 12 hours. AS6192AS11423 (UC) AS11537 (CENIC) AS / / /24 …. Black Hole

11/23/2006France Telecom46 Active BGP Entries

11/23/2006France Telecom47 Active BGP Entries

11/23/2006France Telecom48 Active BGP Entries

11/23/2006France Telecom49 Internet Global Failures How to fix it? AS6192AS11423 (UC) AS11537 (CENIC) AS / / /24 …. Black Hole

11/23/2006France Telecom50 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.

11/23/2006France Telecom51 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…

11/23/2006France Telecom52 Origin AS Changes (OASC) Ownership: UCDavis (AS-6192) owns /16 and AS-6192 is the origin AS Current –AS Path: 2914  209   6192 –for prefix: /16 New –AS Path: 2914  3011  273  81 –even worse: /24 Which route path to use? Legitimate or Abnormal?? It won’t help if a specific prefix is hijacked!! / /24

11/23/2006France Telecom53 BGP MOAS/OASC Events (IMW’2001, Explanation  DSOM’2003) Max: (9177 from a single AS)

11/23/2006France Telecom54 Real-Time OASC Detection Low level events:BGP Route Updates High level events:OASC –1000+ per day and max per day –per 3-minutes window in real-time demo IP address blocks Origin AS in BGP Update Messages Different Types of OASC Events

11/23/2006France Telecom AS# Qua-Tree Representation of IP Address Prefixes / /16

11/23/2006France Telecom AS# AS# Representation AS-1 AS-7777 AS AS-6192 AS-81

11/23/2006France Telecom57 AS81 punched a “hole” on /16 yesterday /16 today / /24 yesterday AS-6192 today AS-81 victim offender

11/23/2006France Telecom58 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

11/23/2006France Telecom59 “Normal”

11/23/2006France Telecom60 AS15412 in April, 2001

11/23/2006France Telecom61 April 6, 2001 AS15412 caused 40K+ MOAS/OASC events within 2 weeks…

11/23/2006France Telecom62 April 7-10, /07/2001 all04/07/ /08/2001 all04/08/ /09/2001 all04/09/ /10/2001 all04/10/

11/23/2006France Telecom63 April 11-14, /11/2001 all04/11/ /12/2001 all04/12/ /14/2001 all04/14/ /13/ /13/2001 all

11/23/2006France Telecom64 April 18-19, 2001 – Again?? 04/18/2001 all04/18/ /19/2001 all04/19/

11/23/2006France Telecom65 How to authenticate or validate? Authentication/validation of BGP update messages AS513 an AS Path: /    6192

11/23/2006France Telecom66 SBGP PKI Every relationship is certified by related ASes (with some certificates issued by the CA).

11/23/2006France Telecom67 Peering ASes UCDavis: /16 AS6192AS11423 (UC) AS11537 (CENIC) AS513

11/23/2006France Telecom68 AS6192  AS11423 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /  6192

11/23/2006France Telecom69 AS11423  AS11537 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /   6192

11/23/2006France Telecom70 AS11537  AS513 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /    6192

11/23/2006France Telecom71 PKI and Global Trust Certificates for everyone and everything Verification through a chain of trust relationship

11/23/2006France Telecom72 PKI and Global Trust Certificates for everyone and everything Verification through a chain of trust relationship BUT  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 Service Trust Service  Internet

11/23/2006France Telecom73 SoBGP Distributed Registry –Checking for Topology relationship Similar to DNS (and many others) –Checking for binding between IP address and name

11/23/2006France Telecom74 SoBGP Authentication/validation of BGP update messages AS513 an AS Path: /    6192 AS6192 owns /16 AS6192 peers with AS11423 AS11423 peers with AS11537 AS11537 peers with AS513

11/23/2006France Telecom75 SoBGP Authentication/validation of BGP update messages AS513 an AS Path: /    6192 AS6192 owns /16 AS6192 peers with AS11423 AS11423 peers with AS11537 AS11537 peers with AS513

11/23/2006France Telecom76 Peering ASes UCDavis: /16 AS6192AS11423 (UC) AS11537 (CENIC) AS513 AS6192 owns /16 AS6192 peers with AS11423 AS11423 peers with AS11537 AS11537 peers with AS513

11/23/2006France Telecom77 AS6192  AS11423 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /  6192 AS6192 owns /16 AS6192 peers with AS11423 AS11423 peers with AS11537 AS11537 peers with AS513

11/23/2006France Telecom78 AS11423  AS11537 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /   6192 AS6192 owns /16 AS6192 peers with AS11423 AS11423 peers with AS11537 AS11537 peers with AS513

11/23/2006France Telecom79 AS11537  AS513 UCDavis: /16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: /    6192 AS6192 owns /16 AS6192 peers with AS11423 AS11423 peers with AS11537 AS11537 peers with AS513

11/23/2006France Telecom80 AS6192 owns /16 AS6192 peers with AS11423 AS11423 peers with AS11537 AS11537 peers with AS513

11/23/2006France Telecom81 SBGP vs SoBGP What is the difference?

11/23/2006France Telecom82 AS6192 owns /16 AS6192 peers with AS11423 AS11423 peers with AS11537 AS11537 peers with AS513

11/23/2006France Telecom83

11/23/2006France Telecom84 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.

11/23/2006France Telecom85 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 ( ), Le Discours de la Méthode, Quatrieme Partie

11/23/2006France Telecom86 Origin AS Changes (OASC) Ownership: UCDavis (AS-6192) owns /16 and AS-6192 is the origin AS Current –AS Path: 2914  209   6192 –for prefix: /16 New –AS Path: 2914  3011  273  81 –For prefix: / /16

11/23/2006France Telecom87 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?

11/23/2006France Telecom88 Descartes BGP Collaborative Conflict Detection and Resolution, while some of the collaborators might be malicious… Every IP prefix: AgreementConflict Persistent Conflict

11/23/2006France Telecom89 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.

11/23/2006France Telecom90 Byzantine/Persistent Failures Very expensive to prevent/eliminate –You will need the ground truth!!

11/23/2006France Telecom91 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.

11/23/2006France Telecom92 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

11/23/2006France Telecom93 Descartes BGP AS-6192AS /16 AgreementConflict Persistent Conflict

11/23/2006France Telecom /16

11/23/2006France Telecom /16

11/23/2006France Telecom /16

11/23/2006France Telecom /16

11/23/2006France Telecom /16

11/23/2006France Telecom /16 Traffic Split Line

11/23/2006France Telecom100 Detectability & Detector Which ASes can detect the conflict? Which ASes should raise the flag?

11/23/2006France Telecom101 Who can detect??

11/23/2006France Telecom102 Who can detect??

11/23/2006France Telecom103 Who can detect??

11/23/2006France Telecom104 Detector Who should be the detector?

11/23/2006France Telecom /   273     6192 Minimizing the detectors

11/23/2006France Telecom106 Detector The AS detects the conflict and will not use the new conflicting BGP update

11/23/2006France Telecom /   273     6192 Detector /16

11/23/2006France Telecom108 Self-Stabilization Detection –Who should detect it? Conflict resolution –Who can possibly verify better than the detector?

11/23/2006France Telecom /  273    6192 Detector /16 Checker

11/23/2006France Telecom /16 Local configuration and resolution If the checkers don’t care, nobody else will. AgreementConflict Persistent Conflict

11/23/2006France Telecom111 Assuming AS81 is faulty AS6192 (checker) confirms with local routing policies for /16. AS81 (checker) realizes that it made a mistake  withdraw.

11/23/2006France Telecom /  273    6192 Detector /16 Checker

11/23/2006France Telecom /  273    6192 Detector /16 CheckerAbnormal

11/23/2006France Telecom114 Self-Stabilization Transient/Simple Faults

11/23/2006France Telecom115 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.

11/23/2006France Telecom /  273    6192 Detector /16 Checker Who should the Network trust? Skeptical “Shared” Trust

11/23/2006France Telecom117 Persistent Conflict How to resolve?

11/23/2006France Telecom118 Management The right information to the management plane Before the issue is “completely” resolved, the Internet still operates to provide the basic service.

11/23/2006France Telecom /16 Detector Checker

11/23/2006France Telecom / /17 Detector Checker /17

11/23/2006France Telecom121 IP Prefix P/n n Network bits32 – n host bits IP Header address restoration bit b Local Decision 0 or 1 Outbound at source AS Inbound at destination AS

11/23/2006France Telecom122 Descartes BGP Recovery All the ASes between AS81 & AS6192 are aware of the persistent conflict for /16. No further new BGP prefix announcement under /16 (e.g., /24) until the persistent conflict is removed by management plane. Application-level IP address re-mapping, based on some trust, is required.

11/23/2006France Telecom123 Conflict Detection prefix

11/23/2006France Telecom124 Conflict Resolution ? ? prefix

11/23/2006France Telecom125 Persistent Conflict ? ? prefix

11/23/2006France Telecom126 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.

11/23/2006France Telecom127 # of Detectors AS (30,088 affected prefixes) 933 detectors totally Average 8.88 per prefix AS-3549 detected 77%

11/23/2006France Telecom /16 NCTU,Taiwan 2001/04/06/5pm GMT

11/23/2006France Telecom /16 NCTU,Taiwan 2001/04/07/1am GMT Fault Line

11/23/2006France Telecom BGP msg 73 BGP msg

11/23/2006France Telecom BGP msg 40 D-BGP msg

11/23/2006France Telecom132 Descartes BGP the principle of ABCD A: Anomalous Advertiser B: Blocker C: Checker D: Detector

11/23/2006France Telecom133 Routing Security  Secure Routing Routing security –Make sure the basic IP service work correctly! Secure Routing –Enhance Internet security via a better routing service!

11/23/2006France Telecom134 Internet Infrastructure It enables many cool applications. – , Web+, IM, Skype, Google, Bittorrent, Infospace, LinkedIn,... We are connected, at least in the “IP address” sense!!

11/23/2006France Telecom135 Internet Infrastructure It enables many cool applications. – , Web+, IM, Skype, Google, Bittorrent, Infospace, LinkedIn,... We are connected, at least in the “IP address” sense!! Many other forms of connections: –Peer2Peer, Friend2Friend, community

11/23/2006France Telecom136 Internet Infrastructure It enables many cool applications. It enables many cool attacks.

11/23/2006France Telecom137 Internet Infrastructure It enables many cool applications. It enables many cool attacks. –David Clark on Morris Worms to DARPA in 1988

11/23/2006France Telecom138 Internet Infrastructure It enables many cool applications. It enables many cool attacks. –David Clark on Morris Worms to DARPA in 1988 “Internet is doing exactly what it supposed to do”

11/23/2006France Telecom139 We can not blame everything to Microsoft! It enables many cool applications. It enables many cool attacks. –Worm, DDoS, spamming, phishing,… (the list is still growing)

11/23/2006France Telecom140 We can not blame everything to Microsoft! It enables many cool applications. It enables many cool attacks. –Worm, DDoS, spamming, phishing,… (the list is still growing) Related to our Inter-domain routing today…

11/23/2006France Telecom141 We can not blame everything to Microsoft! It enables many cool applications. It enables many cool attacks. –Worm, DDoS, spamming, phishing,… (the list is still growing) AB Is “end2end security” the right abstraction?

11/23/2006France Telecom142 It enables many cool applications. It enables many cool attacks. –Worm, DDoS, spamming, phishing,… (the list is still growing) –Spyware (I mainly blame Microsoft for this, but can we do something in the Internet infrastructure to ensure the information accountability across domains?) We can not blame everything to Microsoft!

11/23/2006France Telecom143 “BGP” How would I let the whole world know about /16? –I announce that I owned /16 –Prefix hijacking More importantly, how would anybody else in the Internet know how to send (or route, forward) a IP packet to /16? –Others would know how to send packets to /16 – UCDavis: /16 AS6192

11/23/2006France Telecom144 “BGP” How would I let the whole world know about /16? –I announce that I owned /16 –Prefix hijacking More importantly, how would anybody else in the Internet know how to send (or route, forward) a IP packet to /16? –Others would know how to send packets to /16 –DDoS, Spam – no receiver/owner controllability UCDavis: /16 AS6192

11/23/2006France Telecom145 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 AB AB F F F

11/23/2006France Telecom146 The same message content “M” from Felix Wu “M” from Felix Wu via an IETF mailing list “M” from Felix Wu via Herve Debar

11/23/2006France Telecom147 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?

11/23/2006France Telecom148 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 AB AB F F F

11/23/2006France Telecom149 Social Routers

11/23/2006France Telecom150 Social Routers Proxy

11/23/2006France Telecom151 Social Router Identity Identity: an X-bits string with a public key

11/23/2006France Telecom152 Social Router Identity Identity: an X-bits string with 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.

11/23/2006France Telecom153 Go beyond HIP Host Identity Protocol –Separation of host identity and routable addresses

11/23/2006France Telecom154 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!

11/23/2006France Telecom155 A Social Link representing a trust relationship

11/23/2006France Telecom156 A Social Link representing a trust relationship Without a social link, messages will be either dropped or lower prioritized in the “networking” layer

11/23/2006France Telecom157 A Social Link representing a trust relationship The link can be revoked or downgraded at any time!

11/23/2006France Telecom158 Social Keywords Soccer, BGP, Davis, California, Intrusion Detection,…

11/23/2006France Telecom159 Social Keywords Soccer, BGP, Davis, California, Intrusion Detection,… Social keywords represents your interests and the semantic/social interpretation of you (and your identity).

11/23/2006France Telecom160 Social Keywords BGP, Intrusion Detection Soccer, Davis, California

11/23/2006France Telecom161 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!

11/23/2006France Telecom162 Incoming Route Discovery Messages Soccer, BGP, Davis, California, Intrusion Detection, Liechtenstein AND/OR expression Soccer, BGP, Davis, California, Intrusion Detection, Liechtenstein

11/23/2006France Telecom163 Incoming Route Discovery Messages Soccer, BGP, Davis, California, Intrusion Detection, Liechtenstein AND/OR expression Soccer, BGP, Davis, California, Intrusion Detection, Liechtenstein + a few extra { a bag of expected words} Accepted or not??

11/23/2006France Telecom164 Routing Information Exchange AND/OR expressions of keywords

11/23/2006France Telecom165 Scalable, scalable, scalable??? 40 billions of ASes or nodes “Lots” of keywords and keyword expressions

11/23/2006France Telecom166 Keyword Aggregation AND/OR expressions of keywords

11/23/2006France Telecom167 Limited Resources

11/23/2006France Telecom168 M Keywords and aggregated keywords “content addressable s”

11/23/2006France Telecom169 DSL Route Discovery & Trust Management DSL Forwarding Plane

11/23/2006France Telecom170 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…