1. University of California, Los Angeles, Computer Science Department Using Name-Based Identities and Topological Relations of Trust to Secure Routing System ALEXANDER AFANASYEV June 9 th, 2011 Oral Qualifying Exam

2. University of California, Los Angeles, Computer Science Department A high-level research objective A new model to secure the Internet routing system, which –could be universally applied to all routing levels (OSPF, BGP) –is economically feasible to deploy –is completely distributed without centralized trust management the Internet does not have a single root of trust countries do not want to rely on outside authority to secure the internal network 2 Intro Names Netw. of Trust Chains End

3. University of California, Los Angeles, Computer Science Department Unauthorized access to confidential information –hacking to a router –sniffing control layer –data plane traffic analysis Routing update falsification –announcing an unauthorized prefix –incorrectly announcing a prefix announce /25 prefix instead of /24 –modifying information in route updates fraudulent altering the AS path field in BGP update 3 Generic threats to routing (rfc4593) Intro Names Netw. of Trust Chains End

4. University of California, Los Angeles, Computer Science Department Unauthorized access to confidential information –hacking to a router –sniffing control layer –data plane traffic analysis Routing data falsification: –announcing an unauthorized prefix –incorrectly announcing a prefix announce /25 prefix instead of /24 –modifying information in route updates fraudulent altering the AS path field in BGP update 4 Generic threats to routing (rfc4593) Inevitably some keys will be compromised Intro Names Netw. of Trust Chains End

5. University of California, Los Angeles, Computer Science Department Unauthorized access to confidential information –hacking to a router –sniffing control layer –data plane traffic analysis Routing data falsification: –announcing an unauthorized prefix –incorrectly announcing a prefix announce /25 prefix instead of /24 –modifying information in route updates fraudulent altering the AS path field in BGP update 5 Generic threats to routing (rfc4593) Identities are easy to falsify AS number and IP addresses are incomprehensible to operators misconfigurations and confusions inevitable Identities are easy to falsify AS number and IP addresses are incomprehensible to operators misconfigurations and confusions inevitable Intro Names Netw. of Trust Chains End

6. University of California, Los Angeles, Computer Science Department Proposals to secure global routing PKI Web-of-Trust Secure overlay Evidentiary trust (historical data analysis) 6 * M. Nicholes and B. Mukherjee. “A survey of security techniques for the border gateway protocol (BGP).” IEEE Communications Surveys and Tutorials, 11(1):52–65, 2009. Intro Names Netw. of Trust Chains End

7. University of California, Los Angeles, Computer Science Department PKI-based (S-BGP, soBGP, psBGP, RPKI, …) –the Internet has no central trust Web-of-trust / evidence-based (BGP-Origins, PHAS, pgBGP) –so far the proposals are ad hoc at best –trust relations are too loose Secure overlays (IRV) –the chicken and egg problem: to build overlay routing should exist, to build routing overlay should exist 7 Why previous work failed? Intro Names Netw. of Trust Chains End

8. University of California, Los Angeles, Computer Science Department 8 Shifting concepts: IP vs NDN Name How to make million $$ NDN I know what I want, deliver it to me DNS HTTP FTP HTTPS IP I know what I want, where is it located? How to make million $$ Intro Names Netw. of Trust Chains End

9. University of California, Los Angeles, Computer Science Department Apply Named Data Networking (NDN) concepts to address routing system security –people care about routing data integrity and authenticity –names give meaning Advanced network management tools –names give manageability Internet-oriented way to manage trust –leverage both contractual and collegial trust between parties on the Internet Unify solution to security problems –single framework for everything 9 What can we do differently? Intro Names Netw. of Trust Chains End

10. University of California, Los Angeles, Computer Science Department What is proposed? A framework to secure the routing system by employing a combination of –the topology-derived trust between parties to secure –locally-controlled semantically-meaningful hierarchical names for the routing infrastructure, with –a multi-path trust graph for key certification, resource authorization, etc. Aim to develop a secure routing system for NDN networks Expectation that the results will be directly applicable to the existing Internet 10 Multi-path trust graph Topological network of trust Hierarchical semantically- sound names Routers authentication Routing info authorization Routing config provenance … Intro Names Netw. of Trust Chains End

11. University of California, Los Angeles, Computer Science Department Hierarchical semantically-meaningful names 11 Multi-path trust graph Topological network of trust Hierarchical semantically- sound names Routers authentication Routing info authorization Routing config provenance … Intro Names Netw. of Trust Chains End

12. University of California, Los Angeles, Computer Science Department Currently used routing identities are meaningless Organizations in BGP are identified by AS numbers –AS numbers are just 16 bit or 32-bit numbers (AS52, AS4004) BGP and OSPF routers are identified using 4-octet integer –usually, but not necessary, one of router’s IPv4 addresses Router’s interfaces identified by IPv4 and IPv6 addresses –different interfaces usually have totally unrelated and misleading addresses 12 169.232.4.103 137.164.27.6 137.164.27.5 137.164.26.133 Intro Names Netw. of Trust Chains End

