netdev - Re: Time to revisit LISP?

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 3 Nov 2016 13:57:59 -0700
From:   Tom Herbert <tom@...bertland.com>
To:     David Miller <davem@...emloft.net>
Cc:     chris@...icalelegance.com,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Time to revisit LISP?

On Thu, Nov 3, 2016 at 1:37 PM, David Miller <davem@...emloft.net> wrote:
> From: Tom Herbert <tom@...bertland.com>
> Date: Thu, 3 Nov 2016 12:22:52 -0700
>
>> For instance, one of the his questions is:
>>
>> "What is to keep one from having to service a full Map-Request -->
>> Map-Reply cycle for every packet received?"
>>
>> This can be solved by judicious rate limiting, for instance the
>> infrastructure I implemented to rate limit ILA resolver request could
>> be applied here.
>
> All of these things work great if you have tables that are either very
> tiny or change infrequently.
>
> But once you run into anything seriously dynamic, it has the same
> problems that the routing cache had and OVS can have.
>
One way or another we are going to have to deal with this. If we want
Linux to be serve as router for mobility it is going to have to scale
for having bunches of host routes and they will be quite dynamic
because of mobility.

> And for this reason things like the flow cache are on the chopping
> block.  And frankly, I'd remove OVS from the kernel if I could.
>
Quite frankly the DOS issues with OVS were obvious just by looking at
the initial design-- it should have been done better. Yes, if you
upcall every unresolved packet to userspace you're just inviting a DOS
attack.

> Userspace resolution of paths in response to data path signalling
> simply does not scale and is fundamentally an extremely poor design
> choice.  We're trying to move away from, rather than towards, these
> kinds of architectures.

OVS is quite different I think. LISP is a specific resolution protocol
of identifier to locator as opposed to be some open ended mechanism to
resolve some arbitrary definition of flows like OVS. Also, I don't
think there's any specific requirement in LISP that prevents on from
implementing the mapping protocol in the kernel, it should just be a
simple UDP communication.

Do you see anything in the protocol itself that would be a showstopper?

Tom