Advanced Internet Technologies - uni-luebeck.de · Advanced Internet Technologies PD Dr. Dennis Pfisterer ... – Lack of addresses NAT No E2E anymore – Routing tables grow CIDR

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

...


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


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)


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


111 abc 567 def

111 567abc def


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

Advanced Internet Technologies - uni-luebeck.de · Advanced Internet Technologies PD Dr. Dennis Pfisterer ... – Lack of addresses NAT No E2E anymore – Routing tables grow CIDR

Documents