> For the host to which the attack packets are destined, I don't think that > LISP is worse in this case. However, it is not the effect on a host that I am > concerned about. If the xTR serving that host in this case is either a CE > router or a PE router, then this is a lot worse for the xTR, since the attack > packets cause a reaction in its control plane. Of course if the effect of the > attack is to fill the cache, then again LISP is worse since "non-LISP > Internet operation" doesn't have a cache. I understand that we are not > planning to describe solutions in this text, but if rate limiting of map > requests is considered to be normal practice, I wonder if it would be worth > mentioning that rate limiting could prevent overload of the xTR's control > plane, but that in this case the attack could prevent map requests in support > of legitimate users.
I beg to differ, because what you refer to a cache makes assumptions that it is finite size. A BGP RIB is finite size as well. And even a legit BGP peer can fill up a finite size RIB. So it is my claim that LISP is no worse. > the attacked xTR noticing and putting in a packet filter for that source RLOC, >>> so that varying the source RLOC may make this attack more difficult to >>> counter. >> >> You shouldn't say how the xTR would handle this or else, yes, it will get >> worse. >> Because if you choose a faulty solution, you will introduce more issues. > > I am fine with dropping the sentence stating "Optionally the attacker could > use the same source RLOC for each, but this could in theory lead to the > attacked xTR noticing and putting in a packet filter for that source RLOC, I wouldn't put in a packet filter or else the real RLOC is denied service by the attacked xTR itself. > so that varying the source RLOC may make this attack more difficult to > counter". However, I do wonder, what would happen if a single attacker sent a > large number of packets which look like LISP packets with the same RLOC for > all (perhaps the legitimate RLOC of the attacker) but with different EID's, > each EID chosen from a different EID block. Would the xTR receiving all of > these incoming packets send a map request for each EID? This is what Ron brought up. > This could be a way to get around source IP address checks (where they are > deployed), since the source RLOC would be correct and legitimate. Right, understand. It all comes down to the (source-EID, source-RLOC)-tuple needs to be authenticated to be the legitimate source. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
