1. 11.09.2012 1 Lecture 2 - Internet evolution (part 2) D.Sc. Arto Karila Helsinki Institute for Information Technology (HIIT) arto.karila@hiit.fi T-110.6120 – Special Course in Future Internet Technologies M.Sc. Mark Ain Helsinki Institute for Information Technology (HIIT) mark.ain@hiit.fi

2. Evolutionary approaches Architectural 1. DNS (~1982) 2. EGP (precursor to BGP, ~1982) 3. TCP congestion control (mid-late 1980’s) 4. CIDR (~1993) 5. NAT (early 1990’s) 6. IPv6 (first RFC 1995, Internet standard 1998) 7. IPSEC (1995) 8. Mobile IP (~1996) 9. MPLS (~1996) 10. DiffServ / IntServ (~1998) 11. HIP (~1999, first RFC 2006) 12. BGPSec (mid 2000s) 13. DNSSec (~2004, first deployed at root level ~2010) 11.09.2012 2

3. Network Address Translation (NAT) – 4 types  Problem: address space exhaustion 11.09.2012 3

4. Network Address Translation (NAT) – 4 types 11.09.2012 4

5. Network Address Translation (NAT) – 4 types 11.09.2012 5

6. Network Address Translation (NAT) – 4 types  NAT is ugly, breaks E2E… but it works. 11.09.2012 6

7. IPv6 7  Problem: address space exhaustion  IPv6 was born in 1995 after long work  There are over 30 IPv6-related RFCs  The claimed improvements in IPv6 are: Large 128-bit address space Stateless address auto-configuration Multicast support Mandatory network layer security (IPSEC) Simplified header processing by routers Efficient mobility (no triangular routing) Extensibility (extension headers) Jumbo packets (up to 4 GB)

8. IPv6 11.09.2012 8  Major operating systems and many ISPs support IPv6  The use of IPv6 is slowly increasing in Europe and North America but more rapidly in Asia  In China, CERNET 2 runs IPv6, interconnecting 25 points of presence in 20 cities with 2.5 and 10 Gbps links  IPv6 really only solves the exhaustion of Internet address space

9. IPv6 11.09.2012 9 PlannedActual ?

10. IPSec 11.09.2012 10  Problem: security  IPSec is the IP-layer security solution of the Internet to be used with IPv4 and IPv6  Authentication Header (AH) only protects the integrity of an IP packet  Encapsulating Security Payload (ESP) also ensures confidentiality of the data  IPSec works within a Security Association (SA) set up between two IP addresses  ISAKMP (Internet Security Association and Key Management Protocol) is a very complicated framework for SA mgmt

11. Encapsulating Security Payload (IPv4) 11.09.2012 11 Original IPv4 Header Security Parameter Index (SPI) Sequence Number Coverage of Authentication UDP/TCP Header Data Padding Pad Len Next Hdr Authentication Data Coverage of Confidentiality ESP Header ESP Payload ESP Trailer

12. Encapsulating Security Payload (IPv6) 11.09.2012 12 ESP Payload Hop-by-Hop Extensions Security Parameter Index (SPI) Sequence Number Coverage of Authentication End-to-End Extensions Data Padding Authentication Data Coverage of Confidentiality ESP Header ESP Trailer Original IPv6 Header UDP/TCP Header

13. Mobile IPv4 11.09.2012 13  Problem: mobility  Basic concepts: Mobile Node (MN) Correspondent Node (CN) Home Agent (HA) Foreign Agent (FA) Care-of-Address (CoA)  The following can be problematic: Firewalls and ingress filtering Triangular routing

14. Mobility Example:Mobile IP Triangular Routing 11.09.2012 14 Home Agent Correspondent Host Foreign Agent Mobile Host Ingress filtering causes problems for IPv4 (home address as source), IPv6 uses CoA so not a problem. Solutions: (reverse tunnelling) or route optimization Foreign agent left out of MIPv6. No special support needed with IPv6 autoconfiguration DELAY! Care-of-Address (CoA) Source: Professor Sasu Tarkoma

15. Ingress Filtering 11.09.2012 15 Home Agent Correspondent Host Packet from mobile host is deemed "topologically incorrect“ (as in source address spoofing) With ingress filtering, routers drop source addresses that are not consistent with the observed source of the packet Source: Professor Sasu Tarkoma

16. Reverse Tunnelling 11.09.2012 16 Home Agent Correspondent Host Router Mobile Host DELAY! Firewalls and ingress filtering no longer a problem Two-way tunneling leads to overhead and increased congestion Firewalls and ingress filtering no longer a problem Two-way tunneling leads to overhead and increased congestion Source: Professor Sasu Tarkoma Care-of-Address (CoA)

