From: Lori Jakab <lojakab@cisco.com>
To: David Miller <davem@davemloft.net>
Cc: chris@logicalelegance.com, netdev@vger.kernel.org, vermagan@cisco.com
Subject: Re: [PATCH V6 net-next] LISP: Locator/Identifier Separation Protocol
Date: Fri, 27 Jun 2014 10:31:57 +0300 [thread overview]
Message-ID: <53AD1DED.3090908@cisco.com> (raw)
In-Reply-To: <20140627.001353.840895998677889032.davem@davemloft.net>
On 6/27/14, 10:13 AM, David Miller wrote:
> From: Lori Jakab <lojakab@cisco.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.
I think I did not explain the concept of the P-ETR very well. It is
like a default route, and you don't backlog packets while you wait on
pending Map-Requests. The impact is that packets sent to the P-ETR take
a detour, but they still get delivered. After the Map-Reply comes in,
packets will take the optimal route. So even with a fixed size cache,
you still don't need to drop 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.
The OVS datapath's flow table is also influenced by traffic patterns
sent by external hosts. But while the IPv4 routing table is not
optional for a networked host, OVS and LISP are, and people deploying
them can still find value using them, in controlled environments at least.
next prev parent reply other threads:[~2014-06-27 7:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-20 15:26 [PATCH V6 net-next] LISP: Locator/Identifier Separation Protocol Christopher White
2014-06-23 22:02 ` David Miller
2014-06-27 6:19 ` Lori Jakab
2014-06-27 7:13 ` David Miller
2014-06-27 7:31 ` Lori Jakab [this message]
2014-06-27 19:28 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53AD1DED.3090908@cisco.com \
--to=lojakab@cisco.com \
--cc=chris@logicalelegance.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=vermagan@cisco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.