hip research group 1 hip-rg meeting, ietf 61 november 12, 2004 tom henderson...

1HIP research group

HIP-RG meeting, IETF 61

November 12, 2004

Tom Henderson{thomas.r.henderson@boeing.com}

Pekka Nikander{pekka.nikander@nomadiclab.com}

2HIP research group

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

3HIP research group

RG status update

• Mailing list: – http://honor.trusecure.com/mailman/listinfo/hipsec-rg

• Supplemental web page:– http://hiprg.piuha.net/

• 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

4HIP research group

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

5HIP research group

Report on HIP Workshop

6HIP research group

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

7HIP research group

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

8HIP research group

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)?

Architecturesand specs

Deployed systemsand workableinfrastructure

9HIP research group

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?

10HIP research group

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 i3)•Maybe separated protocols (like HIP and ESP)•Maybe additional protocols–Registration, middle box internal, …

12HIP research group

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?

13HIP research group

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?

14HIP research group

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

15HIP research group

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”

16HIP research group

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

17HIP research group

Experiment Report

18HIP research group

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

19HIP research group

Current skeleton outline

1. Scope2. HIP Architectural Overview3. 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, ...

20HIP research group

Presentation of RG draft submissions

21HIP research group

Software status

22HIP research group

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:

– http://hipserver.mct.phantomworks.org

• HIP infrastructure on PlanetLab (HIIT)– hi3 and OpenDHT integration

23HIP research group

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)

24HIP research group

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?

25HIP research group

Open mike