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