Future Internet Technologies Future Internet Research Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/pfisterer
New requirements on TCP/IP Growth Lack of addresses NAT No E2E anymore Routing tables grow CIDR and topological assignment of addresses No flexible address assignment Mobility IP addresses are assigned topologically routing table size When mobile hosts move to different topological locations, the IP address must change IP address change breaks existing sessions (TCP and UDP) Traffic Engineering Multi-homing #2
Growth: BGP Entries (1989-2012) Source: http://bgp.potaroo.net/as2.0/bgp-active.html #3
Growth: BGP Entries [RFC4984-2007] 2.000.000 1.500.000 1.000.000 500.000 0 2005 2006 2011 2020 (projected) #4
Traffic Engineering Goal Balance load on multiple links ISP#1 ISP#2 Internet Realization Use of BGP Selective advertisement of more-specific routes on different links net/22 Example net/23 Example net/23 Internet #5
Multi-homing #6
Multi-homing A site is served by more than one ISP [RFC4116] Reasons for multi-homing Increase reliability of the Internet connection Important for business-critical applications Internet connections have become inexpensive more frequent use multi-homing Sometimes mandatory due to contract or law Multihomed Network Router ISP #1 ISP #2 Internet #7
Multi-homing Variants Multiple ISPs, multiple interfaces per host, single IP address per interface Hosts have multiple interfaces; each has an IP from the ISP s range If a link goes down, existing connections via this link break New connections could only resolve IPs from the other link Requires DNS update and applications to refresh their revolved names Other solutions: SCTP or Multipath TCP (IETF work in progress) Multiple ISPs, single IP address space The same (single) address space is announced via BGP over multiple links Only best link is used (due to better BGP parameters) If this link fails, BGP will notice this and use a different link Only works with provider-independent address space (incoming) or NAT (outgoing) Multiple ISPs, multiple IP address spaces To increase reliability/load balancing or WAN-internal traffic (internal IP-ranges) #8
Provider-Independent (PI) Address Space IP-Address range that is independent of an ISP Allows changing the ISP w/o changing addresses No need to renumber internal client systems PI address spaces lead to large routing tables Applies to all edge routers of the Internet Backbone routers not capable of holding global BGP table in memory Consequence: Route Filtering Rejection of BGP entries (i.e., not accepted for local routing table) Filter based on prefix length (e.g., a few class C networks) These networks are not visible in parts of the Internet #9
Conflicting Interests Customers Session survivability (no breaking TCP connections) Multihoming (more than one provider) Flexibility (change providers) PI address space Providers Routers should scale (add more customers) and be costeffective Traffic Engineering (w/o adding too many routing table entries) Minimize the number of routing table entries PA address space (provider aggregateable) #10
Current Routing Issues Size of routing tables Lack of aggregation (historic reasons, multi-homing, traffic engineering, mergers and acquisitions) IPv6 renumbering is no solution (often not acceptable) Current size of routing entries bounded by the IPv4 address space With IPv6 deployment things get worse Frequent BGP updates ~500,000 updates per day, peak rate 1000 updates/sec [DynPrefix] Mostly due to traffic engineering (load balancing with BGP) Small number of AS responsible for large fraction of updates [ATNAC2006] Size and update frequency lead to long convergence times #11
Summary Open issues Multi-homing Traffic engineering Mobility Multiple (partial) solutions proposed Stream Control Transmission Protocol (SCTP) Locator Identifier Split Security - 04 Cryptology #12
Stream Control Transmission Protocol (SCTP) #13
Issues with TCP and UDP TCP offers a stream-based interface Most applications exchange messages Requires de-/framing Sometimes reliable, message-oriented service is required w/o sequence maintenance Required: Something between UDP and TCP No multi-homing TCP/UDP sockets bound to one interface #14
SCTP Overview Designed to transport Public Switched Telephone Network (PSTN) signaling messages (SS7) over IP networks Not limited to this application domain Reliable transport protocol Operates on top of a connectionless packet network such as IP Standardized in [RFC4960-2007] #15
SCTP and the Internet Reference Model Application... Transport TCP UDP SCTP Network IPv4 IPv6 Data Link Ethernet WiFi ATM... Security - 04 Cryptology #16
Streams and Associations Message: Application-level data unit Stream: Unidirectional message stream Unlike TCP which provides a single byte-oriented stream SCTP bundles multiple streams in so-called associations Association: Connection between two SCTP endpoints Stream #1 Stream #2 Association Stream #3 #17
Association Setup 4-way handshake to initiate connections Stateless setup to avoid DoS attacks (cf. SYN cookies) Initially, additional IP addresses are exchanged Client and server mutually know all other IP addresses Can include IPv4 and IPv6 addresses INIT INIT ACK - Contains cookie (hash of INIT and signature) COOKIE ECHO - Cookie from INIT ACK - Validates MAC - Create connection state COOKIE ACK - Create connection state Security - 04 Cryptology #18
Packets and Chunks SCTP packet Contains header and one or more chunks Chunk Data (containing messages) or control (handshake, shutdown, ) chunks Encapsulated in an SCTP packet Data chunks may contain fragments of or complete messages Supports path-mtu-adaptive data fragmentation Bundling of multiple messages from different streams into a single SCTP packet Stream #1 Stream #2 SCTP Header Data Chunk Data Chunk Control Chunk Data Chunk Stream #1 Stream #2 SCTP Packet #19
Message Delivery TCP and UDP TCP: reliable, in-order delivery, byte-stream channel UDP: unreliable, message-oriented datagram service Missing: reliable, message-oriented service SCTP supports acknowledged error-free non-duplicated transfer of messages Sequenced delivery of messages Optional: request out-of-order delivery per-message #20
Multi-homing Support Associations exist between two hosts Unlike TCP/UDP where connections exist between interfaces SCTP supports multi-homed hosts Multiple network interfaces or multiple IP addresses on one interface Uses transmission over multiple paths Definition: Path Network route between two SCTP endpoints Primary path: Currently active (default) path Path #1 Path #2 #21
Multi-homing Support Paths are actively monitored Heartbeat messages to detect failures and to measure round-trip time Used to select best path as active one Applications may also actively choose a path Fault tolerance At either or both ends of an SCTP association If a path fails, another one becomes the active path Path #1 Path #2 #22
SCTP Implementations Operating Systems AIX Version 5 Cisco IOS 12 DragonFly BSD since version 1.4 FreeBSD version 7 Linux kernel-based 2.4 and newer Microsoft Windows (3rd party kernel driver) Sun Solaris 10 User space SCTP library Oracle Java JDK 7 (not in SE, available as library) Security - 04 Cryptology #23
Locator Identifier Split #24
Identifiers and Locators Major issues on the networking layer Naming (refer to a system) Addressing (refer to a route to a system) Routing (deliver packets to a system) IP-Addresses have two roles/semantics Identifiers: interfaces of hosts Locators: name of topological locations #25
Identifiers and Locators Issues [ietf-loc-id-split] Rekhter's Law: Addressing can follow topology or topology can follow addressing. Choose one. Strict topological assignment small routing tables, no PI addresses, no traffic engineering, No topological assignment large routing tables / no connectivity Requirements Multi-homing and traffic engineering should be possible and should be done near the edge W/o exposing all details to the Internet core #26
Locator/Identifier Split: Potential Solutions Network Address Translation (NAT) Application Layer Names Use DNS names as identifiers Introduce a new layer #27
Network Address Translation (NAT) Can be seen as a kind of Locator/Identifier split Multiple Internet connections (PA address space) Locators Internal addresses (PI addresses) Identifiers (only internal) No real/global solution; no end-to-end semantics Example: Destination NAT Only incoming traffic considered External IP Internal IP Destination NAT 141.182.164.1 192.168.0.1 88.34.123.1 192.168.0.1 141.182.164.2 192.168.99.2 Internal IP addresses Router ISP #1 ISP #2 Internet 88.34.123.2 192.168.99.2 #28
Application Layer Names Use application layer names for identifiers Exclusive use of DNS names on transport layer Example: DNS names in URLs (disallow IP addresses) Problem: application-specific Requires changes to most application layer protocols E.g., what about IP addresses in FTP Makes DNS names the stable reference point Change the socket API to take DNS names? Issue: Inhibits caching scalability of DNS #29
Introduce a New Layer DNS name new layer type IP address Massive change to the Internet s architecture No disruptive change (IP remains untouched) Requires (additional) infrastructure to maintain and resolve binding between new identifiers and IP addresses Introduces new security problems Different approaches proposed FARA [FARA-2003] PeerNet [PeerNet-2003] Internet Indirection Infrastructure [III-2002] Locator Identifier Separation Protocol (LISP) Host Identity Protocol (HIP) Application Transport New Layer Internet Link Layer Identifiers Locators #30
Address Rewriting Use existing addresses and change semantics (include locator and identifier data) Specific scheme for IPv6 proposed [AltAddrIPv6] which uses top 64 bits as locator and lower 64 bits as identifier Procedure: 1. Resolves mapping for identifier to locator IPv6 address split into: Network (64 Bit) Locator 2. Send packet with unspecified source locator 3. Egress router adds source locator 4. Ingress router removes destination locator and forwards packet to destination identifier 5. Destination interface receives packet Host (64 Bit) Identifier Resolver Resolves Id Loc 1.) Source Dest. Payload --- abc 567 def 2.) 3.) Source Dest. Payload 111 abc 567 def 4.) Source Dest. Payload 111 abc --- def 5.) abc Internal network Internet 111 567 Internal network def #31
Map-and-Encap [RFC1955-1996] Procedure 1. Source sends packet to some identifier and forwards it to the egress router 2. Egress router resolves mapping for identifier to locator and encapsulates the original packet 3. Routing towards the destination based on locator 4. Ingress router decapsulates packet and internally forwards it to the destination identifier 5. Destination receives packet Suggests that the identifier may need to be routable in some scope Likely scoped to the current internal network Mapper Resolves Id Loc 2.) Identifier Payload Identifier Payload 1.) Internal network Locator Identifier Payload Internet 3.) 4.) 5.) Internal network #32
Locator Identifier Separation Protocol (LISP) #33
Locator Identifier Separation Protocol (LISP) Standardized by the IETF Locator/ID Separation Protocol (lisp) working group [lisp-charter] Base standard in [RFC5201-2008] Integration with DNS in [RFC5205-2008] Testbed by companies such as Google, Facebook, NTT, Level3, Goals Improved routing scalability (BGP-free multi-homing) Address family traversal (IPv4 over IPv4 or IPv6; IPv6 over IPv4 or IPv6) Inbound traffic engineering Mobility Simple deployability (no host changes required) #34
LISP Architecture Two addresses Locator: Routing Locator (RLOC) Identifier: Endpoint Identifier (EID) Based on Map-and-Encap Routers responsible for mapping No visible changes for hosts Address type Both identifiers and locators can be IP addresses However, they can be arbitrary types like a set of GPS coordinates or a MAC address [LispAddr] Application Transport Internet Internet Link Layer Identifiers Locators #35
Host Identification Protocol (HIP) #36
Host Identification Protocol (HIP) Introduces new layer Between transport and network layer Application Requires hosts to support HIP No changes to the network Goals: Integrate mobility, multi-homing, and security across IPv4 and IPv6 Transport HIP Layer Internet Link Layer Identifiers Locators #37
HIP Architecture Two addresses Locator: IP address Identifier: Host Identity Tag (HIT) Host Identity (HI) name space Based on a public key security infrastructure Each host has a public/private key pair hash(public-key) = HIT Size of the HIT is 128 Bit (cf. size of IP address) Hosts can prove to own the private key using a Diffie- Hellman key exchange on connect #38
HIP Name Resolution DNS HIT Use of DNS to map hostnames to HIP identities Clients query for HIP records Contains HIP identity (public key) and HIT Rendezvous server for mobile hosts (optional) HIT IP addresses Different options available (see next slide) #39
HIP Name Resolution DNS for resolution on both layers [RFC5205-2008] Query for name; obtain HIT and A/AAAA records Advantage: uses existing infrastructure only Disadvantage: high update latency due to caching Rendezvous server [RFC5204-2008] Returns HIT IP mapping Minimizes update latency for mobile hosts DNS query returns DNS name of rendezvous server Advantage: Good for highly mobile nodes Disadvantage: Additional component Others: DHT-based, #40
HIP Connection Setup Four way handshake Diffie-Hellman key exchange Mutual authentication Stateless to avoid DoS attacks (cf. TCP SYN cookies) Creates a security association between both endpoints After connection setup, packets are encrypted using IPSec HIT C, HIT S or NULL HIT C, HIT S, challenge HIT C, HIT S, response, signature Client HIT C, HIT S, signature Server #41
HIP: Mobility Support Mobility isn t an issue because only IP addresses change the HIT address remains unchanged However, the mapping must be up-to-date Existing connections: inform peer By sending update message to HIP layer Secure because of IPSec New connections: update mapping service Protocol depends on mapping service Examples: DNS, rendezvous server, #42
Literature (1/2) [ietf-loc-id-split] Architectural Implications of Locator/ID Separation. http://tools.ietf.org/html/draft-meyer-loc-id-implications- 01 [RFC4984-2007] D. Meyer, L. Zhang, and K. Fall: Report from the IAB Workshop on Routing and Addressing, 2007. http://tools.ietf.org/html/rfc4984 [ATNAC2006] Huston, G. and G. Armitage, "Projecting Future IPv4 Router Requirements from Trends in Dynamic BGP Behaviour", http://www.potaroo.net/papers/phd/atnac-2006/bgp-atnac2006.pdf, 2006. [DynPrefix] Oliveira, R. et. al., "Measurement of Highly Active Prefixes in BGP", IEEE GLOBECOM 2005. http://www.cs.ucla.edu/~rveloso/papers/activity.pdf. [LocIdImplications] D. Meyer and D. Lewis: Architectural Implications of Locator/ID Separation, 2009. http://tools.ietf.org/html/draft-meyer-loc-id-implications-01. [AltAddrIPv6] M. O Dell: GSE An Alternate Addressing Architecture for IPv6, 2000. http://tools.ietf.org/id/draft-ietf-ipngwggseaddr-00.txt [RFC1955-1996] R. Hinden: New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG, 1996. http://tools.ietf.org/html/rfc1955. [LispAddr] D. Farinacci, D. Meyer, J. Snijders: LISP Canonical Address Format (LCAF), 2012. https://datatracker.ietf.org/doc/draft-farinacci-lisp-lcaf. [FARA-2003] D. Clark, R. Braden, A. Falk, V. Pingali, FARA: Reorganizing the Addressing Architecture, ACM SIGCOMM 2003 Workshops, August 25 & 27, 2003. #43
Literature (2/2) [PeerNet-2003] J. Eriksson, M. Faloutsos, S. Krishnamurthy, PeerNet: Pushing Peer-to-Peer Down the Stack, In IPTPS 03, February 20-21, 2003. [III-2002] I. Stoica, et.al., Internet Indirection Infrastructure, ACM SIGCOMM 02, August 19-23, 2002. [lisp-charter] Locator/ID Separation Protocol (lisp) working group. https://datatracker.ietf.org/wg/lisp/charter/ [HIP-IETF] Host Identity Protocol (HIP) working group. http://datatracker.ietf.org/wg/hip/charter/ [RFC5204-2008] Host Identity Protocol (HIP) Rendezvous Extension. http://tools.ietf.org/html/rfc5204 [RFC5201-2008] R. Moskowitz, P. Nikander, P. Jokela, and T. Henderson: Host Identity Protocol, 2008. http://tools.ietf.org/html/rfc5201. [RFC5205-2008] P. Nikander and J. Laganier: Host Identity Protocol (HIP) Domain Name System (DNS) Extension, 2008. http://tools.ietf.org/html/rfc5205. [RFC4960-2007] Stream Control Transmission Protocol, 2007. http://tools.ietf.org/html/rfc4960 #44