All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.