1. 1 EU SP Security Forum, December, 2008 Vince Fuller (for the LISP crew) http://www.lisp4.net/prezos/lisp-eusp.ppt Introduction to LISP

2. EU SP Security Forum, December, 2008Slide 2 Acknowledgements This work is a collaborative effort, most notably with my colleagues on the LISP “core” team: –Dino Farinacci – leader, instigator, and implementer –Dave Meyer – evangelist –Darrel Lewis – security geek Special thanks are due to J. Noel Chiappa who’s writings on naming and addressing opened my eyes to the concepts of “identifier” and “locator” –See: “Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture”, J. Noel Chiappa, 1999, http://users.exis.net/~jnc/tech/endpoints.txt http://users.exis.net/~jnc/tech/endpoints.txt –“On the Naming and Binding of Network Destinations”, J. Saltzer, August, 1993, published as RFC1498, http://www.ietf.org/rfc/rfc1498.txt?number=1498 http://www.ietf.org/rfc/rfc1498.txt?number=1498

3. Introduction to LISPEU SP Security Forum, December, 2008Slide 3 Agenda What is the problem? What is LISP? Why Locator/ID Separation? Data Plane Operation Finding Mappings – LISP+ALT A word or two about “interworking” Implementation and pilot network Securiy considerations for LISP Call for participation

4. Introduction to LISPEU SP Security Forum, December, 2008Slide 4 Problem Statement There are reasons to believe that current trends in the growth of routing and addressing state on the global Internet may cause difficulty in the long term The Internet needs an easier, more scalable mechanism for multi-homing with traffic engineering

5. Introduction to LISPEU SP Security Forum, December, 2008Slide 5 Problem Statement An Internet-wide replacement of IPv4 with ipv6 represents a one-in-a-generation opportunity to either continue current trends or to deploy something truly innovative and sustainable As currently specified, routing and addressing with ipv6 is not significantly different than with IPv4 – it shares many of the same properties and scaling characteristics More at: www.vaf.net/prezos/rrg-prague.pdf

6. Introduction to LISPEU SP Security Forum, December, 2008Slide 6 Scaling of Global Routing

7. Introduction to LISPEU SP Security Forum, December, 2008Slide 7 Global Routing – Log view

8. Introduction to LISPEU SP Security Forum, December, 2008Slide 8 Instead of IP addresses, two numbering spaces: –Endpoint Identifiers (EIDs): hierarchically assigned to sites along administrative lines (like DNS hostnames) Do not change on devices that remain associated with the site; think “PI” but not globally-routable –Routing Locators (RLOCs): assigned according to network topology, like “PA” address assignments Locators are aggregated/abstracted at topological boundaries to keep routing state scalable When site’s connection to network topology changes, so do the locators – aggregation is preserved What is ID/Loc Separation?

9. Introduction to LISPEU SP Security Forum, December, 2008Slide 9 Hierarchical EID assignment Provider A 10.0.0.0/8 Provider B 11.0.0.0/8 R1R2 PI EID-prefix 240.1.0.0/16 10.0.0.1 11.0.0.1 ISP allocates 1 locator address per physical attachment point (follows network topology) RIR allocates EID-prefixes (follows org/geo hierarchy) Site Legend: EIDs -> Green Locators -> Red

10. Introduction to LISPEU SP Security Forum, December, 2008Slide 10 Provider A 10.0.0.0/8 Provider B 11.0.0.0/8 R1R2 BGP End Site Benefit (1)Easier Transition to ipv6 (maybe) (2)Change provider without address change Lower OpEx for Sites and Providers (1)Improve site multi-homing (2)Improve provider traffic engineering (3)Reduce size of core routing tables What Features do I get? Site with PI Addresses

11. Introduction to LISPEU SP Security Forum, December, 2008Slide 11 What is LISP? Locator/ID Separation Protocol Ground rules for LISP: –Network-based solution –No changes to hosts whatsoever –No new addressing changes to site devices –Very few configuration file changes –Imperative to be incrementally deployable –Address family agnostic

