Re: [PATCH V6 net-next] LISP: Locator/Identifier Separation Protocol

[Lori Jakab <lojakab@cisco.com>]

Hi David,

Thanks for reviewing.

Replying inline below on the general points, since I was coordinating 
with Chris on this work. I added LISP support to the Open vSwitch 
out-of-tree kernel module, which we would like to upstream when 
Jesse/Pravin think it's ready.

On 6/24/14, 1:02 AM, David Miller wrote:
> From: Christopher White <chris@logicalelegance.com>
> Date: Fri, 20 Jun 2014 08:26:12 -0700
>
>> This is a static tunnel implementation of LISP as described in RFC 6830:
>>    http://tools.ietf.org/html/rfc6830
>>
>> This driver provides point-to-point LISP dataplane
>> encapsulation/decapsulation for statically configured endpoints. It provides
>> support for IPv4 in IPv4 and IPv6 in IPv4. IPv6 outer headers are not
>> supported yet. Instance ID is supported on a per device basis.
>>
>> This implementation has been tested against LISPMob.
>>
>> Changes from V2: Move some functions to common headers. Remove unecessary skb
>> ownership change. Minor cleanup.
>> Changes from V3: Revert some generic function consolidation for later patches.
>> Changes from V4: Indentation (Note V4 was erroneously marked V3)
>> Changes from V5: Remove extraneous export
>>
>> Signed-off-by: Chris White <chris@logicalelegance.com>
> I'm not so sure if this is how we should start supporting LISP at this
> time.
>
> The whole point is to be able to dynamically map EIDs to RLOCs on demand,
> and this static tunnel neither provides that functionality, nor provides
> generic enough infrastructure to add such a facility easily.

We started this work after LISP was accepted into the out-of-tree Open 
vSwitch (OVS) kernel module, because all tunneling protocols were moved 
out to standalone kernel implementations, and OVS was just hooking into 
those. That’s why we only implemented static tunneling (for now), 
because we only need the encapsulation to be done in the kernel module. 
The dynamic part is intended to be provided by OVS, by means of flow rules.

>
> Furthermore, LISP fundamentally seems quite DOS'able.  What is to keep one
> from having to service a full Map-Request --> Map-Reply cycle for every
> packet received?  Just keep spamming packet after packet through the ITR,
> specifying a unique and different EID in the destination address each time.

Map-Requests can and should be rate limited. Also, if there is no 
mapping for a packet in the map-cache (while we're waiting for a reply), 
it is sent to a Proxy-ETR, a dedicated LISP infrastructure box part of 
the LISP architecture, and gets delivered to the destination.

>
> That's exactly the same kind of problem we had internally with the
> ipv4 routing cache and that's why we totally removed it.

If I understand correctly, the route cache was a hash table with 
multiple keys. We intend to have a trie based look-up table for LISP. 
Additionally, IPv4 routing was and still is a required component for 
every networked host, while LISP will be an optional feature.

Beucause of this, and the reasons in the previous paragraph the 
potential impact of the DoS is quite low IMHO.
>
> Also I wonder if whatever a "properly functioning" (whatever that
> means, given the DOS'ability of it in dynamic configurations) LISP gives
> us is worth the MTU we lose with the encapsulation.

The MTU issue is not unique to LISP. If you want, I can get into details 
of what a “properly functioning” LISP can provide (granted, on the 
control plane side) that other tunneling protocols don’t in a follow-up 
email.

>
> Sorry, I'm not too thrilled about LISP and this patch in particular,
> from several different angles.  And therefore I'm going to mark this
> patch deferred and not apply it at this time.

Let us know what we should improve, and we’ll work on it.

-Lori