[rrg] Rejecting all but Strategy A

[Dino Farinacci]

>> -----Original Message-----
>> From: Dino Farinacci [mailto:dino at cisco.com]
>> Sent: Monday, January 05, 2009 2:01 PM
>> To: Templin, Fred L
>> Cc: Fleischman, Eric; Pekka Nikander; RRG; Robin Whittle
>> Subject: Re: [rrg] Rejecting all but Strategy A
>>
>> 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?
>
> I was actually saying convergence of "HIP-proxy and xTR";
> xTR does not necessarily mean LISP.

Sorry, I'm not going to let you off that easy. If you don't define xTR  
then you can't way what or what not HIP-proxy can offer it. Because  
"it" might already have the feature, but since you don't want to be  
concrete, you leave it all open ended. Which makes for a non- 
productive conversation.

>> 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.
>
> In my understanding there's a lot more to it than that,
> but would welcome clarifications.

Well there really isn't. It's just this list that makes a mountain out  
of a mole-hill.

Dino

>
>
> Fred
> fred.l.templin at boeing.com
>
>>
>> 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
>