17. 11.09.2012 17 Mobile IPv6 Route Optimization Home Agent Correspondent Host Router Mobile Host MH sends a binding update to CH when it receives a tunnelled packet. CH sends packets using routing header First, a Return Routability test to CH. CH sends home test and CoA test packets. When MH receives both, It sends the BU with the Kbm key. Secure tunnel (ESP) Source: Professor Sasu Tarkoma

18. Differences btw MIPv6 and MIPv4  In MIPv6 no FA is needed (no infrastructure change)  Address auto-configuration helps in acquiring CoA  MH uses CoA as the source address in foreign link, so no problems with ingress filtering  Option headers and neighbor discovery of IPv6 protocol are used to perform mobility functions  128-bit IP addresses help deployment of mobile IP in large environments  Route optimization is supported by header options 11.09.2012 18 Source: Professor Sasu Tarkoma

19. Extension Headers 11.09.2012 19 Mobility Header Upper Layer headers Data MH CN to MNMN to CN MN, HA, and CN for Binding MH Type in Mobility Header: Binding Update, Binding Ack, Binding Err, Binding refresh Source: Chittaranjan Hota, Computer Networks II lecture 22.10.2007

20. (G)MPLS  Problems: scalable transport, QoS, resource usage, business incentives etc.  (Generalized) Multi-Protocol Label Switching  Layer 2.5 protocol  High-performance transport of any layer 3 protocol over any layer 2 data link over any layer 1 medium  Routing via short path labels (path switching)  Layer 2 and layer 3 services (e.g. PtP and PtMP VPN)  Routing implemented in hardware (i.e. switching); much faster than IP longest-prefix matching 11.09.2012 20

21. (G)MPLS 11.09.2012 21

22. QoS  Problem: need better traffic control, satisfy business incentives, better services etc. 11.09.2012 22

23. DiffServ  Differentiated Services (DiffServ, RFC 2474) redefines the ToS octet of the IPv4 packet or Traffic Class octet of IPv6 as DS  Allows operators to control treatment of packets but does not guarantee any particular level of service or policy adherence across network boundaries.  The first 6 bits of the DS field are used as Differentiated Services Code Point (DSCP) defining the Per-Hop Behavior of the packet  DiffServ is stateless (like IP) and scales  Service Profiles can be defined by ISP for customers and by transit providers for ISPs  DiffServ is very easily deployable and could enable well working VoIP and real-time video  Unfortunately, it is not used between operators 11.09.2012 23

24. IntServ  Integrated Services  Unlike DiffServ, IntServ reserves network resources and attempts to guarantee conditions of network flow end-to-end  However, the process is complex, resource intensive, and requires supportive cooperating routers across all AS’s from source to sink. 11.09.2012 24

25. HIP 11.09.2012 25  Problems: mobility, security, multihoming, IPv4/IPv6 interoperation etc.  Host Identity Protocol (HIP, RFC4423) defines a new global Internet name space  The Host Identity name space decouples the name and locator roles, both of which are currently served by IP addresses  The transport layer now operates on Host Identities instead of IP addresses  The network layer uses IP addresses as pure locators (not as names or identifiers)

26. HIP Architecture 11.09.2012 26

27. HIP 11.09.2012 27  HIs are self-certifying (public keys)  HIP is a fairly simple technique based on IPSEC ESP and HITs (128-bit HI hashes)  HIP is ready for large-scale deployment  See http://infrahip.hiit.fi for more infohttp://infrahip.hiit.fi

28. Base exchange 11.09.2012 28 InitiatorResponder I1HIT I, HIT R or NULL R1HIT I, [HIT R, puzzle, DH R, HI R ] sig I2[HIT I, HIT R, solution, DH I,{HI I }] sig R2[HIT I, HIT R, authenticator] sig ESP protected TCP/UDP, no explicit HIP header User data messages solve puzzle verify, authenticate, replay protection draft-ietf-hip-base-02.txt, draft-jokela-hip-esp-00.txt Based on SIGMA family of key exchange protocols standard authenticated Diffie- Hellman key exchange for session key generation Select precomputed R1. Prevent DoS. Minimal state kept at responder! Does not protect against replay attacks.

29. HIP Mobility 11.09.2012 29  Mobility is easy – retaining the SA for ESP

30. HIP in Combining IPv4 and IPv6 11.09.2012 30 IPv4 access network Internet HIP MN Music Server WWW Proxy HIP CN  An early demo seen at L.M. Ericsson Finland (source: Petri Jokela, LMF)

31. BGPSec and DNSSec  Problem: security (within two critical architectural solutions)  BGP Security Extensions:  Authentication of inter-AS BGP data via Resource Public Key Infrastructure (RPKI) i.e. digital signatures  Does NOT provide confidentiality or guaranteed availability  Provides limited protection against certain mis- origination attacks  Not widely implemented 11.09.2012 31

