Routing and the IETF

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