Host Identity Protocol BOF (hipbof)

Decisions

1. Is this an interesting technical problem to pursue in the IETF?

   Yes

2. Do we have enough of additional people that would participate?
   1. Security?

      3 hands raised (Bill Sommerfeld, Perry Metzger, one unidentified)

   2. DNS?

      No hands raised, but Randy Bush noted that the needed basic DNS Resource Record is trivial. Thomas Narter noted that there is clearly need for some help from the DNS working groups.

   3. Applications?

      No hands, but the appsarea meeting was taking place at the same time. Additionally, there was on Wednesday a separate meeting with the applications people.

   4. Routing?

      3 or 4 hands, depending what "HIP and routing means"

3. Do we have enough information to decide about a WG?

   Yes, after answering some clarifying questions.

4. Should we have a working group?

   Yes, after answering some clarifying questions, provided that there will be successful charter discussions.

Summary of discussions

This summary has been compiled by Pekka Nikander, based on the discussion minutes, included below.

The scope of the proposed charter was perceived as too ambitious for a working group. Several people voiced that the working group should focus on making a minimal usable solution, or a core solution, and the rest of the work should probably be moved to an IRTF research group.

The referral problem was perceived as decidedly the hardest problem, and probably one of the main focus areas for a potential RG. The problem is also not only related to HIP, but to almost any solution based on separating identifiers and locators.

Points to pay attention to

• The current documents discuss implementation in various places. This discussion should be moved into appendices.
• More working is needed to clarify the problems that the identifier / locator separation is a solution to. That will help other people to understand the scope of the HIP work.
• More work is needed to study how HIP and IPsec work or do not work together. This is especially relevant to running HIP and IKE in parallel or in some other combination.
• NAT traversal was seen as a hard problem, and there wasn't any clear consensus on how to tackle it.

Presentations and Discussion

Introduction to HIP

Pekka Nikander did a nice overview of HIP. He pointed out that HIP doesn't map cleanly into any IETF area, but it could become the next "waist" of the IP protocol stack. HIP uses ESP in transport mode, has a four-way handshake for association setup, and is DoS-resistent - R1 packet is cryptographic, but is precomputed.

Pekka also pointed out that the mobility/multihoming drafts are much less mature than the base protoco spec, etc.

Keith Moore:

HIP is nice, but being oversold. It has a lot of brilliant ideas, but it doesn't solve all of the claimed problems, it helps to solve them. You need to clarify what HIP does & doesn't.

Pekka Nikander:

I agree. I don't remember what I said during the talk, but if I said that HIP "solves" the problems, it was wrong. HIP provides mechanisms to solve these problems, but as it stands now, it does not "completely" solve the problems.

Jim Bound:

Too much overlap between protocol specification and implementation description in the documents - this needs to be removed before entry into standards track. How to rebuild our stacks is none of the IETF's business. What do you want in terms of standards?

Pekka Nikander:

We have been trying to move implementation level issues to appendices. It is well possible that not all has been moved. If there are still sections that talk too much about implementation, they need to be moved to an appendix, too.

David Ward:

Please note, too, that the architecture document is headed towards informational RFC, and informational documents may discuss implementation issues.

Erik Nordmark:

Do we know about claimed IPRs on this?

Pekka Nikander:

We don't know for sure. There may be IPR claimed on the puzzle. However, given how the current puzzle implementation is, my personal belief is that there shouldn't be any. It is also possible that there are IPRs on the Diffie-Hellman MODP groups, but based on discussions at the IPsec WG it does not seem to be a problem.

Eric Fleischman:

Bob Moskowitz says he won't patent his contributions. Neither does Boeing.

Bill Sommerfeld:

Given my understanding of the patent law, it isn't sufficient to say there are no IPR claims.

Eric Fleischman:

All I am saying is that Bob Moskowitz does not have any IPR on this.

Margaret Wasserman:

If this becomes a working group, we need to look at the IPR issues then.

Perry Metzger:

Why WG for experimental documents? What is the policy for experimental documents?

Thomas Narten:

Currently the IPR requirements are for standards-track documents, not experimental. However, there are new policies in the IETF with respect to IPR and experimental track documents. Hence, the IPR status need to be declared for all documents.

