host identity protocol

host identity protocol PowerPoint PPT Presentation


  • 384 Views
  • Updated On :
  • Presentation posted in: Sports / Games

Introduction: What and why?BackgroundHIP in a NutshellMobility and multi-homing (multi-addressing)HIP infrastructure: Hi3Current statusSummary. Presentation outline. What is HIP?. HIP = Host Identity ProtocolA proposal to separate identifier from locator at the network layer of the TCP/IP stackA new name space of public keysA protocol for discovering and authenticating bindings between public keys and IP addressesSecured using signatures and keyed hashes.

Download Presentation

host identity protocol

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


1. Host Identity Protocol June 15, 2005 Pekka Nikander Ericsson Research Nomadiclab and Helsinki Institute for Information Technology http://www.hip4inter.net

3. What is HIP? HIP = Host Identity Protocol A proposal to separate identifier from locator at the network layer of the TCP/IP stack A new name space of public keys A protocol for discovering and authenticating bindings between public keys and IP addresses Secured using signatures and keyed hashes

4. 8 minutes8 minutes

6. Background A brief history of HIP Architectural background Related IETF Working Groups

9. New requirements to Internet Addressing Mobile hosts Need to change IP address dynamically Multi-interface hosts Have multiple independent addresses Mobile, multi-interface hosts most challenging Multiple, dynamically changing addresses More complex environment e.g. local-only connectivity

10. HIP WG chartered for experimental RFCsHIP WG chartered for experimental RFCs

12. HIP in a Nutshell Architectural change to TCP/IP structure Integrates security, mobility, and multi-homing Opportunistic host-to-host IPsec ESP End-host mobility, across IPv4 and IPv6 End-host multi-address multi-homing, IPv4/v6 IPv4 / v6 interoperability for apps A new layer between IP and transport Introduces cryptographic Host Identifiers

17. Emphasise: no extra encapsulation or header in regular user data. In theory: many encapsulating protocols; only ESP fully specified. Emphasise: no extra encapsulation or header in regular user data. In theory: many encapsulating protocols; only ESP fully specified.

20. One way to implement HIP

21. Using HIP with ESP

25. Signalling carrier Originally HIP supported only ESP-based user data transport (previous slides) ESP is now being split from the base protocol Base protocol is becoming a secure carrier for any kinds of signalling Support for separate signalling and data paths Implicitly present in the original design Now being made more explicit

28. Introduction to IP based mobility and multi-homing Mobility implemented at “lP layer” IP addresses are assigned according to topology Allows for routing prefix aggregation Mobile hosts change their topological location Multi-homed hosts present at many locations In an IP based m&m solution Transport & apps do not see address changes or multiple addresses

32. Multi-addressing dimensions

41. Distributed Hash Tables Distributed directory for flat data Several different ways to implement Each server maintains a partial map Overlay addresses to direct to the right server Resilience through parallel, unrelated mappings Used to create overlay networks

42. i3 rendezvous abstraction Trigger inserted by receiver(s) Packets addressed to identifiers i3 routes packet to the receiver(s)

43. Hi3: combining HIP and i3 Developed at Ericsson Research IP Networks Uses i3 overlay for HIP control packets Provides rendezvous for HIP Data packets use plain old IP Cryptographically protected with ESP Only soft or optional state in the network

47. An Internet control plane? HIP separates control and data traffic Hi3 routes control traffic through overlay Control and data packets take potentially very different paths Allows telecom-like control … … but does not require it

48. Benefits for everyone Operators Control, security, resilience, revenue Enterprises Security, resilience, mobility Individual users Security, mobility, ease of use

49. Benefits to operators More controlled network Data requires HIP handshake first Protection against DoS and DDoS Resilience Integrated multi-homing No single points of failure

50. Benefits to enterprises More secure firewalls Integrated mobility and multi-access Across IPv4 and IPv6 No single points of failure

