Host Identity Protocol Related Research BOF (hiprr)

Decisions

1. Should we continue to work on full blown non-HIP supporting proxies?

   Yes. Transition mechanisms are an important issue.

2. Should we continue to work on NAT traversal?

   Yes, but unclear how. Pressure to work both on solutions that are friendly to current NAT boxes and on solutions that make NAT boxes friendly to HIP.

3. Should we continue to work on the Lightweight HIP idea?

   Yes (large interest).

4. Should we continue to work on CELP?

   Yes (some interest).

5. Should we continue to work on DHT / HIP overlay / ... ideas?

   Yes, but unclear where to focus.

6. Any additional important areas that we missed?

   Applications point of view.

Summary of discussions

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

Points to pay attention to

Presentations and Discussion

Research Group background and Status

Slides

As a continuation of the successful HIP BOF in Minneapolis and the WG chartering discussions that followed, there is a clear need for a research group that will study the consiquences of HIP or the ID/LOC split in general. However, ID / locator split major architectural issue and the IAB wants to investigate it before making a decision. There is hope that the discussion will be finished shortly, i.e., during the week In any case, there will be space for HIP research group.

Dave Crocker:

What is going on this week about the id/loc split? The plenary is often not good for resolving issues.

Vern Paxson:

The IAB discussion will take place before the plenary, and results will then be presented there. The plenary is then a place to see what the community things.

HIP related research elsewhere

Slides

Pekka briefly discribed related research elswhere, including the NewArch, Ambient Networks and Daidalos projects.

Vern Paxson and others:

The NewArch project is done.

Pekka Nikander:

Ok, but I see the work continuing. We have to follow what's going on.

Kevin Fall:

There has been lots of work on interoperability over networks that are not Internet networks. Separation is related to routing, there is SIGCOMM 2003 paper discussing the area. The delay tolerant networking folks have been thinking about ID/Loc and have been doing IRTF stuff. See www.dtnrg.org. [The SIGCOMM paper that Kevin mentioned is available through the DTN RG web pages.]

HIP proxy / rendezvous broker

Slides

Lars Eggert gave a presentation related to draft-eggert-hip-rendezvous-00.txt.

[The comments in the following discussion transcription have been slightly reordered so that related comments are collected together.]

Erik Nordmark (clarifying question):

Why does a rendezvous server need to NAT, why not tunnel?

Lars Eggert:

NAT is what the current architectura draft states. Actually I will propose tunneling a couple of slides later.

Greg Daley:

To me this looks like Mobile IP or like a VPN tunnel server endpoint. You have a static address, like in MIP, which acts as the identifier. Would it be worth comparing?

Lars Eggert:

The difference really is that this kind of a relay is needed only if the other party does not understand HIP.

Greg Daley:

It's the same thing with MIP. What is an advantage for HIP?

Elliot Lear:

Could you comment differences with mipv6?

Lars Eggert:

For the HIP-HIP case, a rendezvous can be anywhere, you don't need to have a fixed home network.

James Kempf:

If you renumber the home network, your identity changes in Mobile, IP but not in HIP.

Pekka Nikander:

The proposal it is very similar to MIP for non-HIP nodes. On the other hand, if we consider only HIP hosts, there are no restrictions on where you put your rendezvous server, and you can have multiple rendezvous servers, even dynamically.

Joe Touch:

Are you changing the DNS or modifying the entries? So the reverse lookups will be ambiguous anyway and lot of protocols will start failing?

Lars Eggert:

There will be additional changes.

Rob Austein (clarification):

You do not actually need to resign the entire zone if a single record is updated via DynDNS. You can do incremental signing.

Miika Komu:

We should concentrate more on the HIP-to-HIP rendezvous server case. If the peer does not understand HIP, we fall back to IP.

Lars Eggert:

If the IP address in the DNS is the IP address of a randezvous server, such fallback would not work.

Pekka Nikander:

We can't put the rendezvous server address in the DNS. The WG must rethink this. The WG is supposed to do the I1/UPDATE only rendezvous server, plus the rendezvous server DNS record.

Kevin Fall:

The terminlogy used here seems to relate to I3 work. Any comments?

Pekka Nikander:

Distributed Hash Tables will come up in later presentations.

Pekka Nikander (chairing):

Is this a topic that should be studied in the RG? Or should we leave this for the WG?