David Ward:

We clearly need to investigate whethere there are IPRs or not.

Eric Rescorla:

How does HIP play with IPsec? Is the assumption that you want to use IKE and IPsec over the top of HIP?

Andrew McGregor:

Well, you could do both, but then you would end up encryptiong twice. Or, you could HIP to establish some SAs and IKE to other ones. Depending on implementation, you could use policies to control this.

Niko Williams:

Does server need to do public key operations before reverse routability verification? What is the computational load on server? How about DNSsec or certificates?

Pekka Nikander:

From our point of view, I would say that HIP is not so much of IPsec. Bob Moskowitz assumed that people would be doing ESP anyway, so the default is to use ESP. However, architecturally HIP could be implemented without any IPSec at all. The exact way of doing that is just not specified as of now.

What comes to return routability and server load, the R1 packet is precomputed. Hence, the server isn't vulnerable to DoS attacks at that point.

We deliberately left DNSsec and certificates out of the scope for now. They were there before, but their usage depends so much on what do you want to use HIP for that it is better to scope them out.

(?):

Have you tested mobility and renumbering?

Pekka Nikander:

Yes, there will be demo of this in a few minutes.

Steve Kent:

This is a solution looking for a problem. IPsec is much more than just ESP. Hence, you're not doing IPSec, you're just doing ESP.

Pekka Nikander:

You can say that we are not doing IPsec but only ESP if you want to express it in that way. What coems to the problem, there seems to be a need to separate identifiers from IP addresses. This is one possible answer to that problem, and we need to understand better the properties of this.

Steve Kent:

A solution must fit within prespecified constraints, and I have haven't heard any of such constraings.

Perry Metzger:

Don't break a butterfly on the wheel. This is an experiment. We need more of them. I think this is a great idea. For once we have a bunch of people going out doing something that may not provide all answers at once.

Eric Fleischman:

We tried doing requirements first last time; that's why we're not a WG now!

Keith Moore:

It is more correct to say that identifier/location combination is a design compromise, not merely wrong.

Steve Kent:

A question to the ADs. If the intent is to create an experimental document, why is this being proposed for IETF, why not IRTF?

Thomas Narten:

IRTF is research, IETF is engineering. We are trying to engineer bits on the wire.

Steve Kent:

For what I have heard, we want to play with this until we know what it's good for. Engineering is about solving problems, not playing with something to see if it's useful.

Margaret Wasserman:

In materials engineering, you may have a new material and it is still engineering to see whether it best fits a problem. We do know some of the problems we are working on. We already have implementations. The idea is to see how this fits within the rest of the system This isn't strictly an experiment.

Pekka Nikander cut the discussion short to continue with the agenda.

Demo of current implementations

Keith Moore:

I want to point out that this is not so wonderful as it might seem. It doesn't live up to the claims being made for HIP. What if both sides move at once? I challenge you to work with both hosts moving concurrently, to create a demo that shows that this is a practical solution, not a toy.

Jeff Ahrenholtz(?):

This is experimental, this isn't complete.

Keith Moore:

So there are still probably issues that need to be looked at. This is interesting technology but not complete.

David Ward:

Of course. That is why we want to do a WG on this. We just want to avoid working in the dark.

Presentation by Steven Venema from Boeing

Steven Venema from Boeing briefly described their plans of possibly using HIP all over in the Intranet.

Charter discussion

Tim Shepard:

I chaired the earlier HIP BOFs. Very soon after the second HIP BOF, I was not in favour of forming a HIP WG.

Today, I use SSH instead of IPsec. SSH became popular because it was an effective solution for the problems people had. I hope that HIP does get there. If we look at engineering in the world, there _are_ a lot of things that are done bottom up, and that is wonderful.

I hope that the development of HIP can proceed like this, and I am not convinced that an IETF WG can help. I am not sure that bringing HIP to the IETF is the right thing. If SSH had been brought into the IETF earlier than it was, it might not be as valuable as it is today. I'm not actually sure for HIP what is the best thing to do. I am ambivalent.

James Kempf:

