> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
