[rrg] Rejecting all but Strategy A

[Dino Farinacci]

>> From: Dino Farinacci [mailto:dino at cisco.com]
>>> 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