HIPRG minutes (scribe Andrew McGregor) 10min Update on HIP experiments (Andrei Gurtov) http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-03.txt Report from Dagstuhl Seminar 06441: Naming and Addressing for Next-Generation Internetworks http://www.dagstuhl.de/06441/ 15 min Update of HIP DHT interface (Samu Varjonen for Jeff Ahrenholz) www.ietf.org/internet-drafts/draft-ahrenholz-hiprg-dht-01.txt Q: Doesn't the DHT do hashes for you? A: Yes, but we are shortening the names by hashing them first, so they can be longer than 20 bytes. 15min IPv4/v6 interfamilily handovers (Samu Varjonen) Clarifications to mm-05 draft on handovers between IPv4 and IPv6 Should this be in its own draft? No, it's merely a clarification to mm. Q: Why would this be a security problem? Not really, we're more worried by routing etc. working. Issue is: should R accept an UPDATE with no addresses in common with previous state? Comment: for sure, iff full HIP state exists. Conclusion: this is perhaps a necessary clarification for mm since the question arose. 25min. Lightweight HIP (Tobias Heer) http://www.ietf.org/internet-drafts/draft-heer-hip-lhip-00.txt Discussion over performance: does 500ms for an update really matter? Ans: Yes, if app is interactive. LHIP is also relevant for big servers because of crypto there. Hash chains: how long will they be? Quite short to start with, and can be renewed later anyway. Suggestion: use PK to anchor the hash chains, keeps more security properties. Comment: middlebox verification is much simpler, and this is a good property. Q: If LHIP is implemented on a server, and I know the HIT of a client, I have some attacks. A: True, but if one end requests full HIP, the attack will fail. We are not protecting against impersonation until full HIP is run. Q: If crypto were much faster, would this be necessary? A: Perhaps still. VoIP, for instance, with very fast handovers. Hardware crypto is becoming common on low-end devices. Q: Does this allow IDs to be arbitrary strings? A: Until you try to upgrade, because the HIT is a hash of it. You'd still like the ID to be unique. Long discussion of value of the idea, somewhat inconclusive. Conclusion: We need more discussion on the list. 15min HIP on Nokia Internet Tablet (Andrey Khurri) Port of HIP on Linux to Nokia N770 Linux PDA and its performance Discussion of N770 wireless performance: looks like stuck on .11b rates 20min NodeID architecture (Martin Stiemerling) Overview of HIP++ architecture from EU Ambient Networks project Clarification: static core LDs mean things like the non-NAT IPv4 internet; a NAT introduces a new LD (usually) Comment: state grows toward core, and this is basically host routing... therefore zero aggregation Q: What's your favourite candidate early adopter? A: Researchers Comment: Companies frequently use 1918 addrs and have to connect to each other. Would the resulting mess be helped by this? Response: Yep, for sure. Comment: Another use case is to talk to legacy stuff or non-IP sensor networks through a gateway with a node-ID. Locators, Identifiers etc (Lixia Zhang) Providers want topological aggregation Sites want PI addresses End systems want address independance First and second separated will reduce DFZ size (first split) Second and third is HIPs game (second split) Q: If you have the third, why does that alone not solve it? A: Enlightened sites would agree, but not all are. There are two groups talking about splits, the two are being conflated. Comment: there are even more kinds of ids and locs. Operator community wants first split ASAP Big sites only need PI Long term need second split, short term need first, make the two coexist Hip Mobile Router (Peetu?) (wasn't paying attention during discussion, sorry) 15min Next steps on HIP mobility and multihoming (Miika Komu) Extensions to HIP mm-05 to use multihoming for fault tolerance Comment: mm mods sound like WG work Comment: nat traversal locators should be as close as possible to best knowledge about what remote end has to use in its packets. Comment: ICE is very useful here, so is perhaps a better way to go than integrating NAT traversal with RVS architecture. 10min Video on OpenHIP Virtual World (Jeff Ahrenholz) 10min Video on OpenHIP Graphical User Interface (Jeff Meegan)