Dino, I don't know the operational cost of HIP in stable networked environments because our many laboratory experiments have focused on very high mobility environments where the HIP overheads are trivial compared with the multiple advantages of using HIP (i.e., without HIP the applications become very brittle).
We have operationally deployed HIP as a basis for securing our IP-connected SCADA machine controllers in our factories. This is the most viable way to secure IP networked-attached SCADA devices that we know about. Again, the operational costs of doing this are trivial compared with the risks with leaving these machines inadequately secured. I myself am not aware of the NAT impacts to HIP though I have noted (but not yet read) the existence of a HIP I-D on that topic (see http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-05.txt) . I suspect that you are overstating the problems with NATs because HIP has proven to be surprisingly clean and the HIP proxy capability is powerful. However, I myself have not envisioned using HIP in environments having NATs except for the narrow context of overcoming ARINC 664-based limitations impacting aircraft's generic (public) IP addresses. By contrast, the more significant issue in civil aviation is whether the aeronautical air-to-ground and air-to-air networking will occur within the context of VPNs (i.e., hierarchical routing/addressing systems perhaps resembling military COMSEC; e.g., each VPN domain perhaps associated with a specific ARINC 664 intra-aircraft partition) or whether the civil aviation addressing/routing will alternatively be a common (flat) system with the intra-aircraft partitions accomplished by air-gaps and firewalls. --Eric -----Original Message----- From: Dino Farinacci [mailto:[email protected]] Sent: Monday, January 05, 2009 2:12 PM To: Fleischman, Eric Cc: Pekka Nikander; 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. > > 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. Well IDs are used for TCP/UDP socket endpoint demuxing. And RLOCs are according to the original definition. But we extended to have IDs *also* be routable inside of a site. We had to for incremental deployability. We don't want to force renumbering of all site-based hosts, switches, routers, firewall devices, etc. > LISP, by contrast, is a map-and-encaps solution to the RRG problem. With LISP, you can move a host to a new RLOC while keeping a TCP connection up. That is the EID does not have to change for the host. > 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. Definitely agree on session-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 But you add another layer of addressing that is probably more than the user wants. It could get this bad: HIT -> EID -> private-RLOC -> public-RLOC when behind a NAT or HIT -> private-EID -> public-EID -> RLOC when behind a NAT 2-levels of mapping is plenty, adding 2 more probably is a non- starter. Remember folks, we have to incrementally deploy this with minimal cost, see Yakov's post early today, he makes good points. > * 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. And it cleans your dirty dishes as well. ;-) Eric, care to quantify the cost of deploying all this machinery? Dino > * 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