13. University of California, Los Angeles, Computer Science Department CENIC UCLA 13 Current practices in mapping IP addresses to names (UCLA / CENIC) core-2--border-1-10. backbone.ucla.net ucla--lax-hpr2-ge. cenic.net lax-hpr2--ucla-10ge. cenic.net hpr-lax-hpr--i2-newnet. cenic.net 169.232.4.103 137.164.27.6 137.164.27.5 137.164.26.133 Intro Names Netw. of Trust Chains End

14. University of California, Los Angeles, Computer Science Department Current practices by large ISPs in mapping IPs to names Level-3 (AS3356 / AS3549) –4.69.130.82 lo-22.err1.Amsterdam1.Level3.net NTT (AS2914) –129.250.0.19 r00.sttlwa01.us.bb.gin.ntt.net Tata Communications (AS6453) –206.82.129.13 vlan518.icore1.eql-losangeles.as6453.net QWEST (AS209) –67.14.24.29dvr-core-02.inet.qwest.net Verizon (AS701) –204.255.169.890.so-1-0-0.br2.lax7.alter.net 14 Intro Names Netw. of Trust Chains End

15. University of California, Los Angeles, Computer Science Department /ucla Keys and signatures from provider(s) CS EE … backbone east-wing south-wing irl-gw nrl-gw lasr-gw Intra-AS domain A natural extension of current practices for OSPF (example) 15 /ucla/cs/backbone/irl-gw Intro Names Netw. of Trust Chains End

16. University of California, Los Angeles, Computer Science Department Routing-based versus name-based topological trust Routing based (BGP) Name-based (OSPF) 16 AS1 AS2AS3 AS-PATH: AS1 AS3 trust chain: AS1 -> AS3 CS irl-gw nrl-gw Update name: */CS/nrl-gw/* trust chain: -> CS -> nrl-gw Intro Names Netw. of Trust Chains End /ucla

17. University of California, Los Angeles, Computer Science Department Advantages of using names Manageability –no confusion of IP address authority (links between providers) –lower risk to make a critical mistake e.g., */local namespace for strictly local updates –router groups management Advanced filtering capabilities Possibility for advanced routing policies Easiness of routing events (accidents) analysis –easy to attribute problem to a particular routing entity The basic of NDN: (name + content) secured with a crypto key—build-in security building block 17 Intro Names Netw. of Trust Chains End

18. University of California, Los Angeles, Computer Science Department Topological network of trust 18 Multi-path trust graph Topological network of trust Hierarchical semantically- sound names Routers authentication Routing info authorization Routing config provenance … Intro Names Netw. of Trust Chains End

19. University of California, Los Angeles, Computer Science Department Intro to public key infrastructure and web- of-trust 19 PKI single root of trust strict hierarchy Web-of-Trust every node can be a root of trust no restrictions on trust relations *S-BGP* PGP Intro Names Netw. of Trust Chains End

20. University of California, Los Angeles, Computer Science Department Public Key Infrastructure –Advantages Strict trust management procedures Deterministic verification process –Disadvantages ultimate trust to a small set of certification authorities (CAs) all CA public keys should be distributed and redistributed (re-issued, revoked) to all nodes in off-line (out-of-band) manner only one trust chain per key is usually allowed Web-of-Trust –Advantages Support of multi-path trust relations –Disadvantages there are no strict procedures how trust links are established verification in web-of-trust is highly nondeterministic 20 Why not to rely on the existing trust management solutions? Intro Names Netw. of Trust Chains End

21. University of California, Los Angeles, Computer Science Department Non restricted trust relationsTopological relations Strengthen trust using topological relations Topological network of trust Intro Names Netw. of Trust Chains End

22. University of California, Los Angeles, Computer Science Department Uses the existent topological relations to define trust between nodes –to make procedures form trust management very strict amendments to existing contracts and agreements –to make verification process deterministic Allows multiple certification paths –to reflect complex topological relations multi-homed for customers mesh-interconnections among providers via Internet exchange points –to give multi-dimensional certification authenticate routers in a routing domain authorize router to announce resources 22 Features of topological network of trust Intro Names Netw. of Trust Chains End

23. University of California, Los Angeles, Computer Science Department Topological relations on the Internet 23 Intro Names Netw. of Trust Chains End

24. University of California, Los Angeles, Computer Science Department 24 A portion of real topological relations * VeriSign Global Registry AS 30085 NTT peer provider peer customer provider customer provider customer AS 701 AS 2914 AS 26415 AS 36628 Verizon VeriSign VeriSign* DynDNS isohunt Hurricane AS 33517 AS 6939 provider customer Intro Names Netw. of Trust Chains End

25. University of California, Los Angeles, Computer Science Department Providers are local roots of trust for customers –Public keys between neighbors could be easily exchanged off- line Customer-provider agreement –customer trusts provider to deliver data –customer also trusts that provider will honor all traffic management policies –customer can ask (require) provider to sign customers key Provider-provider or customer-customer (peer-to-peer) agreements –each peer trusts that the other peer will deliver only local traffic via peer-peer link –peers can sign keys of each other 25 Service agreement = contractual trust relation Intro Names Netw. of Trust Chains End

