2.5.2 Host Identity Protocol (HIPRG)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Current Meeting Report

Host Identity Protocol RG minutes by Jeff Ahrenholz

FRIDAY, August 5 at 0900-1130
Room 341

CHAIRS: Andrei Gurtov (gurtov@cs.helsinki.fi)
Tom Henderson (thomas.r.henderson@boeing.com)
(Tom is not attending this time)

1. Agenda, attendance sheets, note-taker, jabber scribe
5 min
Welcome by Andrei. Pink sheets.

2. HIP experiment report (Andrei Gurtov)
10 min
update on the HIP exp report.
Tom and I have submitted the update.
objective; __ out of scope of this RG
not too much content yet
mostly pointers to literature, document needs a lot of work
list of names requested by IRTF - showing that there is sufficient interest and progress
sections which do not have any text
need more practical experiments with HIP
need non-trivial deployments >100 nodes or so
for example an agreement with people in China to put HIP in many hosts, but need a stable implementation that is easy to install. once WG completes documents, hopefully that will help with that
Telecom Italia has an important contribution that will be added to this report

3. HIP-OpenDHT Interface (Jeff Ahrenholz)
draft-boeing-hiprg-opendht-00.txt (sic)
15 min
Eggert: comment about caching - may not want to cache the values once we get fast lookup services

move to item 6 since Pekka is not present

4. Using HIP with Legacy Applications (Pekka Nikander)
10 min
using HIP with legacy applications
mostly Tom's work
personal view -- we need to converge on this
deemed outside of scope of the WG
implementation experience on many of these areas

Gurtov: kind of an LSI used by OCALA proxy something
would like to get response from RG - what are we missing?
personal feeling: exp report is a couple of years away, maybe this belongs separate draft
background slides explained by Pekka

Eggert: basically it's a NAT inside the box; what do you do on the incoming side? how do you decide which IP address to put in there ...
how do you predict which IP address to use for the receiver? Defeats the multihoming and mobility?
Ahrenholz: we use IP address from ESP input, locators used on the wire; checksum is rewritten based on HITs
McGregor: you could configure the services to listen on localhosts
Nikander: this is how Ericsson does it...
Gurtov: have you considered reverse mapping from IP and HIT?
*** Please check with Tom about reverse mapping in the draft. ***
Nikander: The biggest longer term problem, if different implementations use different methods, then we will have problems with referrals, and not full interoperability. Premature to make a decision at this point in time.
Gurtov: how about an appendix describing what legacy applications don't work?
Nikander: webpage would be appropriate for that. it changes, you need to know versions of app, HIP, OS, etc. Most applications are supposed to work
Need more reviews. Please read it. If you do read it send comments, send comments that even say "I've read it and have no comments."
Eggert: so I haven't read it. are we ready to recommend certain ways for applications
Nikander: I have my opinion and Tom has his.
Unknown: idea is to go informational? yes.

5. Migrating HIP application in the Internet using Xen (Pekka Nikander)
Ongoing work with T. Koponen and A. Gurtov
15 min
He was supposed to send slides but didn't. Basically I made one a couple of minutes ago. Point of Xen is that you can migrate those virtual machines from one to the other. Replaced IP level handover with HIP. Not transferring HIT/public keys. the VM have different HITs, we are doing delegation. One box creates a delegation certificate that says from now on this box represents me. full proxy of the initial HIT.
Gurtov: since HIT doesn't have a binding, we should stop calling it HIT?
Nikander: it's still a host identifier, but for the instance of the virtual host
work on next layer: how do you use public keys for sessions or applications.
status: it works. we are thinking of clever tricks so you can have virtual handover times of 0.
McGregor: why not just allow the keys to move?
Nikander: you can do that. but part of me is a security geek, even though security people may not acknowledge that. From that point of view, it's not such a good idea to move your keys around. In my personal opinion, from security architecture this is what you want to do.
McGregor: relates to previous presentation, using an opaque LSI that is not bound to the HIT
Nikander: <explanation>
McGregor: interesting alternative to simply allowing keys to move. In most cases, I think you would probably allow the keys to move anyway (using local Ethernet) but halfway across the Internet this is a better way.

6. NAT problem statement (Martin Stiemerling)
10 min
been through quite a few revisions
problem statement - want is not going to work if you want to run the currently specified drafts
now a pure problem statement
URL of old document is pretty stable at this point
what to do with this document - is that fine with you?
hum to adopt as a research group item
(no hums against)

