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


The “too …” depends on bandwidth and processing power into and in the 

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.


> On Mar 16, 2018, at 10:58 AM, Tom Herbert <> wrote:
> On Fri, Mar 16, 2018 at 10:38 AM, Dino Farinacci <> 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

lisp mailing list

Reply via email to