12. Introduction to LISPEU SP Security Forum, December, 2008Slide 12 New Network Elements Ingress Tunnel Router (ITR) –Finds EID to RLOC mapping –Encapsulates to Locators at source site Egress Tunnel Router (ETR) –Owns EID to RLOC mapping –Decapsulates at destination site

13. Introduction to LISPEU SP Security Forum, December, 2008Slide 13 Packet Forwarding Provider A 10.0.0.0/8 Provider B 11.0.0.0/8 S ITR D ETR Provider Y 13.0.0.0/8 Provider X 12.0.0.0/8 S1 S2 D1 D2 PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8 DNS entry: D.abc.com A 2.0.0.2 EID-prefix: 2.0.0.0/8 Locator-set: 12.0.0.2, priority: 1, weight: 50 (D1) 13.0.0.2, priority: 1, weight: 50 (D2) Mapping Entry 1.0.0.1 -> 2.0.0.2 11.0.0.1 -> 12.0.0.2 Legend: EIDs Locators 1.0.0.1 -> 2.0.0.2 11.0.0.1 -> 12.0.0.2 1.0.0.1 -> 2.0.0.2 12.0.0.2 13.0.0.2 10.0.0.1 11.0.0.1 Policy controlled by destination site

14. Introduction to LISPEU SP Security Forum, December, 2008Slide 14 When the ITR has no Mapping ITR needs RLOCs from a site ETR for a particular EID prefix ITR sends Map Request (or Data Probe) ETR returns Map Reply But how does the ITR find the right ETR? –Using the mapping system…

15. Introduction to LISPEU SP Security Forum, December, 2008Slide 15 Mapping System: What and Why Need a scalable EID to Locator mapping lookup mechanism Network based solutions –Have query/reply latency –Can have packet loss characteristics –Or, have a full table like BGP does How does one design a scalable Mapping Service?

16. Introduction to LISPEU SP Security Forum, December, 2008Slide 16 Scaling Constraints Build a large distributed mapping database service Scalability paramount to solution How to scale: (state * rate) If both factors large, we have a problem –state will be O(10 10 ) hosts Aggregate EIDs into EID-prefixes to reduce state –rate must be small Dampen locator reachability status and locator-set changes Each mapping system design does it differently

17. Introduction to LISPEU SP Security Forum, December, 2008Slide 17 Tough Questions/Issues Where to store the mappings? How to find the mappings? Push model or pull model? Full database or cache? Secondary storage? How to secure mapping entries? How to secure control messages? Protecting infrastructure from attacks Control over packet loss and latency

18. Introduction to LISPEU SP Security Forum, December, 2008Slide 18 Ideas Considered DNS – considered, many issues DHTs – considered, research pending CONS – new protocol, hybrid push+pull –Push EID-prefixes at top levels of hierarchy –Pull mappings from lower levels of hierarchy EMACS – multicast-group-based NERD – pure Push design ALT – GRE/BGP based, current focus

19. Introduction to LISPEU SP Security Forum, December, 2008Slide 19 Why LISP+ALT was Selected Use existing technology where reasonable Low memory impact on ITR Optional data path to reduce latency (deprecated data probes) Allow infrastructure players to achieve new revenue source

20. Introduction to LISPEU SP Security Forum, December, 2008Slide 20 LISP+ALT: What and How Hybrid push/pull approach –ALT pushes aggregates - find ETRs for EID –ITR uses LISP to find RLOCs for specific EID Hierarchical EID prefix assignment –Aggregation of EID prefixes Tunnel-based overlay network BGP used to advertise EIDs on overlay Option for data-triggered Map-Replies (deprecated for now)

21. Introduction to LISPEU SP Security Forum, December, 2008Slide 21 LISP-ALT Routers and the ALT LISP+ALT routers form “Alternative Logical Topology” (ALT) –Interconnected by tunnels (GRE or …) –eBGP used for EID prefix propagation –Isomorphic topology and EID assignment ITRs and ETRs connect at “edge”

22. Introduction to LISPEU SP Security Forum, December, 2008Slide 22 Tunnel and BGP Operation EID prefixes originated into BGP at edge –advertised by ETR to its first-hop ALT router ITR learns EID prefixes via eBGP – advertised by first-hop ALT router to ITR Map-Request forwarded into the ALT via first- hop ALT router –intermediate ALT routers forward Map-Request to ETR that “owns” an EID prefix ALT routers aggregate prefixes “upward” in the alternative topology

