Re: [lisp] [Ila] LISP for ILA

[Dino Farinacci <[e-mail]>]

Sorry about that but I did say from the Map-Resolver perspective. That is, the node that receives Map-Requests from good acting ITRs/RTRs as well as bad actors. “You” are the good and bad actors where we can’t tell one from the other (other than good actors follow the spec in rate-limiting the Map-Requests they send).

Better?

The “too …” depends on bandwidth and processing power into and in the map-resolver. 

No normative description yet. Just ideas that I have been talking to people about. Dave Meyer has thought about this and how ML can help tell us when we have deviated from a baseline of “normal behavior”. So we can go into frequency-hopping mode when we deviate by %x.

Dino 

> On Mar 16, 2018, at 10:58 AM, Tom Herbert <[e-mail]> wrote:
> 
> On Fri, Mar 16, 2018 at 10:38 AM, Dino Farinacci <[e-mail]> wrote:
>>> Attackers don't typically set the evil bit in packets and will
>>> otherwise try to make their packets indistiguishable from legitimate
>>> traffic. Can you provide a reference to a specific solution with an
>>> algorithm that is able separate the bad packets from the good packets
>>> wrt the cache.
>> 
>> All you can really do to solve this problem is (from the perspective of a LISP Map-Resolver):
>> 
>> (1) You sent a request for an EID too often, I’m dropping future requets from you.
>> 
>> (2) You sent a request for any EID too often, I’m dropping future requests from you.
>> 
>> (3) I am getting too many requests for an EID from many sources, start dropping them.
>> 
>> (4) I am getting too many requests on this specific map-resolver address, I’m going to deconfigure it. If its an anycast-address, the requests will start going to the next closest map-resolver.
>> 
>> (5) I am getting too many requests on this specific map-resolver address, I’m going to deconfigure it. If it is not an anycast-address, packets are dropped by my penultimate hop. Good actors know other map-resolvers to send to, to get their requests resolved.
>> 
>> (6) Do (4) and (5) by withdrawing the route from BGP. So the high-rate of requests get dropped closer to the bad actors.
>> 
>> In (4)-(6), I have referred to this as “solving DoS attacks with frequency-hopping techniques”. And I was thinking of doing it *with no signalling*. So good actors have to be robust to send to other map-resolvers, either serially or in parallel.
>> 
>> Comments?
>> 
> Dino,
> 
> I'm pretty confused by who "I" is, who "you" is, as well as what
> constitutes "too often" or "too many requests". Is there a normative
> descirption of this algorithm we can look at?
> 
> Thanks,
> Tom
> 
>> Dino
>> 
>> 
>> 
>>