A few snippets (with the rest dropped, at least for this one email)... > Ross you have to be much more precise in your language...
More precision and detail is a good idea. > For the above text, you shoudl say "all ISPs on the path do not do a source > check". When you are looking at "big core ISP" connected to another "big core ISP", my understanding is that source checks are normally not done because it is too hard to know what source IP addresses a very large ISP might legitimately source (other than "all"). Yes, if a very small ISP (say, a single university network) is attacked to a larger ISP (say, a national service provider) then the source check might be done either at the entry from the host to the small ISP, or from the small ISP to the larger ISP. Both would need to be missing for my attack #1 to succeed, at least if the source RLOC's were forged. > You should state where the attacker is. In this case it is not at the LISP > site where you refer to the xTR. That was my intention, so yes it should be stated. I was specifically thinking of the "attacks from elsewhere in the worldwide open Internet" case, which probably should be stated. > You need to say that the attacker is not necessarily at a LISP site Correct... > but its source address will be used by the xTR FOR RETURN TRAFFIC. You need > to make it > clear if the mapping database should return a set of RLOCs or what is > returned is a > negative Map-Reply. I presume the former since you said the attacker uses a > "source EID". I think that you are correct that a bit more detail is appropriate here. However, in my scenario 1 I am concerned about the control plane load of the xTR being forced to send out a lot of map requests, so it is not clear that it matters what the response will be to those map requests. Of course there is also the problem that if the forged source EID's span a large fraction of the full LISP database, then the replies that the xTR receives from its map requests will also span the LISP database and fill the cache. Thus you are correct that more detail would be appropriate here. > I think you should make it clear this is not unique to LISP... > You don't want to mislead people to think LISP is worse in this case. 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. > If the cache is going to be exhausted you need to say that each source EID > chosen > will match a different EID-prefix in the mapping database causing distinct > entries to be created... Correct. >> 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, 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 could be a way to get around source IP address checks (where they are deployed), since the source RLOC would be correct and legitimate. > Thanks, > Dino Thanks, Ross _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