26. University of California, Los Angeles, Computer Science Department Certification paths and trust chains 26 Intro Names Netw. of Trust Chains End Verizon -> NTT -> VeriSign* * VeriSign Global Registry NTT Verizon VeriSign VeriSign* isohunt DynDNS Hurricane Verizon -> Verisign -> VeriSign* Verizon -> Hurricane - > DynDNS

27. University of California, Los Angeles, Computer Science Department Verizon Hurricane DynDN S out-of-band: Hurricane Verizon in-band Topological trust bootstraping Direct signingReverse signing local anchor of trust Intro Names Netw. of Trust Chains End Verizon Hurricane DynDNS out-of-band: Hurricane DynDNS in-band

28. University of California, Los Angeles, Computer Science Department Only neighbors exchange public keys out-of-band –this is the only out-of-band exchange Direct signing –Providers sign keys of their customers –Give everybody access to these signatures Reverse signing –Providers sign keys of their providers (and/or peers) –Give clients access to this signatures 28 Summary of trust bootstraping in topological network of trust Intro Names Netw. of Trust Chains End NTTNTT Ver izo n VeriSig n VeriSign* isohun t DynDN S Hurricane Verizon -> Verisign -> VeriSign* Verizon -> Hurricane -> DynDNS

29. University of California, Los Angeles, Computer Science Department Relative cheap trust bootstraping –only direct neighbors exchange of keys Limited trust risks –key compromise only affects customer tree of the node Cheap re-keying abilities –same as in bootstraping –only a few keys exchanged between a few nodes 29 Advantages of topological network of trust Intro Names Netw. of Trust Chains End NTTNTT Ver izo n VeriSig n VeriSign* isohun t DynDN S Hurricane Verizon -> Verisign -> VeriSign* Verizon -> Hurricane -> DynDNS

30. University of California, Los Angeles, Computer Science Department In-band distribution –using soBGP-like SECURITY BGP message –by flooding within OSPF area or throughout OSPF domain Out-of-band distribution/management –DNSSEC-like infrastructure can simplify analysis of trust relations –in case of problems can be used as a primary key storage and management system –standard (familiar) way to store keys and delegate trust –could be hooked up with routing layer to provide information for in- band distribution 30 Trust information distribution methods Intro Names Netw. of Trust Chains End

31. University of California, Los Angeles, Computer Science Department 31 Multi-path trust graph Topological network of trust Hierarchical semantically- sound names Routers authentication Routing info authorization Routing config provenance … Intro Names Netw. of Trust Chains End

32. University of California, Los Angeles, Computer Science Department Chains give a uniform way to establish hierarchical relations –same network of trust –same formats There are orthogonal problems in routing security –routers authentication –resource authorization –limited provenance of router configurations 32 Why do we need multi-path chains? A B C EF G D Intro Names Netw. of Trust Chains End

33. University of California, Los Angeles, Computer Science Department 33 Authentication chains Authenticate other areas in OSPF routing domain Authenticate other routers in OSPF area Authenticate routing updates, originated from the router Intro Names Netw. of Trust Chains End

34. University of California, Los Angeles, Computer Science Department Binding chains 34 Key + name signature Authentication chains Key + name Binding (authorization) chains signature resource Signature binds the resource with the identity Intro Names Netw. of Trust Chains End

35. University of California, Los Angeles, Computer Science Department Routing resource authorization 35 A /ucla CS backbone irl-gw EE east-wing nrl-gw 131.179.196.0/24 /ucla/cs/irl-gw 131.179.0.0/16 /ucla/cs Intro Names Netw. of Trust Chains End

36. University of California, Los Angeles, Computer Science Department 36 Routing configuration provenance 36 A /ucla CS backbone irl-gw EE east-wing nrl-gw Admin alex pete All routers /ucla/Admin All CS routers /ucla/Admin/pete IRL router /ucla/Admin/pete/alex IRL router /ucla/…/alex/irl-gw Intro Names Netw. of Trust Chains End

37. University of California, Los Angeles, Computer Science Department Names are of vital importance –people can understand only meaningful names –routing infrastructure needs advanced, meaningful management features –hierarchical names give these features Topological network of trust –derived based on implicit topological trust relations –freedom of the Web-of-Trust and determinism of PKI –knowledge of the topology for valid trust chain discovery Multi-path chains provide a uniform way to –authenticate routers, –authorize routing resources, –limited router configuration provenance 37 Conclusions Intro Names Netw. of Trust Chains End

38. University of California, Los Angeles, Computer Science Department Define naming model conventions Implement secure intra-AS routing (OSPF) –based on the existing open-source code base Quagga or XORP Evaluate implementation –overhead (protocol, processing, storage, deployment) Research optimization methods (overhead reduction) –selective verification –caching 38 Research plan Intro Names Netw. of Trust Chains End

39. University of California, Los Angeles, Computer Science Department Design secure inter-AS routing –extension for BGP protocol has to be backward-compatible –again, based on existent code base 39 Research plan (continue) Intro Names Netw. of Trust Chains End

40. University of California, Los Angeles, Computer Science Department Questions? 40 Intro Names Netw. of Trust Chains End