>-----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