Juergen Quitteck:

This should be a work issue, because it is important to communicate hip and non hip nodes.

Pekka Nikander (chairing):

There seems to be some interest. I don't see any reason why we can't work on this.

NAT problem statement

Slides

Juergen Quitteck gave a presentation related to draft-stiemerling-hip-nat-00.txt.

Joe Touch:

Most of the reasons why you say NAT is bad is that NAT makes everything behind the network look like one host and this is what you don't want. Most justifications for NAT are reasons for its brokenness. Stop supporting them.

JQ:

NAT is what the users do, you cannot stop them.

PN:

If you do a loc/id split, NAT may become less evil, since you obtain stable id end-to-end. Even if the locators are changed on the fly, the id is still stable.

JQ:

This is not advertising nat, but to address the problems that NAT pose to HIP. The point is to make HIP and NAT coexist.

PN (clarification):

There are no problems with HIP and checksums in NAT traversal, since in HIP the pseudo header contains HITs, not IP addresses.

PN (comment):

I'd like to mention a couple of problems with mobility and multihoming. If a mobile host goes to a network behind a NAT, it already has an association. The NAT has to find out from the UPDATE packet the new address. The SPI values is also problem: there may be collisions. Should the SPIs be within or outside of the signature calculation? DoS does not seem to be a problem.

JQ:

The conflict with using same SPI can be solved with NATs that have more than one IP address available.

Greg Daley:

99% of NATs are unmanaged, so what if they don't support the hip? Stay in TCP or UDP so you don't rely on NAT upgrades?

Tim Shepard:

I agree. We won't get NATs upgraded. HIP could be use to get IPv6 for home node behind a NAT. Maybe even in such a way that v6 is never seen in core network, i.e., use 6to4. We can't upgrade NAts, but we can ask vendors to support 6to4. This seems like the right thing.

Greg Labovitz:

We are a NAT implementer and we don't have problem changing NATs.

Dave Crocker:

It is easy to get one person to do one thing, the problem is to get everybody to do it?

Why did I stand up? Well, NATs are not a problem in the net, they are a problem in the IETF. There are HIP things and then there are other things that HIP must cope with. NAT is not core business for HIP.

There are couple of ways to deal with things. If we wait for NAT boxes to change, we have to wait for a long long time. If we don't wait, we have to manage difficult things. Thus, there are multiple ways to solve problems. Short term hacks will probably be long term (wrong way). Hence, make the ugly thing and the right thing coexist.

Pekka:

I'm not worried about NATs. If HIP happens there will be an incentive for NAT vendors to support HIP and for users to upgrade. The boxes are cheap and get cheaper.

We have to make a distinction between two different things:

1. compatibility with current NATs,
2. HIP allows cross IP realm traversal, which we probably should not even call NAT

You could have multiple IP address realms and let traffic flow between them, while retaining the 3.5 layer end-to-end connectivity. We have tried to design the system to make things to work with 3.5 routing. The state in the layer 3.5 routers must be a soft state.

Elliot Lear:

HIP solutions should be long term and problems solve in the long term ones.

Gonzalo Camarillo:

You will never deploy HIP if you need to update NATs. It is the same problem in SIP. Don't require modifying NAT.

Erik Nordmark:

Should we match HIP and NAT or decouple them the more possible?

LQ:

The question is whether we want to make HIP more NAT friendly or NATs more HIP friendly.

Lightweight HIP

Slides

Pekka presented an idea. No questions or comments, but considerable interest on working on the idea.

CELP

Slides

Dave Croker gave a presentation related to draft-crocker-celp-00.txt.

Pekka (comment):

If we do id/locator split, we get into situation where we have two sets of different congestion control variables. Some are related to the path and some to the flow.

Dave:

I agree with you. The id-locator combination is both on the layer 3 and 4. This was not point of this discussion; a different discussion. If we solve this cleanly, it is good.

Presentation continues with security issues.

Pekka:

Security issues were touched already today. If you do RR test using IKEv2 or MIPv6, there results are different from the security point of view. A solution to this may be to add a a security related granularity parameter.

Dave:

We need to figure out the minimum level of security. I propose naming the IP address pools with domain names, but this is handwaving that requires work. One of the problems is that the DNS name -> IP address -> DNS name chain may not work. There seems to be problems with operation and administration.