32. BGPSec and DNSSec  DNS Security Extensions:  Authentication and integrity (of DNS query results) via digital signatures  Does NOT provide confidentiality or guaranteed availability  Protects against e.g. cache poisoning and other forgeries  Not widely implemented 11.09.2012 32

33. Key limitations, solutions, underlying ossifications 11.09.2012 33 Limitation(s)Solution(s)Key underlying ossification(s) Name-address translationDNS  Network vs. human-friendly naming dichotomy Scalability, routing inflexibility, combined addressing and transport TCP/IP, MPLS  Endpoint-centrism  Rigid core protocol stack CongestionTCP congestion control  Lack of built-in protocol-independent QoS  Rigid core protocol stack Traffic controlBGP, IGPs + EGPs  Endpoint-centrism  Send-receive communication paradigm Address space exhaustionCIDR, NAT, DHCP etc.  IPv4 Mobility, multihomingMIP, HIP  Endpoint-centrism  Rigid core protocol stack QoSDiffserv + Intserv  Lack of built-in protocol-independent QoS  Rigid core protocol stack SecurityVarious (e.g. DNSSec, BGPSec, and many others!)  Endpoint-centrism  Send-receive communication paradigm  Rigid core protocol stack

34. Evolutionary approaches Application-level 1. Scalable content delivery 1. DHTs (~2001) 2. P2P networks 3. CDNs (e.g. Akamai) 2. Security (confidentiality, anonymity, authentication etc.) 1. Asymmetric crypto (e.g. RSA ~1977 or ~1973, DH ~1976) 2. PGP (~1991) 3. SSL/TLS (mid-1990’s, late-1990’s) 4. PKI (1990’s) 5. VPNs E.g. PPTP (~1999) 6. Wireless security e.g. WPA/WPA2/EAP (late 1990’s and beyond) 7. Tor (mid 2000’s) 3. Cloud computing 11.09.2012 34

35. Distributed Hash Table (DHT)  Distributed Hash Table (DHT) is a service for storing and retrieving key-value pairs  There is a large number of peer machines  Single machines leaving or joining the network have little effect on its operation  DHTs can be used to build e.g. databases (new DNS), or content delivery systems  BitTorrent is using a DHT  The real scalability of DHT is still unproven  All of the participating hosts need to be trusted (at least to some extent) 11.09.2012 35

36. DHT 11.09.2012 36  The principle of Distribute Hash Table (source: Wikipedia)

37. 27/1/2010 37 Overlay Routing  In overlay routing the topology is formed over an underlying (usually IP) network  DHTs are examples of overlay routing  DHT techniques can be utilized e.g. in implementing non-hierarchical rendezvous  An example of DHT-based solutions is the Content Addressable Network (CAN)  CAN is based on a d-dimensional Cartesian space, each node having a coordinate zone that it is responsible for

38. 27/1/2010 38 CAN  A two-dimensional example

39. 27/1/2010 39 Chord Ring  Greedy forwarding (cmp w/ ROFL)

40. 27/1/2010 40 Pastry DHT  An example with hexadecimal identifiers

41. P2P networks & CDNs  Napster, Gnutella, BitTorrent (also utilizes DHT) etc.  Akamai CDN 11.09.2012 41

42. Security  Confidentiality, anonymity, authentication etc. 1. Asymmetric crypto (e.g. RSA ~1977 or ~1973, Diffie-Hellman ~1976) 2. PGP (~1991) 3. SSL/TLS (mid-1990’s, late-1990’s) 4. PKI (1990’s) 5. VPNs e.g. PPTP (~1999) 6. Wireless security e.g. WPA/WPA2/EAP (late 1990’s and beyond) 7. Tor (mid 2000’s) 11.09.2012 42

43. Cloud computing  Computing resources are delivered via the network  “x”aaS i.e. “x” as a service  E.g. software, storage, processing etc.  Goal is to achieve resourcefulness and efficiency via computing economies of scale  Examples:  Amazon, Apple, Google etc. 11.09.2012 43

44. For next week…  READ (lecture 3):  M. Handley. 2006. Why the Internet only just works. BT Technology Journal 24, 3 (July 2006), 119-129. DOI=10.1007/s10550-006-0084-z http://dx.doi.org/10.1007/s10550-006-0084-z http://dx.doi.org/10.1007/s10550-006-0084-z  READ (lecture 4):  Van Jacobson, Diana K. Smetters, James D. Thornton, Michael F. Plass, Nicholas H. Briggs, and Rebecca L. Braynard. 2009. Networking named content. In Proceedings of the 5th international conference on Emerging networking experiments and technologies (CoNEXT '09). ACM, New York, NY, USA, 1-12. DOI=10.1145/1658939.1658941 http://doi.acm.org/10.1145/1658939.1658941 http://doi.acm.org/10.1145/1658939.1658941 11.09.2012 44

45. 11.09.2012 45 Thank you for your attention! Questions? Comments?