Dino, >-----Original Message----- >From: Dino Farinacci [mailto:[email protected]] >Sent: Monday, January 05, 2009 2:14 PM >To: Templin, Fred L >Cc: Fleischman, Eric; Pekka Nikander; RRG; Robin Whittle >Subject: Re: [rrg] Rejecting all but Strategy A > >>> -----Original Message----- >>> From: Dino Farinacci [mailto:[email protected]] >>> Sent: Monday, January 05, 2009 2:01 PM >>> To: Templin, Fred L >>> Cc: Fleischman, Eric; Pekka Nikander; RRG; Robin Whittle >>> Subject: Re: [rrg] Rejecting all but Strategy A >>> >>> Before we get carried away with what looks like a convergence of >>> "HIP- >>> proxy and LISP", tell me what HIP offers to a LISP router that the >>> LISP architecture does not already provide? >> >> I was actually saying convergence of "HIP-proxy and xTR"; >> xTR does not necessarily mean LISP. > >Sorry, I'm not going to let you off that easy. If you don't define xTR >then you can't way what or what not HIP-proxy can offer it. Because >"it" might already have the feature, but since you don't want to be >concrete, you leave it all open ended. Which makes for a non- >productive conversation.
All I am saying is that HIP can run over a tunnel virtual interface (on an "xTR") just the same as it can run over a physical interface. How the xTR makes its mapping and encapping decisions to send things over a tunnel virtual interface is largely orthogonal wrt what HIP brings. >>> If is solely a add a pure definition to IDs and RLOCs, then I think >>> it's not worth the cost of deployment to do so. >> >> In my understanding there's a lot more to it than that, >> but would welcome clarifications. > >Well there really isn't. It's just this list that makes a mountain out >of a mole-hill. No; there really is. For example, that is why I asked Pekka about HIP mobile router. If a HIP proxy can do mobility signaling on behalf of end systems, then that is beyond the capabilities being offered by just the map-encaps solution. Fred [email protected] >Dino > >> >> >> Fred >> [email protected] >> >>> >>> Dino >>> >>> On Jan 5, 2009, at 1:27 PM, Templin, Fred L wrote: >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Fleischman, Eric >>>>> Sent: Monday, January 05, 2009 12:13 PM >>>>> To: Dino Farinacci; Pekka Nikander >>>>> Cc: RRG; Robin Whittle >>>>> Subject: Re: [rrg] Rejecting all but Strategy A >>>>> >>>>> >>>>> >>>>>> From: Dino Farinacci [mailto:[email protected]] >>>>>>> From: Pekka Nikander >>>>>>> What comes to HIP and RRG, I do believe that HIP *could* help in >>>>>>> solving the RRG problem. It *could* form a core for what people >>>>>>> now >>>>>>> call "Strategy B" solutions, and a HIP-proxy based solution >> *could* >>>>> be >>>>>>> deployed as a "Strategy A" solution. 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, >>>>>>> yielding a >>>>>>> "Strategy A" HIP-based network-level solution that could >> eventually >>>>>>> lead to full HIP deployment at all hosts, which *could* lead to >>>>>>> an >>>>>>> architecture where renumbering is never needed due to full >>>>> transparent >>>>>>> support of multiple IP addresses at all hosts. >>>>> >>>>>> 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. >>>>> >>>>> I strongly resonate with Pekka's posting. >>>> >>>> Pekka, is "HIP-proxy" and "HIP mobile router" one and the >>>> same thing? 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? >>>> >>>> Fred >>>> [email protected] >>>> >>>>> Speaking solely for myself, I view LISP's original claims to be a >>>>> locator-identifier split to be a redefinition of what those terms >>>>> have >>>>> historically meant (i.e., to be marketing -- not reality). By >>>>> contrast, >>>>> HIP is a true locator-identifier split technology in every sense of >>>>> the >>>>> historic meaning. >>>>> >>>>> LISP, by contrast, is a map-and-encaps solution to the RRG problem. >>>>> >>>>> There is no necessary relationship between HIP (or any other >>>>> locator-identifier split) and LISP (or any other map-and-encaps). >>>>> Specifically, I believe that locator-identifier splits are a >>>>> session >>>>> layer concept and therefore are primarily host-related. I believe >>>>> that >>>>> map-and-encaps is primarily a network layer concept. >>>>> >>>>> By combining a true locator-identifier split (i.e., HIP) with a >>>>> map-and-encaps (e.g., LISP) one gets the combined benefits of both >>>>> approaches. Those benefits are >>>>> >>>>> * For HIP-based applications (i.e., hosts) this creates a full >>>>> decoupling of application issues from network issues. This >>>>> simultaneously solves many different problems including the >>>>> following: >>>> a >>>>> transparent solution to application multihoming; complete >> agnosticism >>>>> concerning network issues including IPv4 or IPv6; strong session >>>>> coherence in the face of substantial mobility; solution to the "IP >>>>> identity problem", thereby solving a great many festering security >>>>> issues including a clean integration with IPsec, providing >>>>> best-current-practice Denial-of-service (DoS) attack resistance, >>>>> exponentially increasing the ability to identify and defend against >>>>> spoofing attacks, substantially increased protection against >>>>> session >>>>> hijacking, and (by solving the identity problem) making existing >>>>> application authentication and authorization systems become more >>>> viable. >>>>> * HIP also provides a formal (secure) delegation capability that >>>>> permits HIP users (e.g., hosts) to delegate authority to other >>>>> entities >>>>> to act on their behalf. This would, for instance, allow a host that >>>>> wants to hide its current location to use network proxies to >>>>> forward >>>> its >>>>> traffic. For example, DoS attacks could also be deflected to >>>>> network >>>>> proxies. >>>>> >>>>> * For map-and-encaps based systems this provides a scalable >>>>> network >>>>> integration capability to resolve a wide variety of different >> network >>>>> scalability and integration challenges including: >>>>> 1) IPv4-IPv6 coexistence: ISATAP, Teredo, IPvLX, etc. >>>>> 2) Military Communications Security (COMSEC) >>>>> 3) IPsec's ESP in tunnel mode >>>>> 4) L3VPN (including how my employer relates to our ISPs (please >>>>> note >>>> the >>>>> plural)) >>>>> 5) ecommerce >>>>> 6) ARINC 664 enclave protections >>>>> 7) Architectures that leverage IP to join together distributed >> legacy >>>>> (i.e., non-IP) protocol systems. It is also used to merge legacy >>>>> populations into IP networks (e.g., RFC 1006). >>>>> >>>>> --Eric >>>>> _______________________________________________ >>>>> rrg mailing list >>>>> [email protected] >>>>> https://www.irtf.org/mailman/listinfo/rrg >> _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