51. Benefits to users DoS and DDoS protection Supports home servers (NAT traversal) Configuration free baseline security (ssh-like leap-of-faith encryption

52. Introduction: What and why? Background HIP in a Nutshell Mobility and multi-homing (multi-addressing) HIP infrastructure: Hi3 Current status Summary Presentation outline

53. Current status WG and RG formed at the IETF / IRTF First meetings in Seoul, March 2004 Four known interoperating implementations A number of internet drafts Base specifications start to be mature About a dozen papers published or submitted

54. Implementation status Four interoperating implementations Ericsson Research Nomadiclab, FreeBSD Helsinki Institute for Information Tech., Linux Boeing Phantom Works, Linux and Windows Sun Labs Grenoble, Solaris Other implementations Indranet (obsolete), DoCoMo US Labs, rumours about other

56. Evolution of drafts: Restart

57. Evolution of drafts: Currently HIP WG chartered for experimental RFCsHIP WG chartered for experimental RFCs

60. New cryptographic name space IP hosts identified with public keys Integrates security, mobility, multi-homing Evolving into a more generic signalling carrier Four interoperating implementations (total 7?) Base specifications start to be mature http://www.hip4inter.net http://www.tml.hut.fi/~pnr/publications/ Summary

61. Backup / other slides

62. 20 minutes20 minutes

63. NAT traversal Legacy NAT traversal Apply ideas from STUN/ICE/STUNT... to HIP UDP tunneling Short term solution with a clear exit strategy SPI-NAT or architected NAT Make NAT aware of HIP messages Allow servers to register at the NAT Learn mappings for HITs and ESP SPIs

64. Upper layer identifiers Backward compatible APIs Current APIs form a major legacy asset HIP allows almost all applications to continue unmodified (no recompilation required) Q: Use HITs / IP addrs / both as the ULID? New APIs Host vs. Session vs. Service identifiers? Using delegation? Some people disagree with “almost all” - e.g. diagnostic applications excludedSome people disagree with “almost all” - e.g. diagnostic applications excluded

67. 12 minutes This is our plan, what we consider likely to happen. This is ongoing research!12 minutes This is our plan, what we consider likely to happen. This is ongoing research!

68. Initial exploration Pair-wise host-to-host deployment e.g. my laptop and my personal server HITs typically stored in /etc/hosts 192.0.2.1 myserver 43bc:4521:4933:956c:3445:956d:ed23:3420 myserver Initial public test servers in the Internet hipserver.hiit.fi

71. Initial exploration: Benefits End-to-end security between client and server Trust based on static configuration Client mobility and multi-homing Even across IPv4 / IPv6 boundaries IPv4 / IPv6 API-level interoperability Protection against CPU / memory DoS attacks Soon: Client-side NAT traversal For plain client–server TCP / UDP protocols v4 / v6 mobility requires that the server is reachable with both v4 and v6. NAT-traversal is in the works, works for most TCP / UDP based protocolsv4 / v6 mobility requires that the server is reachable with both v4 and v6. NAT-traversal is in the works, works for most TCP / UDP based protocols

72. Initial exploration: Challenges Per-host management of a new name space Policy configuration Semantics for unsuccessful handshakes Management of keys and address bindings Privacy management Address resolution from HIT to IP address without any infrastructure Must be explicitly configured Most of the challenges are NOT specific to HIP but apply to any technology that enters this spaceMost of the challenges are NOT specific to HIP but apply to any technology that enters this space

73. Early infrastructure Pair-wise deployment between early adopters e.g. my laptop and your experimental server Store HITs in the DNS as AAAA RRs Look like non-routable IPv6 addresses Returned as the last entry in an RR set Experimental rendezvous (Hi3) at PlanetLab Infrastructure for passing HIP packets 16 minutes16 minutes

74. No new work on NAT, just applying existing work! May not work with symmetric NATs STUN, ICE, Paul Francis’es STUNTNo new work on NAT, just applying existing work! May not work with symmetric NATs STUN, ICE, Paul Francis’es STUNT

75. Storing HITs into AAAA is a temporary hack The idea is that they are returned last in the RR setStoring HITs into AAAA is a temporary hack The idea is that they are returned last in the RR set

76. Early infrastructure: (Additional) benefits Opportunistic security between participants Perhaps build trust with DNSSEC Simultaneous mobility; i.e., mobile servers Increases the cost of some flooding DoS attacks Potential attacker needs to solve the HIP puzzle before getting the real IP address NAT traversal for both client and server Unlikely to work for symmetric NATs

77. Enhanced infrastructure Internet-wide experimental deployment Stable rendezvous service Store HITs in the DNS using new RRs Benefits as before but larger audience Results to be reported in HIP RG experiment report Input to the IETF community

78. Markets take over:HIP on selected vertical markets Potential markets Multi-homed road warriors Operations and management Military or dual-use systems High-availability systems Mobile public networks e.g., municipal 802.11 networks What may happenWhat may happen

80. Upper Layer IDsPreliminary thoughts

85. From virtual hosts to services

  • Login