44
Advanced Internet Technologies PD Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/pfisterer Future Internet Research
Advanced Internet Technologies
PD Dr. Dennis Pfisterer
Institut für Telematik, Universität zu Lübeck
http://www.itm.uni-luebeck.de/people/pfisterer
Future Internet Research
• Growth– Lack of addresses � NAT � No E2E anymore
– Routing tables grow � CIDR and topological assignment of addresses � No flexible address assignment
• Mobility
New requirements on TCP/IP
• 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)
#3Source: http://bgp.potaroo.net/as2.0/bgp-active.html
Growth: BGP Entries [RFC4984-2007]
1.500.000
2.000.000
#4
0
500.000
1.000.000
2005 2006 2011 2020
(projected)
• Goal
– Balance load on multiple links
Traffic Engineering
Internet
ISP#1
ISP#2
• Realization
– Use of BGP
– Selective advertisement of more-specific routes on different links
#5
Internet
Example net/23
net/22
Example net/23
Multi-homingMulti-homing
#6
• 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
Multi-homing
– Important for business-critical applications
– Internet connections have become inexpensive �more frequent use multi-homing
– Sometimes mandatory due to contract or law
#7
InternetMultihomed
Network
Router ISP #1
ISP #2
• Multiple ISPs, multiple interfaces per host
– 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
Multi-homing Variants
– 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
– 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
#8
• 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
Provider-Independent (PI) Address Space
• 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
• Customers– Flexibility (change providers)
– Multihoming (more than one provider)
– Session survivability (no breaking TCP connections)
�PI address space
Conflicting Interests
�PI address space
• Providers– Routers should scale (more customers) and be cost-effective
– Traffic Engineering (w/o adding many routing table entries)
– Minimize the number of routing table entries
�PA address space (provider aggregateable)
#10
• 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
Current Routing Issues
– 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
• Open issues
– Multi-homing
– Traffic engineering
– Mobility
Summary
– Mobility
• Multiple (partial) solutions proposed
– Stream Control Transmission Protocol (SCTP)
– Locator Identifier Split
Security - 04 Cryptology #12
Stream Control Transmission Protocol (SCTP)Stream Control Transmission Protocol (SCTP)
#13
• TCP offers a stream-based interface – Most applications exchange messages
– Requires de-/framing
Issues with TCP and UDP
• 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
• Designed to transport Public Switched Telephone Network (PSTN) signaling messages (SS7) over IP networks– Not limited to this application domain
SCTP Overview
– 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
...
Security - 04 Cryptology #16
Network
Transport
Data Link Ethernet WiFi ATM ...
IPv4 IPv6
TCP UDP SCTP
• Message: Application-level data unit
• Stream: Unidirectional message stream
– Unlike TCP which provides a single bidirectional byte-oriented stream
Streams and Associations
• SCTP bundles multiple streams in so-called associations
• Association: Connection between two SCTP endpoints
#17
Association
Stream #1
Stream #2
Stream #3
• 4-way handshake to initiate connections– Stateless setup to avoid DoS attacks (cf. SYN cookies)
Association Setup
INIT
INIT ACK
- Contains cookie (hash of INIT and
signature)
• Initially, additional IP addresses are exchanged– Client and server mutually know all other IP addresses
– Can include IPv4 and IPv6 addresses
Security - 04 Cryptology #18
COOKIE ECHO
- Cookie from INIT ACK
- Validates MAC
- Create connection state
COOKIE ACK
- Create connection state
• SCTP packet
– Contains header and one or more chunks
• Chunk
– Data (containing messages) or control (handshake, shutdown, …) chunks
– Encapsulated in an SCTP packet
Packets and 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
#19
Stream #1
Stream #2
Stream #1
Stream #2
SCTP Packet
Data Chunk
SCTP
HeaderData Chunk Control Chunk Data Chunk
• TCP and UDP
– TCP: reliable, in-order delivery, byte-stream channel
– UDP: unreliable, message-oriented datagram service
– Missing: reliable, message-oriented service
Message Delivery
• SCTP supports
– acknowledged
– error-free
– non-duplicated transfer
of messages
• Sequenced delivery of messages
– Optional: request out-of-order delivery per-message
#20
• 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
Multi-homing Support
• Definition: Path– Network route between two SCTP endpoints
– Primary path: Currently active (default) path
#21
Path #1
Path #2
• 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
Multi-homing Support
• Fault tolerance – At either or both ends of an SCTP association
– If a path fails, another one becomes the active path
#22
Path #1
Path #2
• Operating Systems– AIX Version 5
– Cisco IOS 12
– DragonFly BSD since version 1.4
– FreeBSD version 7
SCTP Implementations
– 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 SplitLocator Identifier Split
#24
• 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)
Identifiers and Locators
– Routing (deliver packets to a system)
• IP-Addresses have two roles/semantics
– Identifiers: interfaces of hosts
– Locators: name of topological locations
#25
• 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, …
Identifiers and Locators
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
• Network Address Translation (NAT)
• Application Layer Names
Locator/Identifier Split: Potential Solutions
• Use DNS names as identifiers
• Introduce a new layer
#27
• 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
Network Address Translation (NAT)
• Example: Destination NAT– Only incoming traffic considered
#28
InternetInternal IP
addresses
Router ISP #1
ISP #2
External IP Internal IP
141.182.164.1 192.168.0.1
88.34.123.1 192.168.0.1
141.182.164.2 192.168.99.2
88.34.123.2 192.168.99.2
Destination NAT
• 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
Application Layer Names
• 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
• 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
Introduce a New Layer
Transport
Application
Identifiers
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)
#30
New Layer
Link Layer
Internet Locators
• 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
2. Send packet with unspecified source locator
3. Egress router adds source locator
Address Rewriting
IPv6 address split into:
Network (64 Bit)
Locator
Host (64 Bit)
Identifier
3. Egress router adds source locator
4. Ingress router removes destination locator and forwards packet to destination identifier
5. Destination interface receives packet
#31
InternetInternal
network
Internal
network
ResolverResolves Id � Loc
Source Dest. Payload
--- abc 567 def
Source Dest. Payload
111 abc 567 def
111 567abc def
Source Dest. Payload
111 abc --- def1.)
2.) 3.)
4.)5.)
• Procedure1. 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
Map-and-Encap [RFC1955-1996]
• Suggests that the identifier may need to be routable in some scope − Likely scoped to the current internal network
#32
InternetInternal
network
Internal
network
Identifier Payload Identifier Payload
Locator Identifier Payload
MapperResolves Id � Loc
1.)
2.)
3.)
4.) 5.)
Locator Identifier Separation Protocol (LISP)Locator Identifier Separation Protocol (LISP)
#33
• Standardized by the IETF
– Locator/ID Separation Protocol (lisp) working group [lisp-charter]
– Base standard in [RFC5201-2008]
– Integration with DNS in [RFC5205-2008]
Locator Identifier Separation Protocol (LISP)
• 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
• Two addresses– Locator: Routing Locator (RLOC)
– Identifier: Endpoint Identifier (EID)
• Based on Map-and-Encap
LISP Architecture
Application
• 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]
#35
Internet
Transport
Link Layer
Internet
Identifiers
Locators
Host Identification Protocol (HIP)Host Identification Protocol (HIP)
#36
• Introduces new layer – Between transport and network layer
• Requires hosts to support HIP
Host Identification Protocol (HIP)
Transport
Application
Identifiers• Requires hosts to support HIP– No changes to the network
• Goals: Integrate…– mobility,
– multi-homing, and
– security
across IPv4 and IPv6
#37
HIP Layer
Link Layer
Internet Locators
• Two addresses– Locator: IP address
– Identifier: Host Identity Tag (HIT)
HIP Architecture
• 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
• DNS � HIT
– Use of DNS to map hostnames to HIP identities
– Clients query for HIP records
– Contains
HIP Name Resolution
– Contains
• HIP identity (public key) and HIT
• Rendezvous server for mobile hosts (optional)
• HIT � IP addresses
– Different options available (see next slide)
#39
• 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]
HIP Name Resolution
• 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
• Four way handshake
– Diffie-Hellman key exchange
– Mutual authentication
– Stateless to avoid DoS attacks (cf. TCP SYN cookies)
HIP Connection Setup
• Creates a security association between both endpoints
– After connection setup, packets are encrypted using IPSec
#41
Client Server
HITC, HITS or NULL
HITC, HITS, challenge
HITC, HITS, response, signature
HITC, HITS, signature
• Mobility isn’t an issue because…– …only IP addresses change
– …the HIT address remains unchanged
HIP: Mobility Support
• 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: updated mapping service• Protocol depends on mapping service
• Examples: DNS, rendezvous server, …
#42
• [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.
Literature (1/2)
• [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-ipngwg-
gseaddr-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
• [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/
Literature (2/2)
• [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
