HIPRG met on 29 March 2011 at IETF 80 in Prague. Tom Henderson chaired the meeting; co-chair Andrei Gurtov was not able to attend. Roughly 30 people attended. 1) Tom Henderson reviewed RG document status. Two documents (HIP DHT Interface and HIP Experiment Report) are ready for IRSG review. Three other RG documents (RFID, Proxies, and HI Revocation) have been recently updated and will be discussed at the meeting. There were two new drafts and six updated drafts targeted towards the RG since the last meeting. 2) Gyu Myoung Lee presented some slides from Pascal Urien (who was unable to attend) on the RFID draft (draft-irtf-hip-rfid-02). The presentation focused on changes since the previous version. Tom Henderson: Review the diagram. The goal here is to disclose RFID to the portal, but reader can't know the RFID. Based on shared secret from portal and RFID, portal can extract EPC code. Proposal is to use HIP as a transport, using nonces and the shared secret, the portal can extract the EPC code. Robert Moskowitz: Have question about HEP (HIP Encapsulation Protocol). Would also be HIP in the reader to have HIP running between reader and protocol? Gyu: In case of HEP, this protocol has association between readers and portal, but authors mention no description for this issue. Not sure whether Pascal plans to put details in this document. Tom Henderson: Raised some issues on the list. Would like to request RG participants to please look at the issues on the mailing list. In particular, it is not using HITs according to the HIP architecture; they are ephemeral (random numbers) and all of the security is in the payload fields. Is this really HIP? Do HITs need to be more securely bound to the identifiers? One concern is that the RFID-enabled device desires privacy; is the BLIND architecture appropriate here? 3) Dacheng Zhang presented updates on the HIP Proxy draft (draft-irtf-hiprg-proxies-02). The main changes were to respond to Tom Henderson's comments on the previous version, and add some additional clarifications. Tom Henderson: Seems close to finishing up this draft during the next meeting cycle. 4) Dacheng Zhang also presented an update on the HI Revocation draft. There are still several issues to address. First issue: whether to introduce a long-lived name? Second: how the expiration date can be set, how to detect whether HI has been compromised. Not sure whether to integrate this all into this draft or write several. Third issue: how do hosts learn HIs from third parties? Will address this third issue in the next revision. Tom Henderson: Recommend to not try to handle everything in this draft, but limit the scope and write down in the introduction what the scope is and what is for further study. Broadly, this draft deals with two issues: 1) when you have multiple HIs that must be related to one another, and 2) when you have a compromised HI. Dacheng: Should we write another draft to cover this topic? Tom Henderson: Up to you; may not need a separate draft. Recommend to try to write it in the current draft. 5) Robert Moskowitz reviewed the so-called Diet HIP draft updates; Diet HIP (DEX) is a proposed new mode of HIP for devices with fewer compute resources. Robert mentioned the need to align with RFC 5201-bis, and to review the key derivation function based on CMAC. He also mentioned that this mode of HIP is being considered for the key management protocol for IETF CORE WG (DTLS-PSK and EAP-TTLS are other modes) as well as for key management in IEEE 802.15.4. Antonio Herra: Could DEX be adapted for constrained networks (6LowPAN)? Bob: Yes, this all ties in together. Robert Cragie: In 15.4 security, we punted on it due to diverse range of applications. Regarding ZigBee PANA, PANA works on UDP which works on 6LowPAN. TLS is very flexible, efficent due to reuse. My question is how flexible is HIP DEX for cipher suites and key management mechanisms? Bob: It is flexible, can key the mac, IP, and DTLS. Right now, only ESP supported, but am working on DTLS. 6) Jani Pellikka reviewed an update to the HIP Certificate Requests draft, proposing a technique for requesting certificate of a peer host, and request for issuance (signing) of a certificate. Tom Henderson: Plan to keep this in the RG or move to the WG? Jani: Not sure about RG or WG yet; we plan to implement it. 7) Zhen Cao presented a new draft on flow mobility bindings (draft-cao-hiprg-flow-mobility-00). This proposes to add RFC 6089 flow bindings to a new E-Locator type, to allow granularity in moving flows to different locators. Rene Hummen: Why don't you just transfer all of your flows to the best connection? Zhen: Sometimes 3G has better QoS control, sometimes WiFi has more bandwidth but more congestion. Tobias Heer: Is using required flag in locator a good idea? Should new type be used instead? If new type is used, and host doesn't support it, then you just lose the granularity of flow movement, rather than losing all mobility functionality. Tom Henderson: Similar to this comment, please note that there is standards track work on the mobility draft; we can discuss there whether existing locator in 5206-bis could be extended in this way. Otherwise, use another type. Andrew McGregor: This proposal (6089 flow IDs) is a good idea; we just need to resolve how to do it. Tom Henderson: Please track this issue in the HIP WG. 8) Zhen Cao presented a new draft on communications between a HIP host and a legacy host (draft-cao-hiprg-legacy-host-00). The scenario that we are interested in is when the HIP is totally unaware of the proxy. Should this be integrated into the proxy draft? I talked with Dacheng; he has some consideration of this. First, security between proxy and legaxy host. We assume it is secure channel. Second is integration. Action item is to ask whether this is reasonable to include this scenario to the proxy draft? Tom Henderson: Dacheng (editor of proxy draft) not in the room right now. If I look at diagram, this looks like the home VPN "back to my MAC" use case. Is this the same? Rene Hummen: Not sure; Miika proposed that service, but it looks like it to me. Tobias Heer: Will HIP host be able to figure out it is talking to a proxy instead of HIP host? Zhen: No. Tobias: In which case, this may hurt, because stack on HIP host assumes a secure host, then this assumption no longer holds if the connection is indeed insecure. This doesn't occur in home VPN because it is secure. HIP host nees to know it is insecure. Zhen: Will take into consideration. Tom Henderson: Discuss with Dacheng about inclusion to proxy draft. Resolve on the list. 9) Dmitriy Kuptsov presented an update to the hierarchical Host Identity Tags verification draft. Offload HIT verification to third party infrastructure. Want to take into account the possibility of HIT revocation. When HIP security gateway sees control packets, it can use the hierarchical bits to resolve the domain, then submit to domain authority for verification. Deployed on PlanetLab and discussed measurements, experienced a lot of loss and instability. Tom Henderson: How much of your performance is due to PlanetLab problems? Dmitriy: We believe a lot of impact due to PlanetLab problems. Tom Henderson: Any action for research group? Dmitriy: Can discuss offline. 10) Tapio Leva and Ari Keranen introduced the topic of HIP deployment from a techno-economic issue and described plans to write a draft by the next IETF meeting. The methodology may involve interviews with various stakeholders to discuss deployment incentives and bottlenecks. Andrew McGregor: See value in doing this; not sure whether it is IRTF activity or publishing paper. You missed an obvious issue: not just why do OS vendors not deploy HIP, but device vendors (e.g. gateways). Ari: Yes, these are kinds of discussions we want to have.