7. Traversal of HIP aware NATs and Firewalls (Hannes Tschofenig)
10 min
Hannes actually had to run away to current NSIS WG meeting. He left me the slides which I haven't seen yet, so I am going to show them on his behalf.
Lars has presented draft - problem statement for legacy NAT traversal, this is the case for middleboxes designed with HIP in mind.
Originally included a lot of specific proposal, has been moved to the appendix, maybe could be removed altogether.
How many have read? A couple. We need more people to read and post comments to the mailing list.
Any comments on the draft?
Eggert: my only comment is that I don't see why this is an issue right now, are people going to build HIP aware NAT/firewalls right now?
McGregor: I am intending to do some firewall work.
Gurtov: we have implemented HIP-aware firewall, good to see how well it follows this draft, maybe not very well because they evolved concurrently (thesis will be available soon)

8. Using SRTP transport format with HIP (Hannes Tschofenig)
15 min
First draft was a generic discussion between HIP and SIP.
The idea is to use HIP associations as a platform for SIP.
Eggert: channel binding again. if you don't know ___. specific example of generic problem.
Camarillo: we are using so called K field in the draft. It has a set of problems. Maybe we will use a new mechanism, we need to do more research here
secure STRP problem, is that wireless devices do not want to use IPsec, you want to use header compression. SRTP over IPsec, not how ESP should be applied
In my opinion, these are two open issues in the draft.
Gurtov: question ???
Camarillo: last document in the SIP working group was approved. There is no deployment experience.
controversial HIP does not go through middleboxes
please send comments to mailing list

9. Privacy extentions (Alfredo Matos)
15 min
We focused on location privacy since it is a growing requirement
for example, last Tuesday, they are focusing on the problem
current arch provides no privacy at all
fairly easy to track a node's position through the network
no location privacy is provided w with HIP
good thing is it decouples the locator and the identifier
example topology.
we introduce 3 elements, 2 new -
extend RVS concept.
identity of HIP mobile node translates to RVA identity. RVA assigns global IP to each mobile node.
size of RVA determines amount of geographical information revealed.
focus on network mobility, which is difficult with the additional level of hierarchy
how to do signaling delegation - since CERT is no longer in the draft

Questions: is this an interesting topic for HIPRG? In/Out of scope? are there additional proposals for more in-scope items?

Vogt: yes, it definitely makes sense. in MIP there is hierarchical MIP and it works very similar to this, so it seems to be a good approach. question, do we use current mobility approach?
yes ... so you get CBA also.
<discussion on what mechanisms they are doing>
whether you use existing hip-mm to register IPs with RVA? yes.

Mathis: stunned by the power of this -- brings something to the net, I think this is very important. This underscores some of Steve Bellovinís comments last night (plenary). If locators tell you nothing about who people are, how do you know if your mappings are correct. Imagine having good ...

Gurtov: prototype?
we are looking at it, we make no promises

Gurtov: Yes, is a very interesting item for the RG

10. Implementation status of BEET and PATH (Andrei Gurtov)
10 min
BEET - mostly done by Diego from HIIT.
BSD was easy - done in three days. hard because XFRM has little documentation.
support for auth header
Ahrenholz: comment on using tunnel mode -- you really want to bind the SA to the inner address, not the outer address, to implement BEET; otherwise you have problems with mobility.

PATH draft
optimistic case -- NAT traversal for HIP in early September.
PATH draft has not been recently updated; PATH does not have enough details...
Eggert: update the draft or write a new one whatever is quicker
*** Need discussion on mailing list about this. ***

11. Hi3 implementation and experimental results (Andrei Gurtov)
10 min
This infrastructure could be used to bootstrap HIP experimentation
Eggert: do you have an idea why traffic fluctuates a lot, while IP traffic does not?
Gurtov: why is IP getting less throughput that HIP traffic occasionally?

12. Hi3 scalability analysis (Dmitry Korzun)
15 min
use distributed rendezvous server - i3
using some theory to look at what should happen, cannot do experiment with millions of nodes
Main result: latency is a result of these two factors: size of infrastructure and node to node forwarding cost. O(logN) results

Zhang: question - where you use hi3, are you using it in the control plane or the data plane? how can it work through middleboxes
Zhang: there are always some tradeoffs. example: if you only do mapping at first time you send data, it may be hard to support mobility. Like DNS today, you may have to use caching, how do you know about such movement? Iím afraid of limitations in performance with Hi3. What about a router which has simple forwarding mechanism - I don't see how you can achieve this goal with Hi3... they will find it hard to implement in actual hardware routers 10G or 40G etc
Gurtov: not quite there yet, with anyone thinking about
Dmitry: we use only for control plane, double jump problem, not for the data plane. The double jump problem performs quite well -- better than MIP
Zhang: there are always some tradeoffs. Supporting privacy and forwarding, you have to pay. Perhaps 90% user uses key functions -- must choose whether you will receive requirements from 10% of user, hard to choose.... we must be cautious in adding a new feature to a NAT -- we maybe can't use the model here.

