Dino, >-----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. >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. 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