23. Introduction to LISPEU SP Security Forum, December, 2008Slide 23 Legend: EIDs -> Green Locators -> Red GRE Tunnel Low Opex Physical link Data Packet Map-Request Map-Reply ETR ITR EID-prefix 240.1.1.0/24 ALT 240.0.0.1 -> 240.1.1.1 1.1.1.1 2.2.2.2 3.3.3.3 240.0.0.1 -> 240.1.1.1 EID-prefix 240.0.0.0/24 1.1.1.1 -> 11.0.0.1 240.0.0.1 -> 240.1.1.1 11.0.0.1 -> 1.1.1.1 ALT-rtr 12.0.0.1 11.0.0.1 ? 240.0.0.1 -> 240.1.1.1 11.0.0.1 -> 240.1.1.1 ? 240.0.0.1 -> 240.1.1.1 11.0.0.1 -> 240.1.1.1 ? <- 240.1.1.0/24 <- 240.1.2.0/24 < - 240.1.0.0/16 ? LISP+ALT in action

24. Introduction to LISPEU SP Security Forum, December, 2008Slide 24 “low-opex” xTR – what & why BGP configuration complexity is a barrier to site-multihoming Remove xTR/CPE BGP requirement: –ITR has “static default EID-prefix route” to “first hop” ALT router –“first hop” ALT router has “static EID-prefix route” pointing to ETR –originates EID prefix on behalf of ETR Considering new “map-server” element

25. Introduction to LISPEU SP Security Forum, December, 2008Slide 25 A few open ALT issues Who runs the ALT network? –What’s the business model? –Should it be rooted at/run by the RIRs? IXCs? Some other neutral parties? –Different levels run by different orgs –Should it be free? OK to renumber to get “PI” EID prefix? Interworking/transition strategies (later) Work in standards/ops community (later) Others?

26. Introduction to LISPEU SP Security Forum, December, 2008Slide 26 Interworking LISP will not be deployed overnight –And may never be deployed at some sites Need “Interworking” between LISP sites and non-LISP sites Two choices: –Proxy Tunnel Routers – advertise EID space to Internet; act as ITR for non-LISP sites –LISP-NAT – LISP site xTR translates EIDs into “legacy” Internet addresses draft-lewis-lisp-interworking-01.txt

27. Review: LISP in one Slide Today’s Internet - Data Plane LISP-ALT Control Plane LISP Site Non-LISP Site LISP Site GRE Tunnels Physical Links CE LISP Routers LISP Routers RLOCs EIDs EIDs assigned by Internet Registries RLOCs assigned by Service Providers Configure EID -> RLOCs database mappings for local site Stores EID -> RLOCs cache mappings for remote sites Benefits: Improved low-opex multihoming Site based policy and reachability Reduces routing tables in core routers No site renumbering when changing ISPs No changes to site hosts No changes to site switches/routers No changes to core routers No DNS changes No site addressing changes Works with PI or PA prefixes Supports 4to4-over-6 and 6to6-over-4 Sites authoritative for their mappings Interworks with non-LISP sites using translation or PTRs Costs: Mapping system required New Software in CE routers New LISP-ALT infrastructure Legend: EIDs (End Site IDs) in green RLOCs (Routing Locators) in red CE: Customer Premise Edge Router ALT: Alternative LISP Topology OH: Outer header, CE to CE IH: Inner header, host to host “Separating ID and Location in an IP address through a level of indirection” CE Advertises RLOCs to maintain aggregation and provide reachability to sites RLOCs EIDs Data Packet Payload OHIHHost Data Wed Nov 26 16:23:38 PST 2008 CE Advertises EID-prefixes to find mappings

28. Introduction to LISPEU SP Security Forum, December, 2008Slide 28 Implementation Status cisco has a LISP prototype implementation –Started in March 2007 –Testing on pilot network since summer ‘07 OS platform is NX-OS (on top of Linux) Hardware platform is Titanium –1 RU dual-core off-the-shelf PC with 7 GEs Based on draft-farinacci-lisp-10.txt Software switching only Supports both IPv4 and ipv6 Includes ALT and Interworking Traceroute and debugging features

