[rrg] Rejecting all but Strategy A

[Dino Farinacci]

With respect to security in LHIP by using hash-chains, we consider  
them for LISP, but requires 3 to 4 packet exchanges, so a non-starter.

Dino

On Jan 7, 2009, at 3:47 AM, Pekka Nikander wrote:

> On 6 Jan 2009, at 00:01, Dino Farinacci wrote:
>> 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 don't know what LISP already provides, so the following are mere  
> guesses.
>
> - Security?  Both opportunistic, no-infrastructure-requiring  
> security for multi-homing/mobility, and baseline-level signalling  
> security for integrating any security infrastructure you want (such  
> as PKI, AAA, ...)
>
> - Mobility?  As HIP proxy can be trivially integrated with the HIP  
> mobile router (MR), the legacy networks can be mobile without any  
> extra effort.  (Provided that the mapping infra has the required  
> updating capability...)
>
> - Ability to move more cleanly to a host-based solution, better  
> serving mobile and multi-interface hosts.  This includes the ability  
> to support upgraded hosts in the legacy networks.
>
> Obviously, the next question is what the drawbacks would be.  Here  
> is my initial list:
>
> - Crypto.  Current HIP requires PK crypto (but no PKI!) and ESP.   
> LHIP (which uses only hash functions) is an option if people  
> generally shun PK, and, as I already explained, ESP can be replaced  
> with any tunnelling or flow-identifying protocol.
>
> - Lack of operational experience.  AFAIK, only Boeing has  
> operational experience on HIP.  I guess there is more operational  
> experience available on LISP, even though I haven't seen any.
>
> (I am sure there are others, but I cannot figure out any other  
> drawbacks right now.)
>
>> 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.
>
> Agreed.
>
> Obviously, _for_me_ the main benefit would be the ability to cleanly  
> move to a host-based solution, in such a way that the upgraded  
> mobile hosts could work both stand-alone in the "new internet" (at  
> the non-legacy side of xTRs) and in the legacy networks, without any  
> extra overhead.  (That is, any upgraded hosts at the legacy networks  
> would report their existence to the xTR, which would understand  
> their presence, avoiding double encapsulation and signalling  
> overhead).
>
> --Pekka
>