1 / 25

HIP-RG.meeting at IETF 61: Summary, Discussions, and Workshops

This document provides a summary of the HIP-RG.meeting at IETF 61, including discussions on the status update, experiment reports, new types of locators, NAT and Firewall Traversal for HIP, and more.

charlesdmiller
Download Presentation

HIP-RG.meeting at IETF 61: Summary, Discussions, and Workshops

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HIP-RG meeting, IETF 61 November 12, 2004 Tom Henderson {thomas.r.henderson@boeing.com} Pekka Nikander {pekka.nikander@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 today’s 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

More Related