HIP research group 1 HIP-RG meeting, IETF 61 November 12, 2004 Tom Henderson Pekka Nikander

HIP research group 2 Agenda 5 min Agenda bashing 5 min RG status update 20 min Report from HIP and Related Architectures workshop 15 min HIP Experiment Report -draft-irtf-hip-experiment-00.txt 10 min New types of locators 15 min HIP Resolution and Rendezvous Problem Description -draft-eggert-hiprg-rr-prob-desc-00.txt 15 min NAT and Firewall Traversal for HIP -draft-tschofenig-hiprg-hip-natfw-traversal-00.txt 15 min Exchanging Host Identities in SIP -draft-tschofenig-hiprg-host-identities-00.txt -30 min Open mike discussion on HIP deployment or other topics

HIP research group 3 RG status update Mailing list: – Supplemental web page: – Charter –Evaluate benefit/impact of deploying HIP –Prepare report to IESG Modus operandi: Gain experience on HIP deployment –Experiment with software –Analyze HIP in context of real networks

HIP research group 4 RG drafts Several have asked whether we can have RG documents? We are chartered for at least one such document –HIP Experiment Report We can add more based on RG consensus Note: IRTF presently considering review and approval procedures for having a RG documents track

HIP research group 5 Report on HIP Workshop

HIP research group 6 Logistics Held on November 6 By invitation only, based on white paper submittal and other considerations 20 attendees –author from each submitted white paper –academic researchers from other projects (i3, NewArch, Delegation-Oriented Architecture, NIMROD) –RG chairs from Routing RG and DTN RG –IETF HIP, SIP, NSIS, MobIKE representation

HIP research group 7 1.Applying and deploying an ID/locator split –changing and managing applications and hosts –dealing with legacy infrastructure and middleboxes –introducing new infrastructure 2.Overlays, rendezvous, middleboxes, and delegation –advanced middleboxes and firewalls –advanced resolution and indirection 3.General architectural directions –late binding –encouragement of middleboxes in architecture –approaches (FARA, HIP, i3, NIMROD, multi6, etc.) Sessions

HIP research group 8 Session 1: Deployment Assume that users and networks want to deploy ID/locator separation How to “cross the chasm” between architecture and reality (Early Adopters)? Architectures and specs Deployed systems and workable infrastructure

HIP research group 9 Session 1 organization 1.Host: Implementing and managing an ID/locator split –host and application concerns 2.Network: Making it work in today’s networks –firewalls –middleboxes (existing NATs) –(resolution) infrastructure 3.Incentives: Application/user incentives for deployment –what are the killer apps?

HIP research group 10 Session 1: Conclusions Managing HIP is not a trivial task –HIP makes explicit some design choices that were implicit We have probably not paid enough attention to middlebox traversal –a key deployment concern No killer applications identified –Road Warrior and SIP explored –a framework for middlebox traversal? –or is HIP still a solution in search of a problem?

HIP research group Session 2: advanced infrastructure Maybe just one protocol (like in i 3 ) Maybe separated protocols (like HIP and ESP) Maybe additional protocols –Registration, middle box internal, …

HIP research group 12 Session 2: Open questions Rendezvous: overlay routing or name resolution? Bootstrap: how to find an infrastructure node? Layer 3.5 routing: –How much state in packet vs middle boxes? –How is the middle box state managed? –Effects of asymmetric routing? What are the limiting and decisive factors?

HIP research group 13 Session 2: Open questions (2) Address hiding and DDoS protection Combination of different types of middle boxes? Operations and management issues? –Debugging the system Dangers of having any centralization –Aim for decentralised infrastructure? How to manage free riding?

HIP research group 14 Session 3: Architecture Discussion on other identifier types –Identity-Based Cryptography (Boneh-Franklin) –flat identifiers (i3) Discussion of “what is HIP?” –A lot of functionality/features being overloaded into HIP –e.g. mobility management Other architectural comments –late-binding of locators to identity

HIP research group 15 Summary of workshop General value seen for HIP as “lowest location- independent identity in the stack” –are specific benefits enough to warrant deployment? Recognize that HIP includes: A: public key to identifier binding (inherent) B: identifier binding to locators –Consider whether these can be separated, and different choices for A –Consider more carefully what is the “core HIP”

HIP research group 16 Summary of workshop (2) How to coherently incorporate middle boxes? –Enumeration of what are the options –Discussion on legacy middle boxes and NATs Killer apps? –NAT, FW, IPv4/v6 transition –or are there none? Making configuration and management user- friendly is a hard problem

HIP research group 17 Experiment Report

HIP research group 18 Experiment report draft-irtf-hip-experiment-00.txt Intended to capture consensus for the IESG: –What are benefits and consequences of deploying HIP, or other ID/locator split? –What modifications to HIP are recommended? Contributions needed from early adopters and implementors

HIP research group 19 Current skeleton outline 1. Scope 2. HIP Architectural Overview 3. HIP Architectural/Deployment Impact –on hosts (stack, APIs, management) –on infrastructure (DNS, firewall/NAT, advanced overlays) 4. HIP Experience –management, NAT traversal, scaling, deploying infrastructure, impact on applications, implementation experience,...

HIP research group 20 Presentation of RG draft submissions

HIP research group 21 Software status

HIP research group 22 Software status Three current, public implementations of HIP available: –HIPL (HIP for Linux) (Helsinki HIIT) –FreeBSD HIP (Ericsson NomadicLab) –User-space Linux-based daemon (Boeing) Max OS X and Windows XP under development Boeing HIP testing server: – HIP infrastructure on PlanetLab (HIIT) –hi3 and OpenDHT integration

HIP research group 23 Software plans When can you start using HIP? For bleeding edge types-- now For early adopters (clean install, more user- friendly management)– maybe 6 months we would like feedback on HIP usability and management (of current implementations)

HIP research group 24 Questions to RG Do you favor continuing to meet on Friday afternoon of IETF? How many people intend to experiment with HIP once software is more available?

HIP research group 25 Open mike