1 / 14

Routing and the IETF

Routing and the IETF. Routing activities in the IETF. We consider some key areas Scaling of Internet Routing Identifier – Locator split Routing Security BGP route origination Transport security Multicast. Size of routing tables.

sanjiv
Download Presentation

Routing and the IETF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Routing and the IETF

  2. Routing activities in the IETF • We consider some key areas • Scaling of Internet Routing • Identifier – Locator split • Routing Security • BGP route origination • Transport security • Multicast

  3. Size of routing tables • One major issue today is the size of routing tables in the global Internet (default free zone) • How to keep routing tables small? • Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. • This can be achieved in some way by having IP addresses assigned to providers, and have users use addresses from their provider. • Number of routes in the global routing tables will then be limited by the number of providers – same order of magnitude • These addresses would be essentially locators. The address specifies an end-points location in the network

  4. Addresses as identifiers • We generally like to think of addresses as identifiers • Enterprises/organisations want to own their own address space • Changing providers without renumbering • Each address identifying an end-point • Want to do multihoming by announcing the same addresses with multiple providers • This allows multihoming to be transparent to end-points • Traffic engineering, e.g. load balancing by announcing different parts of the address space through different providers • There have also been attempts at doing dynamic load balancing, causes frequent updates and churn in the global routing tables.

  5. Loc/ID examples • A typical postal address is e.g. Jan Modaal, Leuk Straatje, Amsterdam, Netherlands • The red part (if unique) would be an identifier • The person might move or somehow have two post boxes in two different locations • The blue part is a locator and can be aggregated (hierarchical) • The postal service around the world treats all post to Netherlands the same way, sending it to the same next-hop • The postal service in Netherlands can send all Amsterdam post to the same next-hop etc • When one were looking at IPng (now IPv6) there were proposals like GSE/8+8 for having IP addresses containing prefix and identifier • With IPv6 stateless address autoconfig we almost have this • 2001:db8:10c:2:1234:56ff:fe78:9abc

  6. Locator – Identifier split • IAB workshop 2007 • IAB (IETF Internet Architecture Board) had a workshop in 2007 (RFC 4984) discussing scaling of the Internet’s routing system. Main conclusion was that using the same address as both a locator and an identifier (answering “where” and “who”) is one of the main problems. • Identifiers could be what is used in the DNS, what the transport layer (e.g. TCP) cares about • A separate address, the locator, could specifiy the current location of the identifier • Locators can be aggregated and used for Internet routing • IRTF (Internet Research Task Force) created a Routing Research Group to find possible solutions • There was a recommendation from the working group in March to go for a solution called ILNP, but this was controversial. Many other approaches had been studied, and no consensus • Another solution proposed is LISP, and there is an IETF working group

  7. Identifier to Locator mapping • End-points should only care about identifiers. How to find the locators for an identifier? We need a mapping system • There may be multiple locators for an identifier if multi-homed • How to choose which? Traffic-engineering? • Mobility can be done by changing the mapping when the location changes • How to make the mapping system scale? • Aggregation by aligning mapping system hierarchy with identifier delegation hierarchy? A bit like e.g. reverse DNS mappings. • How dynamic can the mapping system be? • Push, poll, cache,...; mobility too hard? • How to secure the mapping system? • Avoid e.g. hijacking of traffic by providing wrong locators

  8. Identifier Locator Network Protocol • Originally only IPv6 where 64 first bits are used as a locator and last 64 bits as an identifier • Proposed by Mike O’Dell in 1997 8+8, also GSE • DNS as mapping system • Applications use FQDN, not addresses • ID and Locator both retrieved from the DNS • Transport layers just use ID to identify end-point and for checksums • Zeroing out locator (first 64) bits • Network layer learns and uses the ID-Loc mappings • ICMP message allowing locator set changes • May allow internal localised addressing • Rewriting of locator at site border • IPsec, security association only based on identifier • http://tools.ietf.org/html/draft-rja-ilnp-intro

  9. LISP – Locator ID Separation Protocol • A so-called map and encap solution, IETF working group • Internal IP addresses inside a site are Identifiers • Should be globally unique • Packets tunneled between site border routers • IP addresses used for tunnel end-points are Locators • Provider assigned addresses used for encapsulation • Only locators which can be aggregated used in Internet routing • LISP only requires changes to site border routers • But need a mapping system to map from identifier to locator • Identifiers aggregated in the mapping system, need not follow network topology • Solves multihoming and to some extent mobility • Mobility depends on rate of change and mapping system • Has its own mechanism for checking locator liveness • http://tools.ietf.org/html/draft-ietf-lisp

  10. LISP Thanks to Dino Farinacci for the slide

  11. LISP availability • Cisco EFT/ED releases available for download • See http://lisp4.cisco.com/ • Also http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/prod_bulletin_c25-598556.pdf • OpenLISP • See http://www.openlisp.org/ or http://gforge.info.ucl.ac.be/projects/openlisp

  12. Routing security – BGP • IETF sidr wg (secure interdomain routing) • Working on architecture for interdomain routing security framework • Use of PKI for signing routing objects • http://tools.ietf.org/id/draft-ietf-sidr-arch-09.txt • An AS can prove that it is authorised to originate routes for an address prefix • Can be used to filter out unauthorised routes • Pakistan Telecom accidentally shut down YouTube in February 2008 by announcing a more specific route • http://www.cidr-report.org/as2.0/#Bogons has a list of more than 200 prefixes that are announced by ASes but not allocated to them • Does this prevent hijacking? • One can still announce a bogus path that appears to be originated by the correct AS, very difficult problem, see e.g. RFC 5123 • http://www.potaroo.net/presentations/2010-01-28-route-secure.pdf

  13. Routing Protocol Security • KARP working group • Keying and Authentication for Routing Protocols • Concerned with authentication, packet integrity, DoS protection for routing protocols • Basically transport security, it does not ensure the information itself is valid • Hence, different from the BGP security on the previous slide • Considering BGP, OSPF, PCE, PIM,LDP, RSVP-TE, ISIS, BFD, LMP and MSDP for now • Many routing protocol RFCs simply specify IPsec for security, but do not precisely say how • Interesting challenges regarding crypto agility, key management • May be more challenging for group communication

  14. Multicast • PIM (Protocol Independent Multicast) • Limited activity in the working group • PORT (PIM over Reliable Transport) • PIM becomes hard state, uses TCP/SCTP and no periodic signaling • MBONED • AMT (Automatic IP multicast without explicit tunnels) • Allows multicast over non-multicast networks • UT Dallas implementations for Linux, FreeBSD and Windows • http://cs.utdallas.edu/amt/ • Pretty close to being an RFC, except for some controversy regarding IPv6 UDP and checksums • New mtrace specification for IPv4 and IPv6 • MULTIMOB (Multicast mobility) • Concerned with multicast for Proxy Mobile IPv6 • Also tuning of IGMPv3/MLDv2 in general

More Related