Minutes of the joint meeting of IRTF HIP and EME RG Tuesday July 24, 1300-1500 -------------------------- Meeting co-chaired by Tom Henderson, Tilman Wolf, and Mark Williams Purpose of joint meeting: Explore relationship between HIP and EME architectures: - interest within HIP community with middlebox-oriented architectures - relationship between namespaces of the two architectures - HIP recognizes that namespaces will need to be built on top of cryptographic HIP API Questions: - Do HIP and EME architectures complement one another? - Does EME/NUTSS have something to offer HIP with respect to NAT traversal - Does EME/NUTSS derive any benefit from HIP? - What can either or both research group do to encourage more experiments and deployment? 1. Paul Francis: EME draft review draft-irtf-eme-francis-nutss-design-00.txt -Looking for active feedback, BOF was well attended, but interest has dropped off - Goal is to be able to establish connections, keeping in mind the policy interests of various stakeholders along the path - explore a lot of other things one can do with a name-based namespace - expose the ends to middleboxes and vice versa - looking at clean slate for now before looking at actual protocols and overlap with existing IETF work - Introduction of NUTSS - name-based and address-based routing - p-boxes and m-boxes - name routing very much like SIP Tim Shepard: is the EME token (passed in address-routed signalling) singular? Paul: may need to have one for each m-box. It goes in the address-routed signaling message. May bind you back to a HIP name or other crypto a 5-tuple flow. Aaron Falk: Are you thinking about the granularity of the hole (5-tuple or more) that the token might open up in a firewall? Paul: There has been a notion that you can open up a range of points, that state would time out, etc. Philip Matthews: My experience with NAT traversal is that you seem to be more successful the minimum assumptions you make about trusting other components in the network (making assumptions about applications trusting firewall and so forth). Paul: Agree. Paul: Want to generate enthusiasm or criticism of this so we know where to go from here. Aaron: I didn't follow your authentication, number of round trips per flow. Paul: Various ways to do this (open questions). In case of name routing, should be established relationships. Address routed stuff is just the tokens. Mark Handley wanted to put in application data there too. Michael Richardson: Have you looked at Security Policy Protocol, Luis Sanchez, part of IPSP WG a few years ago; architecture and results are similar. Somewhat validates the result if several people come up with similar architecture independently. Paul: didn't know about that, please send a pointer. Dan Wing put out something similar a few years ago too. 2. Philip Mathews draft-matthews-p2psip-hip-hop-00.txt Review of this P2PSIP draft that proposes to use HIP as an overlay-routed basis for P2PSIP. (Slides posted on the meeting site). Paul Francis: How does the first connection get through the NAT? Philip: Need some way (rendezvous server) to bootstrap the first server Paul Francis: Intent is to use the rendezvous server rarely. Philip: Yes, the first connection. Tim S.: Someone not behind the NAT could bootstrap this-- could be like Gnutella was. Philip: Interested in finding people to work with us and refine it. Plan is to work on some prototypes, also with Gonzalo Camarillo. Tim S.: Might be great example of how to encourage HIP usage. 3. Joakim Koskela HIP-based Peer-to-Peer SIP (Slides posted on the meeting site) Described a system that they are building, combining the HIPL stack (HIP implementation), P2PSIP Proxy, and any SIP application. Has been tested in various configurations. Some discussions of this and other P2P SIP protocols at the P2PSIP WG. 4. Marcelo Bagnulo Braun draft-oliva-hiprg-reap4hip-00 (Slides on REAP4HIP) Try to understand scenarios for HIP multihoming and what stuff is missing to make it work. Presentation is a set of scenarios, some solutions for the easy ones, and introduction of the harder ones. Tim S.: Dual-stack hosts are multihomed as well. Might be doing Teredo. Might have multiple IPv6 and IPv4 addresses. Marcelo describes complicated NAT multihoming scenario. Tim S.: How does it work today? Marcelo: It doesn't-- you are not able to preserve established communications when your NAT fails. HIP here has some promise to be able to solve this, though. Hannes: Have you discovered REAP is a small version of STUN? Marcelo: No-- there are some differences. REAP does not introduce overhead when there is data traffic. REAP supports unidirectional connectivity, which is important in multihoming situations. Hannes: ICE can detect a NAT and do keepalives. REAP does not work on IPv4. Real-world communications in NAT/firewall world-- unidirectional routing support does not help. Marcelo: If your inter-site routing gives you unidirectional paths, you have to deal with them. 5. Open discussion on HIP and EME Andrew McGregor: I think there is strong synergy. Something like EME architecture was discussed in the early days of HIP. Hannes: Provocative statement: HIP and SIP largely orthogonal, with perhaps some small overlap which is to allow SIP to do a capability negotiation and signaling for later data exchange. Might be interesting to tie the two together, but got almost no comments on a draft on that. Can't see what additional input. Tom: Aspect of EME that is nice is URI-based names as means to configure policy-- probably needs to be built on top of HIP, which has less friendly and aggregatable names. Also, very little work in HIP to work out the policy details for HIP-aware middleboxes. For example, trying to implement policies such as "default off", there is value in having an aggregatable name. Question for Paul: How do you see integration of HIP with NUTSS? Paul: Idea for EME is making explicit policy of middles and end, but protocols we have (e.g., IPsec) tend to be two-party protocols. Difficult to use existing protocols to support multiple parties. That's where HIP becomes interesting-- to accommodate multiple middleboxes. Michael Richardson: Can you distinguish authenticate from modify? Integrity protection vs. middleboxes that want to change messages? Paul: Was referring to authenticating and not modifying middleboxes. Michael: I'm more comfortable with that. Andrew: Don't need to modify-- can append. ?: NUTSS seems to be allow policies such as identify/allow/deny or some deeper functions allowing processing based on application semantics. Paul: Don't want to go there (the latter). Want to keep this low level. Some deeper packet inspection is needed to do application-semantic-related work. Andrew: Have thought about issuing an identity to applications as well. Melinda Shore: I think of NUTSS as conveying policy requests to middleboxes-- what is in those requests (pinholes or more) is not that important right now. ?: Different ends of the connection know more or less about different identities. What about identity delegations? Paul: Not sure I understand the question. I see the policies as being more like existing policies. I haven't gone into delegations. Paul: Question for the HIP crowd. You seem to be interested in NAT traversal. I see that HIP could use EMEs names, but I sense that what you really want is ICE for the short term. Tom: We get a lot of feedback that NAT traversal is a critical missing piece of our software. Paul: NUTSS has similar problems-- we assume middlebox is playing along, but in short term, we need to use ICE for now. In the end, if you have legacy NATs, you have to do ICE. Tim: Multihoming is important for HIP. NUTSS seems to be nicely oriented towards that. Paul: Yes, you have location-independent name, and you can bind it to one or more addresses. Philip: EME question. Struggling to understand how NUTSS proposal differs from many other middlebox traversal proposals that have gone through. I don't see it myself. Melinda: NUTSS is a way of integrating on-path and off-path signaling; problems with doing these in isolation. If you have multihoming, nested middleboxes, etc. on-path becomes difficult. NUTSS combines it in a way that it all works. Not that protocols are all that different, it is just the integration that is new. (end of session)