2.8.20 Host Identity Payload (hip) BOF

Current Meeting Report

Thursday, 8/9 1300-1400

BOF Chair: Tim Shepard
Notes taken by: Aaron Falk

Agenda bashing
HIP Review
Comments on HIP and IPv6

HIP Review - Bob Moskowitz

(powerpoint presentation)

New core document: draft-moskowitz-hip-04.txt

HIP, IPv6 and Mobility: Some Random Rants - Pekka Nikander

(powerpoint presentation)

Promising New Technologies & HIP - Paul Francis

(powerpoint presentation)


Tim Shepard: need to discuss what to proceed with as initial problem

Key exchange, mobility, NAT traversal, host multihoming, site multihoming

David Black: IPsec is doing NAT traversal, HIP shouldn't solve this

John Wrocklaski: been many proposals of this class over years, this is best of the lot, focusing on one problem may miss some of the issues that need to be addressed, perhaps having different people looking at each of a set of problems. This solves many of the IPv4 problems and so focus shouldn't be on v6. SO, IPv6 multihoming is a poor choice.

Scott Brim: yes, go forward now with a specific goal. Something everybody agrees is a problem but is politically acceptable: site multihoming.

Dana Blair: Can't address host/site multihoming and mobility separately. Solve route optimization for mobile hosts and mobile networks. This is the most pressing and v6 is floundering in this area.

Andrew McGregor: need to accept that there will be consequences in multiple applications but starting with focus on single app is good start. Starting with v6 may promote v6 app deployment.

Francis ???: something about address management being a tough problem

Luis Sanchez: many solutions in process for NAT traversal and key exchange. Focus this solution on these problems may not be too attractive. Perhaps better to focus on mobility and multihoming issues.

Erin Fleishman, Boeing: would be overjoyed if mobility and multihoming topics were addressed. (of great interest to our corporation)

John W.: Dana got it right. Question is one of scope. Schemes like HIP give lots of flexibility. A) work to v6 mobility for scope or B) look at broader approach to solving problems. Look at problem space with potential for better solution is preferable to taking someone else's requirements and designing to them.

Dave Oran: (older but not wiser :) Two aspects to solution: 1.a broad enough class of problems to get over deployment energy barrier. 2. challenging IESG guidance: IETF needs to look at broader class of problems.

Steve Bellovin: Things deploy well in Internet if they can deploy gradually from the edges with little or no involvement from system or network administrators. IPv6 needs help in middle, SSH doesn't. Think about how two consenting machines can speak HIP to each other with little or no overhead or stuff in the middle.

Scott Bradner: Need carrots to encourage deployment. But want to avoid boiling the ocean. A single or small number of 'poster child' is helpful for understanding applications of the technology.

Paul Francis: picking a problem is helpful to focus manpower. Nit: IPv6 can be deployed without changing the middle b/c of 6to4.

Ross Calhoun, Juniper: One host doing HIP is not interesting. So, solving for v4 may not be worthwhile. Solving multihoming may be big benefit for Internet. Mobile hosts/handsets will motivate deployment of v6. So, solving mobile host and multihoming problem is 'right sized bite.'

Bob Moskowitz.: charter should contain core concepts of HIP and specific cases of handful of problems. This is a broad tool. IPv4 community may want to apply some of the solutions.

Gab Montenegro: additional items for list: when N nodes create a routing fabric, as in MobileIPv6 or Manet. We should hear from Manet folks to see if this is applicable. Also, RSERPOOL needs security and this might help.

Andrew: regarding Manet: this helps not only with routing stability, but also with very large manet-style networks.




HIP General