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
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 <t...@quantonium.net> wrote:
> On Fri, Mar 16, 2018 at 10:38 AM, Dino Farinacci <farina...@gmail.com> 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.
> 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?
lisp mailing list