HIPRG minutes Friday, Afternoon Session I 1230-1500 Room Name: Room 513B ------ 1. Agenda discussion and status update - draft-irtf-hiprg-nat-03.txt http://www.ietf.org/internet-drafts/draft-irtf-hiprg-nat-03.txt - draft-irtf-hip-experiment-02.txt http://www.ietf.org/internet-drafts/draft-irtf-hip-experiment-02.txt 2. Drafts draft-pierrel-hip-sima-00: HIP Simultaneous Multiaccess (Petri Jokela) http://www.ietf.org/internet-drafts/draft-jokela-hip-service-discovery-00.txt Julien Laganier: I'll have a question on draft-lindqvist-hip-tcp-piggybacking-The TCP segments piggybacked on I2 and R2 aren't protected at all? Tim S.: skeptical that we will build into applications managers that are aware of multiple i/fs. Sebastien Pierrel: Bittorrent for example. Tim S.: seems to be hard problems here. SP: don't quite see your point. TS: Can't imagine end users wanting to tweak these knobs, so we need something automatic. Petri Jokela: We made the easy part, the difficult is common for many other wg also, shim6, monami... I know that's a very hard problem that cannot be solved in two years. Shinta: question about how the locator part is handled, binding flow per interface? Seems a bit redundant to establish another SA for only the purpose of having multiple locators. ?: application may not be able to establish the interfaces AG: how does it work, separate SAs per HIT? SP: for every.... can have multiple SAs. Miika Komu: there should be one SPI per interface in the mm draft. SP: here we are taking multiple interfaces into account. Andrei: anyone from shim6 that can comment? Shinta: I was also working on shim6, as far as I see there is no work on this topic. Common need but no particular work here. SP: should this be a research group topic? Andrei: take it to the list, I think Tom has a comment. draft-jokela-hip-service-discovery-00: IP service discovery (Petri Jokela) http://www.ietf.org/internet-drafts/draft-pierrel-hip-sima-00.txt Petri: this work started because we needed to locate services on the ML this came up that this resembles the old BOS packet (bootstrap) service discovery could be used in the same manner as the BOS. Andrei: status of BOS, removed? Petri: Yes it is removed. nobody wanted to work on it at that time. slide: New packet: Service Discovery...describes active service discovery. The packet structure in its basic form is like an I1 with a destination HIT set to zero the REG_INFO from the reg draft is optional. slide: New Packet: Service Announcement R1 parameters may be included to speed things up. slide: Active Service Discovery...gives example of a HIP host joining a network ...host increasing TTL. slide: Active Service Discovery...going through slide animation describing the process, new diagram showing regional model. slide: Active Service Discovery (multiple frames) slide: Passive Service Discovery the HIP node doesn't do anything actively slide: Passive Service Discovery...describing diagram...the yellow circle has a local address space, will not go into detail about MR operation. slide: Implementations Ericsson has implemented on-path, plans for regional. slide: Future Haven't been looking at existing protocols. How this could be transferred to other protocols? ... I don't understand why service discovery needs to be integrated in the HIP protocol. Why can't we just use DNS records, or SLP? Tim S.: I have the same question. TS: reading the draft, I see it uses site local multicast address ... deprecated? I was still unable to think of a motivating example if you can think of a unicast address ... you are looking for middleboxes, why? Petri: for HIP-aware middleboxes we need this for the MR, a network mobility scenario. TS: maybe you need some motivating examples in the draft, or point to one maybe you could give an example now. Bill Atwood: one of the things that I see is ICMP packet being thrown away by routers because of the security damage, but you are relying on them. Have you considered that risk at all? PJ: we should implement some kind of timer in that case... Andrei: or do it in parallel. BA: a whole bunch of router admins throw this stuff away. Miika: another use would be searching for a printer or something or in the NAT draft there is a hairpin problem using service disc. Or BOS you can figure out if two nodes are in the same network. Petri: OK we could define. Andrei: what is the advantage of Active vs Passive? MK: passive works only on path. Petri: passive "" "" Andrei: with active discovery you probe off path, how do you know which places to probe? random? Petri: broadcast on the link Andrei: what about for beyond TTL 1? Petri: we use site local address Tim S.: I may be repeating myself, but as a group we cannot ask questions about this unless we understand what you are trying to accomplish. If midbox detection is the issue, there is MIDCOM... Andrei: think about Windows services TS: why should this be a part of HIP? Petri: we need to look at existing protos, do we provide an advantage? If Service Discovery is the issue, still SLP, DNS, or even multicast DNS. AG: some generic protocol might not be aware of HIPs. TS: I'm full of questions about this ... I'm full of questions about this but I cannot figure out which questions are appropriate to ask without first understanding what the motivation for this is. Petri: we will look at these issues. draft-lindqvist-hip-tcp-piggybacking-00.txt: TCP piggybacking (Janne Lindqvist) draft-lindqvist-hip-opportunistic-01.txt: Opportunistic mode with TCP option (Janne Lindqvist) http://www.ietf.org/internet-drafts/draft-lindqvist-hip-opportunistic-01.txt Janne Lindqvist: Establishing HIP Opportunistic Mode with TCP option was presented in Dallas but this is about the new draft. General comment: I like the idea, this is a neat hack general comment: I hate the idea, this is a bad hack slide: Motivation for the Approach slide: Basic Idea :-) but since this is the rg, looking at this is ok oh wait, the "bad hack" comment goes with janne's other draft I agree with julien :-) Lars, so the bad hack is piggybacking? slide: Alternatives ... result of hallway discussions ... w.r.t. security, the TCP segments piggybacked on I2 and R2 aren't protected at all? Lars: what's specific about TCP about this? Why can't you allow other transports to piggyback ... relax the MUST to a MAY and it becomes much more general. Janne: true Agree with Lars. Could possibly work with any protocol. TS: ... you would have all you need at the end of the packet you could have a magic SPI. Agree with Tim as well. TS: it could work, need more details... If you use a fixed SPI you can use ESP. JL: it could work... also ESP was removed from the base draft, so there may be more that I don't know. And protects piggybacked packet TS: Bob Moskowitz originally wanted this functionality in the protocol. You don't want to add another RTT. Issue is that some IPsec people are allergic to fixed SPI, they equate them to SKIP, and SKIP was ruled out by IETF. TS: reason to put it in the same packet ... to protect it with ESP. It's unfortunate ESP was removed from the base draft, b/c it makes this harder to explain. Lars: Still suggest that you don't just focus on ESP. What if you had simult. SYN. Use something that protects that stuff, this would be awesome. Andrei: any issues with maximum packet size? It should fit but what if not. LE: you need to know how big the data is you want to include, there are ways to do this. JL: I need to look at not only TCP, that sounds interesting to me. 3. Software Status update of experimental implementations. Miika Komu/HIIT NAT support for client, currently implementing NAT server, it would be nice to have a planetlab testbed and provide free rendezvous service. We have 4 CDs that contain knoppix live CD with HIP support. We welcome any feedback and also will post this to the project web page. Jeff Ahrenholz/Boeing Done upgrading of drafts, support for IPv6, NAT support from NEC will be included in the next version of OpenHIP, Mac OS X support. Petri Jokela/Ericsson Ericsson implementation is up to date, but I don't know much about that. The woodtsock test server doesn't yet support the new 28-bit HIT prefix. 4. Open discussion Lars Eggert: some of these things don't seem very researchy to me anymore if we have running code and it interoperates, full standard immediately :-) AG showed related web sites http://www.openhip.org and http://infrahip.hiit.fi, IRTF wiki, http://www.hip4inter.net/ Tim S: (talking about Dave Thaler's mobility comparison draft): it's a really interesting draft You should go look at this draft... there are some "no's" in his tables http://www.openhip.org/irtf/wiki/index.php?title=Main_Page (that is the IRTF wiki page) Look at the draft and see if HIP is being explained accurately what's the draft about mobility protocols comparison? draft-thaler-mobility-comparison-01.txt Dave Thaler: outages point is not clear... outages is where both ends think their locator is working but they are not based on IETF *WG* it has the signalling stuff, but not discovering the failure. TS: it's an accurate description of the scenario. LE: was a really good presentation, too, slides at IP mobility protocol comparison. TS: An implementation might do something here too. What would the implementation do in this situation, what would you expect your implementation do? Andrei: double jump. Hi3 is based on an overlay network. TS: the double jump is a different situation: both hosts have multiple locators, each AB – YZ A - Y can communicate, then something goes wrong, failure in the middle of the network, communication from A-Z might work, but would an impl. discover this fact? In SHIM6 they have a story for that. Andrei: is this purely an implementation issue? Doesn't require any interoperability. DT: what probing mechanism are you going to use? TS: if we don't write this don't people won't be convinced as to how which probing mechanism, depends what the other side can support, not interop if the other side doesn't respond. You probe with various TCP retransmissions. DT: that's a mod of the TCP protocol -- if you spray them across different paths. TS: I don't think this would change the protocol. MK: mm draft gives a mechanism to probe for active locators using the reachability test, hasn't been nailed down in the draft. Andrei: something added to the SIMA draft later? About how to probe local interfaces. Sebastien: OK we can look at that. Andrei: set of drafts in WG is quite small, in RG we have had 20 or so drafts, not easy to find ... like privacy extensions, etc. Andrei (to DT) thanks for writing the document it is useful. Xiaoming Fu: invite you to a workshop, deadline end of this month. It will be collocated with GLOBECOM Nov 27-Dec 1 in San Francisco. Please send good topics to me. Shinta: would like to add about reachability verification. SHIM6 has failure detection protocol in the works designed so it could be used with other protocols, like HIP. It may be useful for implementers. Andrei: thanks for coming, we are done.