1. Internet Routing Security: Past, Current, and Future S. Felix Wu Computer Science Department University of California, Davis wu@cs.ucdavis.edu http://www.cs.ucdavis.edu/~wu/

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

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

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

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

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

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

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

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

10. 11/23/2006France Telecom10 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!!

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

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

13. 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 169.237/16 UCDavis: 169.237/16 AS6192

14. 11/23/2006France Telecom14 “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

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

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

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

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

19. 11/23/2006France Telecom19 AS11537  AS513 UCDavis: 169.237/16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: 169.237/16 513  11537  11423  6192

20. 11/23/2006France Telecom20 Packet Forwarding UCDavis: 169.237/16 AS6192AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: 169.237/16 513  11537  11423  6192

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

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

23. 11/23/2006France Telecom23 The “Internet”

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

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

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

27. 11/23/2006France Telecom27 BGP Security Issues

28. 11/23/2006France Telecom28 Origin AS in an AS Path UCDavis (AS-6192) owns 169.237/16 and AS-6192 is the origin AS AS Path: 513  11537  11423  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

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

30. 11/23/2006France Telecom30 Security of BGP Authentication/validation of BGP update messages AS513 an AS Path: 169.237/16 513  11537  11423  6192 How to validate? What to trust?

31. 11/23/2006France Telecom31 Trust Model in BGP?? AS513 an AS Path: 169.237/16 513  11537  11423  6192

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

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

34. 11/23/2006France Telecom34 Trust Model in BGP Naïve/unconditional trust AS513 an AS Path: 169.237/16 513  11537  11423  6192

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

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

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

38. 11/23/2006France Telecom38 “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

39. 11/23/2006France Telecom39 “BGP” How would I let the whole world know about 169.237/16? –I announce that I owned 169.237/16 –Prefix hijacking 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

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

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

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

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

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

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

46. 11/23/2006France Telecom46 Active BGP Entries

47. 11/23/2006France Telecom47 Active BGP Entries

48. 11/23/2006France Telecom48 Active BGP Entries

49. 11/23/2006France Telecom49 Internet Global Failures How to fix it? AS6192AS11423 (UC) AS11537 (CENIC) AS513 169.237/16 142.7.6/24 204.5.68/24 …. Black Hole

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

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

52. 11/23/2006France Telecom52 Origin AS Changes (OASC) Ownership: UCDavis (AS-6192) owns 169.237/16 and AS-6192 is the origin AS Current –AS Path: 2914  209  11423  6192 –for prefix: 169.237/16 New –AS Path: 2914  3011  273  81 –even worse: 169.237.6/24 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/16 169.237.6/24

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

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

55. 11/23/2006France Telecom55 1101 1000 1001 110001110011111001111011 110000110010111000111010 00110110 AS# Qua-Tree Representation of IP Address Prefixes 169.237/16 10101001.11101101/16

56. 11/23/2006France Telecom56 1101 1000 1001 110001110011111001111011 110000110010111000111010 00110110 AS# AS# Representation AS-1 AS-7777 AS-15412 AS-6192 AS-81

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

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

59. 11/23/2006France Telecom59 “Normal”

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

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

62. 11/23/2006France Telecom62 April 7-10, 2001 04/07/2001 all04/07/2001 1541204/08/2001 all04/08/2001 1541204/09/2001 all04/09/2001 1541204/10/2001 all04/10/2001 15412

63. 11/23/2006France Telecom63 April 11-14, 2001 04/11/2001 all04/11/2001 1541204/12/2001 all04/12/2001 15412 04/14/2001 all04/14/2001 1541204/13/2001 1541204/13/2001 all

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

65. 11/23/2006France Telecom65 How to authenticate or validate? Authentication/validation of BGP update messages AS513 an AS Path: 169.237/16 513  11537  11423  6192

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

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

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

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

70. 11/23/2006France Telecom70 AS11537  AS513 UCDavis: 169.237/16 AS6192 AS11423 (UC) AS11537 (CENIC) AS513 an AS Path: 169.237/16 513  11537  11423  6192

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

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

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

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

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

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

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

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

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

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

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

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

83. 11/23/2006France Telecom83

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

