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

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

Message-Id: <20140627.001353.840895998677889032.davem@davemloft.net>
Date:	Fri, 27 Jun 2014 00:13:53 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	lojakab@...co.com
Cc:	chris@...icalelegance.com, netdev@...r.kernel.org,
	vermagan@...co.com
Subject: Re: [PATCH V6 net-next] LISP: Locator/Identifier Separation
 Protocol

From: Lori Jakab <lojakab@...co.com>
Date: Fri, 27 Jun 2014 09:19:50 +0300

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

Sorry, I don't buy this.

Still sounds DOS'able to me, you cannot process an infinite amount of
packets backlogged on pending Map Requests, your only choice is to
start dropping packets.

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

I think you misunderstand the problem space.

If you have to lookup on EIDs you have to consider the full 32-bit
value, even if you use a trie.  Therefore you will have to limit
the size of your cache, and trim it when it hits certain thresholds.

Therefore it has the same problems that the routing cache had.

The reason the DoS'ability disappeared with the routing cache removed
is that the remaining datastructures operate on a fixed sized database
which is not influenced by traffic patterns sent by external hosts.

Read that critical component again: "not influenced by traffic
patterns sent by external hosts"

LISP fails that test regardless of the data structures you use, any
external host can influence your cache and how often you have to
create new entries.

That's a bad design and fundamentally exploitable.
--
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