Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00

From: JFC Morfin <[email-masked]>
Date: Fri, 16 Feb 2007 04:35:44 +0100

LISP is intended for IPv4 as well and supports multiple encapsulation 
for unlimited successive addressing capacity.

As a selfish user my main need is not many more network address (I 
have already mine) it is stability, simplicity in installation and a 
very large number of standardizable local addresses (plug and play, 
access grids, etc) to best manage my single IP address (and I can can 
give all the other back, so I am not as selfish as you thought 
first). I understand that LISP gives this to me through successive 
possibility of  addressing encapsulation. I see here a good chance to 
promote NATs to the point to get rid of them in transforming them 
into smart standalone gateways exchanges, speaking LISP with the 
global network and IPv4 or IPv6 or other environment with the local network?

Not to change anything in the existing systems, I proposed to 
structure the IPv6 address payload to split the three address layers, 
and supposed that an 'internat IPv8' could be a grassroots 
intermediary patch. LISP seems to elegantly address all this.

jfc

On 09:34 15/02/2007, Pekka Nikander said:
>I finally had time to properly read draft-farinacci-lisp-00.  To me,
>it is intriguing work from deployment and implementation point of
>view.  However, it also seems to bear wider architectural
>similarities to what would be proxied SHIM6 or HIP, or any other
>proxied host-based identifier/locator split architecture.
>
> From an architectural point of view, I would divide the proposed
>mechanism into four different aspects:
>
>   1. Placement of the identifier / locator mapping function
>   2. Encapsulating of data packets
>   3. State creating between mapping points, i.e., the "protocol"
>   4. Trust models and security mechanisms
>
>Continuing from this architectural viewpoint, at least to me, the
>main feature of LISP is to place the identifier / locator mapping
>function into separate boxes in the network, not at the hosts.
>However, as I tied to outline in draft-nikander-ram-generix- 
>proxying-00.txt, also host-based approaches allow such placement by
>"stretching" the stack into a wire.  In the case of the EIDs being
>routable (as for LISP 1 or 1.5), there is also considerable freedom
>in placing the proxies in the network; see Section 7 of the draft.
>
>Considering the other aspects, LISP and any SHIM6/HIP based proxied
>approach are pretty similar.  Both encapsulate the data packets
>somehow, at least conceptually*).  Both need to create appropriate
>mapping state between the mapping points, and resynchronise the state
>in the case of mobility or state loss.  Both need some mechanism for
>securing against traffic stealing, black-holing, and flooding.
>
>*) When ESP is used with HIP, actually no explicit encapsulation is
>needed since the ESP SPI can be used for demultiplexing the traffic
>at the decapsulating end.
>
>The differences are in details.  The following table attempts to
>capture the crux.
>
>Approach | Encapsulation | Protocol | Security
>---------+---------------+----------+------------------
>LISP     | IP tunnel     | ICMP/new | not defined yet
>SHIM6    | Context tag   | SHIM6    | HBA / CGA + RR
>HIP      | IPsec ESP     | HIP BE   | ORCHID + RR
>
>Looking at the details, I don't see any fundamental differences in
>encapsulation.  IP tunnelling could be easily used for SHIM6 and HIP,
>too.  Basically, what SHIM6 and HIP provide are optimised tunnelling,
>i.e., headers that are optimised to carry the minimum amount of
>information needed so that the receiving end (ETR in LISP
>terminology) can re-create the original packet.  If tunnelling (with
>all its known drawbacks) is considered to be a better encapsulation
>method that what is currently defined for SHIM6 or HIP, it would be a
>no-brainer to adjust SHIM6 and/or HIP accordingly.
>
>Looking at the protocols, SHIM6 and HIP base exchange carry known
>similarities; the SHIM6 protocol was inspired by HIP.  The biggest
>advances of SHIM6 to HIP are its ability for late binding and lighter
>cryptographic operations.  However, the LHIP proposal provides
>similar properties for HIP too, rendering the fundamental differences
>between SHIM6 and HIP to the ULID formats.  Currently the proposed
>LISP protocol is very simple, but I expect it to grow considerably
>more complex once all the security issues are solved.
>
>So, to me, the biggest differences are in trust models and security.
>That, in turn, are hard to comment in detail at the moment, for two
>reasons:
>
>  1. There is no detailed spec for proxying SHIM6 and/or HIP
>
>  2. The LISP spec is missing the security details
>
>
>Now, based on my earlier work, starting from the late Homeless Mobile
>IPv6 proposal (which was killed due to security considerations),
>through MIPv6 security, HIP, and some aspects of SHIM6 security
>design, my gut feeling is that once security is added to LISP, we end
>up with a very similar design to current SHIM6 and HIP, with a four- 
>way handshake that uses certain cryptographic bindings and return
>routability.  But of course I may be completely wrong here; it may be
>easier to provide security in the network side, at least if you can
>assume S-BGP or similar.  But then, can you assume that such a
>security framework would be there?
>
>Anyway, if I happen to be right in my security gut feeling, I don't
>see any real benefits in LISP w.r.t. to proxied SHIM6 or HIP.  Both
>HIP and SHIM6 are much more mature at the date that LISP.  If/when
>proxying is added to them, they should be able to allow similar
>network-based implementation and TE characteristics that LISP do.
>
>--Pekka Nikander
>
>
>_______________________________________________
>RAM mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ram

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram