HIPRG meeting minutes for IETF 72 Monday July 28, 2008, Afternoon Session I 1300-1500 Meeting chaired by Andrei Gurtov. Minutes reconstructed from session audio by Tom Henderson. 1) Progress since last meeting: - new update for HIP Experiment Report published: draft-irtf-hip-experiment-04.txt - mailing list had discussion about middlebox authentication draft - progress on HIP certificates draft and discussion on moving to HIP working group - several new and revised drafts in both the WG and the RG - new HIP book published 2) Samu Varjonen. Update on HIP certificates draft. - draft-varjonen-hip-cert-01 - overview of the draft, changes from version -00, and open issues Discussion: No questions at the microphone. 3) Tobias Heer. Update on middlebox authentication draft. - draft-heer-hip-midauth-01.txt - extensions to allow middleboxes to authenticate hosts - allow middleboxes to add parameters to HIP signaling, and add Host ID parameter to the UPDATE - Open issue (raised on the mailing list): the authentication on the base exchange is stronger than on the data channel (where there is no packet-level authentication) - question for the RG: is this useful work item for the RG? Discussion: Andrei G.: Have you addressed all comments and questions that were posted on the list? Tobias: Some comments from Samu not yet addressed, but Julien's comments were addressed in a security section 4) Bob Moskowitz. HIP experimentation using Teredo. - motivation is to look at HIP from a perspective of total commitment to IPv6; gaming community may be driver of this - Teredo-based approach to HIP presented - mobility and Teredo signaling impose some costs on number of packets, and timing Discussion: Alan Johnston: RTP media, latency, will be key quality metric; will be interesting to see how it compares with ICE Bob: Yes, Teredo relays, and discovering your nearest relay, etc. will affect this. Am also working how might Teredo play into a company's v6 deployment plan. Yes, a lot of timings to consider... we'll see. Miika Komu: Are there MTU issues with Teredo? Bob: Teredo has MTU of 1280, what is impact on RTP? I don't think any. May cause a few more SIP packet exchanges. 5) Pascal Urien. HIP-based RFID Networking Architecture - draft-urien-hip-tag-00.txt - use of HIP for active tags - modified version of HIP for active tags; tags never expose their identity - tag portal can solve equation to learn identity - new attribute, F-transform (details in the draft) - plan to implement by end of this year/beginning of next year Discussion: Andrei G.: Is this similar to object to object draft later? Pascal: No, completely different. Privacy issues are dealt with differently. In our approach, tag does not return its identity, but instead it returns a function which may be used to recover its identity. Main goal of HIP exchange is to hide the identity of the tag. Andrei G.: HAT in the picture, is it NAT? Pascal: May be a new protocol at the tag level, or maybe new modified version of HIP. For experiment, we expect to do whatever translation is needed to transport it from the reader to the portal. (person did not state name): What are you identifying? Just the tag, or any other object associated with it? Why do we need this binding relationship? All mobile phones have their own smartcard. Pascal: The first thing is to know who you are. Not like done in wifi, mobile phone, today; you do not give your identity to the whole world (protect your identity). Once I know who you are, HIP allows you to open ESP channel to get data to/from this device. Emphasis is on identity privacy. 6) Xiaohu XU. Hierarchical Routing Architecture - draft-xu-rrg-hra-00 - overview of a framework in which the HIT is split into an organizational part and a hash part, and the organizational part is hierarchical and managed. - routing architecture allows multiple locator domains - hierarchical mapping system/DHT and a two level routing system Discussion: No questions at the microphone. 7) Gyu Lee. HIP Extensions for Object to Object Communications - draft-lee-hip-object-00.txt - main point: the concept of "host" should be extended to support all objects, including tags, sensors, etc. - objectives for protocol development: protection of object, connection to anything using object identification, and service and location discovery - proposes introduction of Object Identity and Object Identity Tag (OIT) Discussion: Miika Komu: Would be nice to have a few use cases in the draft; other points will be raised on the list; seems interesting. Andrei Gurtov: Would be nice to mail something to start discussion on the mailing list. (did not catch the name): I suppose there will be mapping in DNS; do you have idea of resource record to add? What about object identification? Are you going to use RFID or some uniform object identification in this framework? Gyu Lee: Don't have an idea, but maybe DNS should help us. Gyu Lee: Most of our identifiers are different, but there is some trend in defining a common identifier to accommodate all of the identities. 8) Closing microphone discussions Paul Thierry? (not sure of name): How do you see namespace for this being managed? Ad hoc, or ISPs, or some combination of the two? Who manages the host identifiers? Are they generated by hosts or do ISPs play a role? Andrei: Self generated, but can insert into DNS if you want. ORCHIDs reserve some IPv6 address space, but no other assignment is plan. Bob: Design was that HITs are totally unroutable; big discussion in NSRG in the past, and the initial draft had a form of HITs that had a prefix that was managed. Lookups (directory entries) return both HITs and addresses for rendezvous servers. The issue was, if we have a problem that needs traceback, the reverse lookup was the issue that Randy Bush was very adamant about (no reverse lookup methodology). There's no good answer for that. Tim Shepard: This question keeps coming up over and over again with HIP. A recurring perception problem that HIP has with the wider IETF audience. My reaction is, if you have an ssh host key, how do you look up that? No one seems bothered by that, though. Bob: This is a function that the rendezvous server is supposed to provide, or the DNS extensions. Miika: We are looking into how much impact to not have the reverse lookup working-- hope for experimental results in half a year or so. Has been suggested that some organization might manage the ORCHID prefix, or OpenDHT (which lately doesn't work so well). Legacy applications draft says that HIP software should log all of the mappings so at least the administrator could do the traceback.