You should get rid of the proposed charter items 9 & 10 (Implementation report & MIB), they are standardization items and shouldn't be part of experimental. I think that the biggest problem is the rendezvous server. There are other proposals around for separating identifiers and locations without cryptographic keys. They need to be also considered. We need to understand if a cryptographic name space has any additional value.

David Ward:

The intention of putting up an implementation report is to separate implementation techniques from the specification.

Erik Nordmark:

It is good to continue to explore HIP, and a WG is a good way to do this. One is issue is IPv4 by itself, other concern is NAT. It is operationally hard to make a robust solution as all NAT implementations are different. That may make it hard to focus.

Pekka Nikander:

There are two approaches to the NAT problem. One is to base the solution on existing mechanisms, meaning UDP encapsulation. The other is to enhance NATs, i.e., to teach NATs to understand HIP. The current thinking is in the favour of the latter.

Keith Moore:

This is bottom-up architecture. That's the wrong way to do architecture. We need top-down architecture before we deploy widely. The search mechanism (Charter item 7) isn't optional, it's critical. I would make it number 1 on the list. Need to look at wide range of interactions, for example, MTU changes when we move from v4 to v6. Probably need to do base spec last, including what we've learned from working on other specs.

Pekka Nikander:

The current plan is to complete the base spec first, then get operational experience, and then revise the base spec if needed.

Perry Metzger:

SSH was widely deployed before coming to IETF - the IETF value-add was SSHv2. The protocol originally had some serious flaws. HIP could be the same way. It is important for HIP to be brought to the IETF. It needs the exposure to a wide number of people so that it gains from the exposure and the protocol is improved. We need to give the WG a chance to come up with HIPv2.

Bob Hinden:

A WG for Experimental docs just seems wrong, wrt. IESG overload. The deliverables look like charter items for standards-track documents - no cycles included. I would like to see something that shows what is the result of the experiment.

Eric Fleishman:

We need to add the v4/v6 transition mechanisms to charter list. In general, the IETF doesn't do architecture well and architecutral work is less appreciated. This is architecture, but other people are starting to solve the same problem in piecemeal fashion - even worse than us! I value HIP as giving the IETF a possibly more architecturally complete solution than the more piecemal approaches elsewhere. HIP is giving the to IETF a possibility to consider a broader architectural solution.

Melinda Shore:

The concept of exploratory WGs is under discussion (Ted Hardie draft, etc). This would fit in there. NAT traversal is actually several problems that have never been decomposed appropriately at IETF, and name spaces is only one of them. Expect problems with directory, reachability, etc. Making NAT HIP aware do not solve these problems.

Harald Alvestrand:

If the IESG is massively overworked, then chartering or not chartering HIP is not going to change that. HIP by itself won't break the IESG's back. Decide if running this experiment is in the best interest of the Internet (in my opinion it is). If so, we'll need to figure out how to make it happen.

Spencer Dawkins:

APPS view of HIP is needed soon, to avoid late suprises. We want to have the applications guideline in the charter.

Gabriel Montenegro:

I would like to speak in favour of the WG, but the charter obviously needs some more hacking. Items 6 & 7 (rendezvous and proxy servers & search mechanism) need more work and may be better done in research. Personally, I would not worry about modifying NAT boxes but just assume they are there and workaround them. My advice is to also create an IRTF research group to have a look at some of the issues. At the working group side, should also be a document as a guidline of how to join the experiment.

Erik Nordmark:

Should IKE interactions be considered?

Pekka Nikander:

I am not sure. We have the MOBIKE BoF later, and it addresses some (but not all) of the issues from the IKE point of view.

Erik Nordmark:

But what if you use ESP, use HIP to rehome your packets, and simultaneously want to use IKE instead of HIP to create the security associations?

David Ward:

If this becomes a working group, we apparently need to address this issue.

Eliot Lear:

The NSRG research group at the IRTF didn't get far in this space. Perhaps the charter should be expanded to include MAST, NOID, etc? It also seems like some charter items aren't independent work items - they are different aspects of the problem, and must not be dealt serially. This concerns especially multi-addressing, DNS, rendezvous, and DHT issues.

Tony Hain:

Ignore NAT traversal unless you're doing IPv6. Look at infrastructure problems - that's the hard part - DNS, proxies, rendezvouz servers, etc. They are what needs experimentation. Lots of work fails because of infrastructure issues.

