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

[Dino Farinacci <[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.

I think so too and has been an effort of mine for many years. And something I requested and wanted IDEAs to tackle.

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

You mean RFC6830. And what you are commenting on below is the map-cache and not the global mapping system. That is the point I want to get Lorenzo’s opinion about.

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

Right, I realize that. But that is not for architectural design reasons. It’s for Linux implementors idealist reasons. And that is okay.

> The argument is that it is easily DOSed. A attacker could flood an ITR

And I have said dozens (probably more) that a “cache" and a “table” is not different. And you think a “BGP table” cannot be DoSed either?

Having said that, I just don’t want to say everything sucks, so I want to give you a proactive response.

Just like you use white-lists for push based routing protocols (which doesn’t include the link-state protocols), you can use rate-limiting an white-lists for cache population. 

And in 90% of the cases, most ITRs will have default map-cache entries with I’d say on a larger scale deployment pointing to 4 to 8 RLOCs. Those RLOCs go to RTRs that are larger such products to deal with this.

Please note that carrier grade NATs are cached based systems to. Why would they ever get deployed?

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

Right, I have heard the argument many times. But if you didn’t have a cache, you wouldn’t flee from the problem. And having a cache will allow you to scale better by storing the state in need where you and when you need it.

Geoff Huston showed a decade ago that only 10% of the routes are being used in, at that time, a 500,000 route entry routing table. This was in big core routers in big ISPs at the time. I wonder what the number is now.

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

Yes, over and over again and has been solved in many ways. RTRs are the current solution as long as NATs are being used and packets need to be encapsulated in IPv4 RLOCs for whatever reason.

RTRs also have the benefit for updating less places for EID mobility. Here is a quick example. Say 1000 EIDs are talking to my LISP based Macbook EID. I’m sitting in a coffee shop behind a coffee shop resident NAT. Those 1000 ITRs have my EID cached with the RTR’s RLOC. The RTR is the only node that can get packets through the coffee-shop NAT. So its map-cache has my EID cached with the tranlsated RLOC. When I move to another coffee-shop my translated RLOC changes, so only the 1 RTR needs updating versus the 1000 ITRs that are talking to me.

RTRs are also useful for traffic-engineering and multicast replication. See draft-ietf-lisp-te and draft-ietf-lisp-signal-free-multicast for details.

That is the indirection you may be referring to. Please correct if I got that wrong.

Dino