29. Introduction to LISPEU SP Security Forum, December, 2008Slide 29 Implementation Status IOS 12.4T prototype is in the works OpenLISP implementation: draft-iannone-openlisp-implementation-00.txt Would really like to see more

30. Introduction to LISPEU SP Security Forum, December, 2008Slide 30 LISP: Practice & Experience NANOG 44 Slide 30 Deployment status – ALT pilot LISP: Practice & Experience Slide 30 NANOG 44

31. Introduction to LISPEU SP Security Forum, December, 2008Slide 31 Security in LISP Control Plane Security –What’s going on in the ALT? Data Plane Security –What are the implications of security in a loc/id split world Site Security –What needs to be able to talk to my RLOCs? Likely more work needed…

32. Introduction to LISPEU SP Security Forum, December, 2008Slide 32 Control Plane Security Use existing/proposed BGP security mechanisms –Filtering of ETR-to-ALT announcements –MD5 authentication of sessions –S-BGP/SO-BGP as they are developed –SIDR for address assignment checking GRE Tunnels need love too –ACLs to prevent anything other than BGP, ICMP, and UDP 4342 –Likely need something other than just GRE in the longer term due to data-insertion issues

33. Introduction to LISPEU SP Security Forum, December, 2008Slide 33 Data Plane Security In the Core, things look… different with lots of LISP flows –All LISP data is encapsulated into UDP4341 –The inner header/data is there, 36 Bytes from the start –Think about how to look at that data… Spoofing, and (spoofing) –Outer Header spoofing is no different than UDP today –Inner header spoofing is a little bit more tricky

34. Introduction to LISPEU SP Security Forum, December, 2008Slide 34 ITR/ETR/ALT are vulnerable ITRs and ETRs represent new targets for attacks (as do ALT routers) Nonce in LISP request/reply exchange –Guards against third-party spoofing –But doesn’t prevent “man-in-the-middle” attacks Mitigation using well-known control plane protection techniques (infrastructure hiding, iACLs, rACLs, CoPP, etc.) More work likely needed… …must balance against deployability

35. Introduction to LISPEU SP Security Forum, December, 2008Slide 35 Site Security At the site, securing your xTR is pretty straightforward. –Allow LISP (data & control) packets to your RLOCs –Allow GRE (for ALT) to your RLOCs –Allow for ICMP to your RLOCs –LISP enforces spoofing on decapsulation Outgoing –LISP enforces uRPF on encapsulation so you are prohibited from spoofing inner headers

36. Introduction to LISPEU SP Security Forum, December, 2008Slide 36 Site Security (Continued) Post encapsulation, your site’s policies can remain the same Flexible packet matching is an existing IOS tool that can be used to build ACLs on inner/lisp/outer header chains (12.4T) More work needed here so if you’re interested…

37. Introduction to LISPEU SP Security Forum, December, 2008Slide 37 Interested in more? Considering additional external test sites –Must be able to dedicate minimum of 1 day a week Goals: –Test multiple implementations –Experience with operational practices –Learn about revenue making opportunities Developers at: lispers@cisco.comlispers@cisco.com Discussion at: lisp@ietf.orglisp@ietf.org

38. Introduction to LISPEU SP Security Forum, December, 2008Slide 38 LISP Internet Drafts draft-farinacci-lisp-10.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-01.txt draft-farinacci-lisp-multicast-01.txt draft-meyer-lisp-eid-block-01.txt draft-mathy-lisp-dht-00.txt draft-iannone-openlisp-implementation-01.txt draft-brim-lisp-analysis-00.txt draft-meyer-lisp-cons-04.txt draft-lear-lisp-nerd-04.txt draft-curran-lisp-emacs-00.txt

39. Introduction to LISPEU SP Security Forum, December, 2008Slide 39 Questions/Comments? Thanks! Discussion: lisp@ietf.orglisp@ietf.org Information: http://www.lisp4.nethttp://www.lisp4.net OpenLISP: http://inl.info.ucl.ac.behttp://inl.info.ucl.ac.be