> -----Original Message----- > From: Pekka Nikander [mailto:[email protected]] > Sent: Wednesday, January 07, 2009 3:30 AM > To: Templin, Fred L > Cc: RRG; Robin Whittle > Subject: Re: [rrg] Rejecting all but Strategy A > > I (Pekka) wrote: > >>>> I don't know the details of LISP, but the recent discussion > >>>> between Dino and me seem to indicate that HIP proxy and > LISP xTRs > >>>> are functionally close enough so that a HIP proxy could be > >>>> "plugged in" to the LISP architecture... > > Dino replied: > >>> And since I don't know the details of HIP-proxy, saying LISP and > >>> HIP-proxy are functionally equivalent only occurs at a > >>> conversational level. The devil is in the details of course. > > Eric noted: > >> I strongly resonate with Pekka's posting. > > Which make Fred to ask: > > Pekka, is "HIP-proxy" and "HIP mobile router" one and the > same thing? > > Briefly, a "HIP-proxy" (as I understand the term) could be > implemented > as a version of the "HIP mobile router" (draft-melen-hip-mr-01.txt) > that has the additional feature of being able to support unmodified > legacy IPv4 and IPv6 nodes in the mobile network. For such legacy > nodes, the MR node would create ephemeral HIP identities and > assign an > IP address in the moving network side for each identity. Hence, > typically, the legacy host would get a single stable the IP address > through DHCP or ND, in which case the MR would act as the DHCP or ND > server. OTOH, there is no need for the MR to actually be mobile -- > the mobility aspect could simply refer to its ability to use > interchangeably multiple PI addresses. > > So, I guess my answer is a qualified "no". They are not the same > thing, though they could be close.
I agree that HIP-proxy and xTR are not the same thing. xTR tunnels, mapping entries, cache entries can cover aggregates of hosts, while HIP-proxy has per-host granularity. xTR doesn't claim to represent any host from a security point of view, while HIP-proxy seems to. > > One old, outdated description of the HIP proxy functionality is > available as Patrik's MSc thesis at > http://www2.cs.hut.fi/~pmrg/index.cgi?id=148 > But that is basically 4 years old and concerns only the > case where > there is a 3G legacy network, not generic legacy networks at both > sides. Quite obviously, the thinking has evolved quite a lot since > then. > > > If so, IMHO it is absolutely realistic that the HIP-proxy and xTR > > could occur on exactly the same platform. Note that they are > > complementary functions, however; not competing ones. I think this > > also goes with what Eric was saying below? > > I don't see any problem at all in installing a HIP proxy and xTR at > the same box -- they could even use the same mapping > infrastructure to > find out the RLOC of the peer HIP proxy/xTR, and then in > parallel send > an opportunistic HIP I1 and whatever LISP sends when an xTR contacts > another xTR that it has no prior association with. But that > would be > a (minor) waste of resources as two packets would be sent in parallel. This would probably increase the load on the mapping system and xTRs considerably, because of the per-host granularity. I'm not sure how it would work for multiple ITRs and ETRs, are there multiple proxy host identities, one for each xTR? How is that handled with mobility or path unavailability events? It changes the security model for HIP-- when I move behind some ITR, am I going to want my packets to flow unprotected between my host interface and the ITR? Am I going to trust arbitrary ITRs to proxy for my host? Also, are ITRs going to have any incentives to give me good (or any) HIP service? > > Initially, what I think would be interesting to understand is the > possibility of two additional designs: > > 1. One where the LISP xTR-xTR protocol is replaced with the HIP > protocol (providing the additional mobility and security > features HIP > provides). > > 2. One where the initial xTR->xTR opening message is a hybrid that > indicates that the sender understands both LISP and HIP, > allowing the > receiver to pick which one to use. > > And then I could imagine a few designs beyond either... Are you instead suggesting above to look at combining HIP with LISP, or HIP-proxy with LISP? I see the distinction being that HIP with LISP means that HIP keys are used to name xTRs and to secure the xTR to xTR communications (and possibly communications with the mapping system), but otherwise LISP works as described. Proxy-HIP keys would name individual hosts and would play more of a role as an EID in the system. - Tom _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