Zhang: How can you mitigate DoS attack with Hi3 architecture? End users or servers?
Dmitry: we are working with this issue. we need some extra assumptions for this.
Need to estimate its origin using some assumptions about attacker. My estimates are too rough to make a statement.
Zhang: Hi3 not related to ___
Gurtov: if receiver notices lots of traffic, it can tell i3 to stop sending data
Zhang: what about for a public server that is accessible?
Gurtov: explains how i3 works w/private triggers
Zhang: <gives an example>
Gurtov: difficult problem to distinguish flash crowd traffic vs legitimate.
Zhang: even without i3, we can add a feature to the IP header to do DoS?
Zhang: people don't consider performance enough with i3 architecture. in my opinion it is quite hard to perform well. we must note that there are limitations with this technology.
Gurtov: to serve a reasonably large amount of nodes, current Hi3 arch will even support it. Pure i3 has much higher requirements due to forwarding control + data.

13. Native HIP API (Andrei Gurtov)
feedback summary - may need something more generic. OTOH, can't be too generic or you will never finish it.
Eggert: you need an API for the WG, but you need a clean API for the new stuff that the RG, it is not clear where it should be. Maybe it should be two drafts, i don't know.
Gurtov: perhaps one option is basic functionality to the WG, advanced to the RG
something to discuss w/Miika
*** Please send ideas to the list. ***
McGregor: some feedback for some app area meeting people. For a minimally-aware application, using new resolver functions is not a particularly good idea, better to add extra codepoints through getaddrinfo(), a better interface for adapting things.
Gurtov: legacy, HIP-aware, minimally aware HIP apps.
McGregor: relatively rare function is loading host ids, etc
Gurtov: can't implement HIP naming resolution. app happens to be pretty HIP aware
McGregor: take it to the list
This is not very compatible with opportunistic mode. No comment from Ericsson.
Might be able to be solved through new OCALA architecture

14. Open Discussion.
Any new ideas for the RG, etc?

Eggert: RG is supposed to throw over ideas to WG. What are some of the low-hanging apples that we can do here and throw over to the WG?
Gurtov: legacy NAT traversal... pretty trivial thing to do. Once finished w/base draft, that's a good thing to move there.
McGregor: privacy extensions are a good thing to move there. But first they should stay here for a little while.
Gurtov: what about BEET? hanging in MobIKE somewhere?
Eggert: any new feedback about BEET?
Gurtov: haven't heard anything too angry from them. People like Jari Arkko are fond of it. It may be useful in areas other than HIP.
McGregor: maybe we should just last call it

Eggert: hereís a crazy idea -- on opportunistic HIP. There is very little contained in the I1 packet. What if you put that into an IP option that you just send to the peer -- if you know it, read it? Otherwise ignore.
Lindquist: Nikander has suggested about using as TCP option, similar to I1, and we have been thinking about it in the InfraHIP option. Weíll likely make a draft and implementation in the near future.
Has many tough questions. TCP options field only has 14 bits, so it cannot fit there.
Gurtov: clarification please
Eggert: they want to put it in a TCP option, yes
TCP piggybacking
Gurtov: sounds a little cautious to me, what about SCP, UDP -- transport might not be best place
McGregor: point of putting it here -- you can if you want treat this as an opportunistic I1. It is possible to do an opportunistic exchange where neither end knows the HIT
Lindquist: one motivation is we could fall back, we just use TCP
Gurtov: I like the IP option more
Eggert: TCP people won't like TCP option. Will you write something down on this?
Lindquist: yes.

Gurtov: what about the DHT draft?
Ahrenholz: probably keep it in RG for now. Itís still too researchy, need more implementation experience and interop'ing with it.
McGregor: people need to play with it for a while see where the DHTs break. It will work to the extent that OpenDHT is... we don't kwow what deployability is, we may need to design a DHT from scratch. i.e., what if you want to use XMLRPC over HIP. That remains researchy yes.
Gurtov: probably need more time. We are working w/Sean Rea at UC Berkeley, improving latency
Eggert: I like it a lot, but it is something to experiment with, too specific.
The more general case is interesting: what are the tables, lookup steps
Gurtov: I think vice versa. Draft the specific implementation uses to WG, more generic to RG.

Do we like the Friday time slot?


HIP experiment report
HIP-OpenDHT Interface
Using HIP with Legacy Applications
Xen and HIP
NAT problem statement
Traversal of HIP aware NATs and Firewalls
Using SRTP transport format with HIP
Privacy extentions
Implementation status of BEET
Implementation status of PATH
Hi3 implementation and experimental results
Hi3 scalability analysis
Native HIP API