[rrg] Rejecting all but Strategy A

[Dino Farinacci]

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?

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.

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: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.
>
> 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
> fred.l.templin at boeing.com
>
>> 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
>> rrg at irtf.org
>> https://www.irtf.org/mailman/listinfo/rrg