Erik Nordmark:

I'm wondering about issues with a shared pool and multiple users. What is the key for looking up from the pool? What if we have two users, (two connections), and they give a different key to retrieve the address from the pool? Or if the users are attaching different informations to the same key?

Dave:

I don't have an answer, needs more investigation. Multi-address parallel usage would be great.

Pekka:

I have an example. Consider using HIP and SCTP. HIP gets more addresses to the pool (rendezvous servers) than SCTP.

Elliot Lear:

On the use of the domain names. Firstly, there must be no circular dependencies. Secondly, I was asked to write a draft for the multi6 WG, things to think about. There are couple of points that are interesting.

Presentation continues.

Dave (question):

Is this interesting? [A few few hands.]

Pekka:

I have a gut feeling: DNS names are not going to work. You dont put DNS names into the kernel. Looks complicated. My personal feeling that it is a bad idea.

Dave:

Your comments were mild compared to others. Interesting discussion.

Andrew McGregor:

How to you manage the address pool in the DNS server?? DNS names are pronote to a dispute.

Tim Shepard:

Needs cooperation from DNS admins. This is a showstopper. It is hard to work on a protocol and deploy it if I can't use it on a network until I get cooperation form the administrator of the DNS.

Dave Crocker:

From the CELP point of view, DNS provides two different services: lookup service and naming service. We are not necessarily doing lookups.

Erik Nordmark:

Locator pools apply, even if you introduce new name space.

Dave Crocker:

We need an identifier space for pools. We need some commonality between the users of the pool, in order for this to be useful.

Kevin Fall:

Why not use URI space instead of FQDN?

X:

You said: there should be a DB and a key. Key seems to be DNS names.

Dave Crocker:

We need to add a few details before it is practical.

Kevin Fall:

The CELP acronym is already taken.

Referrals problem statement

Slides

Pekka Nikander gave a presentation where he tried to clearly state the referral problem but actually talked more about Distributed Hash Tables (DHTs). He really should not give that many presentations during a single RG meeting. [A note to those whose sense of irony is limited: remember who has compiled these minutes.]

Joe Touch:

I have a little confusion here, why don't we want to use the DNS?

PN:

The HI / HIT name space is flat. You can't use DNS, as DNS requires hierarchy.

JT:

Well, then, make the name space hiearchical.

PN:

Earlier version of the HIP drafts contained an hierarchical name space as an alternative. It was removed for the sake of simplicity and some other problems. The HIP WG can certainly add it back if they want to. In the Research Group side, though, I think that we want to explore the other possibilities.

XX (from Deutche Telecom?):

The carriers may not want to use DHTs because of the amount of traffic generated.

PN:

There may be a misunderstanding here. The way I envision that we might use DHTs is not really P2P like, or at least not Napster like P2P. It does not generate any more traffic than DNS.

Rob Austein:

A problme with a DHT is the trust model. In the DNS you have somone in control of which servers you trust, and that is not possible in the DHT case.

Pekka Nikander:

In DHT you can use several hash keys and several independent servers.

Rob Austein:

So you must trust several strangers insteas of just one.

PN:

The assumption is that you have a strong id check, so you just need enough replicas to find at least one set of valid data, i.e., one where the signature is valid. Remember, if we use DHT with HIP, we have a public key and the strong relation with HIT. The real problem is whether you get data back or not. To solve this, you can make ten replicas or so. This is not a perfect solution, there may be better ones, but is a solution.

But yes, we have two problems: collusion (as I mention in the slide) and replay of old data. The latter can be solved by always making more than one lookups, but that is bad from a performance point of view.

PN:

So, basically, what I am saying is that we know how to make DHTs work in theory but not how in practice.

Erik Nordmark:

Practical issues of how well it scales? In a large network we have many hosts joining and leaving? We would have a million or more servers. This is different if all internet uses this than the current DNS use or current DHT research use.

Kevin Fall:

All this discussion relates to the new layer. Maybe i disagree on the issues on the agenda?

Pekka Nikander:

We need a mechanism to get IP addresses from identifiers. We try to get attention from academic research.

Kevin Fall:

This is distraction to the reseach group. There are other communities that are solving these problems. We should focus on the problems that others are not solving.

Pekka Nikander:

how about Erik's comments?

Kevin Fall:

