Transcript PORT and asserts

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
• 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
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.
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
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
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 multihomed
– 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
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
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
LISP
Thanks to Dino Farinacci for the slide
LISP availability
• Cisco EFT/ED releases available for
download
– See http://lisp4.cisco.com/
– Also
http://www.cisco.com/en/US/prod/collateral/ioss
wrel/ps6537/ps6554/ps6599/prod_bulletin_c25598556.pdf
• OpenLISP
– See http://www.openlisp.org/ or
http://gforge.info.ucl.ac.be/projects/openlisp
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
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
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