[Ila] Scaling mapping systems (was Re: [5gangip] BOF Description)

[Tom Herbert <[e-mail]>]

On Fri, Feb 2, 2018 at 10:37 AM, Dino Farinacci <[e-mail]> wrote:
>
> The question to be answered is if all 10 million need to be stored in one place at the same time.
>
> Lorenzo, do you think the DNS is scaling? And if the mapping system is designed roughly the same way, could it scale?
>
Right, there now are many examples of sharded databases to draw
lessons from. At 10M entries per router, to get to 1B aggregate
mappings in a network that's 100 routers. Assuming a 5x replication
factor then network needs 500 identifier/locator routers. I would
target scaling this by two orders of magnitude within ten years to
accommodate influx of IoT devices and fined grained object addressing
in virtualization. I know this is simplistic math and scaling this is
a hard problem, but I believe it's a solvable problem.

>
> Also, the other point you made about third-party dependency, is a another question about push versus pull style of operation.
>

There is a related question that needs to be addressed and that's
DOSability of a mapping cache.

For instance, from RFC6380:

"6.  The ITR receives the Map-Reply message, parses the message (to
check for format validity), and stores the mapping information from
the packet.  This information is stored in the ITR's EID-to-RLOC
mapping cache.  Note that the map-cache is an on-demand cache.  An ITR
will manage its map-cache in such a way that optimizes for its
resource constraints. "

This on-demand mapping cache is the reason that LISP is not in Linux.
The argument is that it is easily DOSed. A attacker could flood an ITR
with packets to random destinations that would trigger map requests.
If the map requests are rate limited then that could prevent requests
being made for legitimate traffic. If map replies are generated for
the bogus traffic they they could fill up the cache and block out
legitimate users.

I think the the request rate limiting problem can be mitigated by
using a redirect model instead, but I don't have complete answer yet
for the cache exhaustion attack (my patches that would facilitate an
ILA mapping cache we also rejected).

Dino, has this DOS issue been looked at for LISP?

Thanks,
Tom