Research is going on but you have a different problem, yes.

Thomas Henderson:

Any fresh ideas?

Using any servers as rendezvous points

Slides

Tim Shepard described his idea of using any servers as rendezvous servers.

Tim Shepard:

About HIP rendezvous issues. I'd like to have a system that doesn't use DNS at all, where end points recognize each other without using dns. You just introduce each other once and then they know each other. Server mobility is easy because the server remains fixes simultaneous movement: only one of the moving host has to maintain a association with the rvs could all hip nodes act as relays?

Elliot Lear:

That was a great bar conversation. Really good questions. May I disagree: it is ok to use DNS, its ok to fail if the resouce is not present. First question: In simultaneous movement, what is the tolerable period to have stale info? Second question: In moving from one location to another, how do you introduce the routing system, leave info in everywhere you go?

James Kempf:

Two nodes moving at the same time. You lose the update. When a node moves it tells the old router so that the traffic can flows to the new location. So we can come up with a local link fixed routing protocol (for HIP, MIP...)

For VoIP, the maximum is 40 ms dropout period. This figure also works for HIP. This work has not gone anywhere due to non-interest.

Tim Shepard:

This is this same as Eliot mentioned.

James Kempf:

Yes, approximately. Router and node has to find out the movement. 40 ms is allowed, due to voip apps.

Tim Shepard:

May be. However, my basic observation is that if you have implemented HIP, you are only few lines [of code] away from a [I1-only] rendezvous server.

Erik Nordmark:

If every node acts as a relay wouldn't this enable new attacks, is it worse tat than ipv4 today? Consider open SMTP relays today. Here you have strong identity. You have to tell where they are coming from to get them shut up if needed. You can hide your IP address. If you have IP address, you can tell the ISP that this guy must be "closed".

Kevin Fall:

This looks awfully lot like i3. Refrasing, is is better to have an infra with storage capability, or is it better to be more active.

Pekka Nikander:

This is one very good question. This is the third independent time that I hear I3 and HIP in same sentence. I am starting to wonder why

X:

HIP identifiers like ethernet addresses from the forwarding point of view. You use the identifier only on the last part. Not so vulnerable.

Tim Shepard:

I dont really understand the question. HIP ids can be proved to be owned.

X:

Different thing. It is just equivalent to that point.

Tim Shepard:

Are you saying that we should take only part of the HIT as the id. Possiblity of collisions gets greater. I don't know how to solve that.

Open mike

Pekka Nikander:

People are working on the DHT problems elsewhere so we don't have to take so much effort on those things. Concentrate on understanding how HIP effects on the Internet.

Steve Kempf:

What's impact on applications? Nothing concrete on application layer referrals so far. That is important.

Erik Nordmark:

Another thing, how IDs show up at the application layer. Does this change applications? Does this change the way to use applications?

Pekka Nikander:

One of the questions is that we have an aulli mailing list, basically dead at the moment. Which is the right forum to look at application area? Apps is not a HIP tradition, so lets get some clue to look at it.

Maybe we should have a sub research group for application issues? I don't know how to organize this kind of thing.

Erik Nordmark:

Are there people in the room that understand application level identifiers? [No hands]

XX:

This is a difficult question.

Joe Touch:

I can take applications that use ip addressses in different ways. They will suffer from using HITs. Who understands apps use of addresses? Many bizzarre things out there. Is non-hip host talking to non-hip app on hip enabled device a problem?

Erik Nordmark:

No idea, but does existence of HIP namespace change things in interesting ways? What other kinds of IDs do applications use?

XX:

There is also a body existing work related to these things. There are surveys about these issues. Have been surveys of app protocol use of IP addresses.

Keving Fall:

Are these right things? Semantics, routing system, what layer routing system it relates to, hierarchical. Lot of things to cope with.

Elliot Lear:

NSRG draft looks at some of this. Remember also the draft mentioned earlier with the open questions.

Pekka Nikander:

There are some answers in HIP architecture draft. Maybe they are not sufficient. The draft was in the RFC Editor queue, but it is now back for editing. Please review the architectural draft, needs to be stable as soon as possible.

Pekka Nikander (chairing):

No more comments? Looks like a lot of the right questions are being addressed. The apps level identifiers stuff needs to thought in more detail. We need help from the apps people. More drafts, please!