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 <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. >> >> 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 lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