Tom Petch:

To the naive, it looks like the DNS is the crux of the problem. DNS is right answer but is perceived as useless to solve this problem. We need to bite this bullet now.

Steve Kent:

You need to do a list of problems right up front. Work item number zero should be a list of problems you are tackling. An experiment is used to verify or disprove a hypothesis. Are you doing experiments or testing?

Margaret Wasserman:

The current identity/locator overlap is a property of IP addresses, not inherently evil. We need a scalable way of life after the split. Don't throw all the experiments in a room and expect them to work things out. Apparently we will eventually need something like the DHTs to be able to look up identifiers.

Erik Nordmark:

There are overlapping conversations, and we need them. It is good to have these guys in one room.

Spencer Dawkins:

Yes, but don't put them all in THIS room - HIP is focused and already underway.

Margaret Wasserman:

We're trying to build a taller tower. We don't do that by putting everything in one tower and hoping it fits and turns out to be taller. In other words, we should not be put everything in the same room and expect to get a good outcome.

Thomas Narten:

Why a working group now?

Pekka Nikander:

We have been working on the base protocol for last two years. It would now really benefit from a wider review. Additionally, we need to focus on the infrastructure requirements, and we don't have that expertise in the current HIP community. Creating a working group is one way to get a wider review and invite people with wider experience to take part.

David Ward:

We have reached the point where the initial work has uncovered some interesting problems and potential paths. We need to finalize the specs we are working ong, and build interoperable solutions.

Pekka Nikander:

We need a widely implemented experimentation to get operational experience.

Thomas Narten:

HIP requires upgrades at both ends of an association. Is this deployable? Is it deployable from the experimental work point of view? How about longer term look, as a wider solution? We need to consider these at the working group, if one is formed.

David Ward:

There is no need for a Internet flag day for HIP, of course.

Thomas Narten:

Can you prioritize charter items?

John Loughney:

Everything beyond base spec is moving beyond experiment. Need a crisp charter for experiments. NAT traversal, for example, not needed for experiments.

Pekka Nikander:

Yes, we need to prioritize, but the base spec is not quite enough.

John Loughney:

Ok, "Core set of what's needed" may be more than the base spec alone.

Thomas Narten:

The suggestion of "DNS interaction" too vague. Speaking about using HIP to dynamically update DNS, we need to check with the DNS WG.

Spencer Dawkins:

Items needing wider community review can be mentioned in the charter without being chartered deliverables at this time.

Tim Shepard:

What would be the minimal set of useful things to do. Probably the first three proposed items, plus a report on what the experiments taught us. Wait a year to add more deliverables.

Keith Moore:

How can "minimal set" not be already done, if you have interoperating implementations now? I am concernted that if you exclude important isssues, you need to work on all aspects together.

Bill Sommerfeld:

Is this technology incrementally deployable? If not, what changes does it need? You can't boil the ocean.

Margaret Wasserman:

But IPv6 isn't incrementally deployable, either. Before we can have a question of incremental deployability, we need to decide what what we are talking about.

(The discussion came to end.)

Summary and next steps

The chairs posed the questions given in the top of this document, in the Decisions section. There was some clarifying discussion during the questions.

Clarifications for "HIP and routing"

Thomas Narten:

What do you mean with routing?

Margaret Wasserman:

I asked the chairs to ask these questions, so that we get some cross area expertise.

Clarifications for the question about enough of information

Randy Bush:

I am trying to understand how this relates to the work out of multi6. I am not sure I understand the space yet, and what we can achieve here with a separate working group, and whether it would be useful?

(?):

The deployment piece that needs work is the secure updating of the infrastructure.

Keith Moore:

I think that it is unfortunate that the applications people are not here. They are the people who need broader view to finalise the charter.

Margaret Wasserman:

All WG proposals get sent out for two weeks anyway.

Clarifications for the question about forming a working group

Randy Bush:

How this relates to NOID.

Margaret Wasserman:

We need to identify willingness to work here.

David Ward:

We have managed to bash the charter so much that we need to have a charter discussion at the list anyway.

Tony Hain:

My concern is that some of the key pieces of the problem (infrastructure) have no volunteers.