85. 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 (1596-1650), Le Discours de la Méthode, Quatrieme Partie

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

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

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

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

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

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

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

93. 11/23/2006France Telecom93 Descartes BGP AS-6192AS-81 169.237/16 AgreementConflict Persistent Conflict

94. 11/23/2006France Telecom94 12654 6192 11423 2093011 273 2914 81 169.237/16

95. 11/23/2006France Telecom95 6192114232093011273291481 169.237/16

96. 11/23/2006France Telecom96 6192114232093011273291481 169.237/16

97. 11/23/2006France Telecom97 6192114232093011273291481 169.237/16

98. 11/23/2006France Telecom98 6192114232093011273291481 169.237/16

99. 11/23/2006France Telecom99 6192114232093011273291481 169.237/16 Traffic Split Line

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

101. 11/23/2006France Telecom101 Who can detect?? 6192114232093011273291481 6192114232093011273291481 6192114232093011273291481 6192114232093011273291481

102. 11/23/2006France Telecom102 Who can detect?? 619211423209 3011273 2914 81 619211423209 3011273 2914 81 619211423209 3011273 2914 81 619211423209 3011273 2914 81

103. 11/23/2006France Telecom103 Who can detect?? 619211423209 3011273291481 619211423209 3011273291481 619211423209 3011273291481 619211423209 3011273291481

104. 11/23/2006France Telecom104 Detector Who should be the detector? 619211423209 3011273291481

105. 11/23/2006France Telecom105 6192114232093011273291481 169.237/16 81 273  81 3011  273  81 6192 11423  6192 209  11423  6192 Minimizing the detectors

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

107. 11/23/2006France Telecom107 6192114232093011273291481 169.237/16 81 273  81 3011  273  81 6192 11423  6192 209  11423  6192 Detector 169.237/16

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

109. 11/23/2006France Telecom109 6192114232093011273291481 169.237/16 3011  273  81 209  11423  6192 Detector 169.237/16 Checker

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

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

112. 11/23/2006France Telecom112 6192114232093011273291481 169.237/16 3011  273  81 209  11423  6192 Detector 169.237/16 Checker

113. 11/23/2006France Telecom113 6192114232093011273291481 169.237/16 3011  273  81 209  11423  6192 Detector 169.237/16 CheckerAbnormal

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

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

116. 11/23/2006France Telecom116 6192114232093011273291481 169.237/16 3011  273  81 209  11423  6192 Detector 169.237/16 Checker Who should the Network trust? Skeptical “Shared” Trust

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

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

119. 11/23/2006France Telecom119 6192114232093011273291481 169.237/16 Detector Checker

120. 11/23/2006France Telecom120 6192114232093011273291481 169.237.0/17 169.237.128/17 Detector Checker 169.237.128/17

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

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

123. 11/23/2006France Telecom123 Conflict Detection prefix

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

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

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

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

128. 11/23/2006France Telecom128 140.113.0.0/16 NCTU,Taiwan 2001/04/06/5pm GMT

129. 11/23/2006France Telecom129 140.113.0.0/16 NCTU,Taiwan 2001/04/07/1am GMT Fault Line

130. 11/23/2006France Telecom130 73 BGP msg 73 BGP msg

131. 11/23/2006France Telecom131 83 BGP msg 40 D-BGP msg

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

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

134. 11/23/2006France Telecom134 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!!

135. 11/23/2006France Telecom135 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!! Many other forms of connections: –Peer2Peer, Friend2Friend, community

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

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

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

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

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

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

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

143. 11/23/2006France Telecom143 “BGP” How would I let the whole world know about 169.237/16? –I announce that I owned 169.237/16 –Prefix hijacking 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

144. 11/23/2006France Telecom144 “BGP” How would I let the whole world know about 169.237/16? –I announce that I owned 169.237/16 –Prefix hijacking 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 –DDoS, Spam – no receiver/owner controllability UCDavis: 169.237/16 AS6192

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

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

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

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

149. 11/23/2006France Telecom149 Social Routers

150. 11/23/2006France Telecom150 Social Routers Proxy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

167. 11/23/2006France Telecom167 Limited Resources........

168. 11/23/2006France Telecom168 M........ Keywords and aggregated keywords “content addressable emails”

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

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