Gathering Presentation Template

1
HIP-RG meeting, IETF 61 November 12, 2004
Tom Henderson thomas.r.henderson_at_boeing.com Pek
ka Nikander pekka.nikander_at_nomadiclab.com
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

3
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

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

5
Report on HIP Workshop
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

7
Sessions

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

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

Deployed systems and workable infrastructure
Architectures and specs
9
Session 1 organization

• Host Implementing and managing an ID/locator
  split
• host and application concerns
• Network Making it work in todays networks
• firewalls
• middleboxes (existing NATs)
• (resolution) infrastructure
• Incentives Application/user incentives for
  deployment
• what are the killer apps?

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?

11
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,

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?

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?

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

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

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

17
Experiment Report
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

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, ...

20
Presentation of RG draft submissions
21
Software status
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
• http//hipserver.mct.phantomworks.org
• HIP infrastructure on PlanetLab (HIIT)
• hi3 and OpenDHT integration

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)

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?

25
Open mike