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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Jun 2014 09:19:50 +0300
From:	Lori Jakab <lojakab@...co.com>
To:	David Miller <davem@...emloft.net>, chris@...icalelegance.com
CC:	netdev@...r.kernel.org, vermagan@...co.com
Subject: Re: [PATCH V6 net-next] LISP: Locator/Identifier Separation Protocol

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@...icalelegance.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@...icalelegance.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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html