> 5.2.4 Examples of DoS attacks > > Suppose that the attacker has a single system that he controls, and that his > ISP does not check the source address of outgoing packets. Suppose gleaning > is turned off (so that gleaning cannot be utilized in the attack):
Ross you have to be much more precise in your language or no one will understand exactly what you are trying to get across. See my comments below. For the above text, you shoudl say "all ISPs on the path do not do a source check". > 1. Attacker could send a lot of packets to one address behind a particular > xTR, each packet with a different You should state where the attacker is. In this case it is not at the LISP site where you refer to the xTR. > source EID. This causes the xTR to do a mapping lookup for each one. This > causes two problems in the xTR: (i) You need to say that the attacker is not necessarily at a LISP site 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". > control plane load (a simple data plane DOS has turned into a control plane > DOS); (ii) potential exhaustion of I think you should make it clear this is not unique to LISP. Because what you refer to as a data-plane DoS means that the hardware can drop packets, where as you know any packet that needs to go to the control plane would result the same way. You don't want to mislead people to think LISP is worse in this case. > the cache. Optionally the attacker could use the same source RLOC for each, > but this could in theory lead to 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. Otherwise, if all the source EIDs come out of a registered coarse prefix, then only one cach entry is used. > 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. > 2. Attacker could send a lot of packets to many remote xTRs, one packet to > each, all with the same source forged EID and source RLOC, with the source > EID and source RLOC being that of the system that he really wants to attack. > This causes each to do the same mapping lookup, which might overwhelm the > mapping system serving the system under attack. This is written well and clear if (1) is written with more detail. > 3. Attacker could send a large number of map requests to many remote xTRs, > all with the same forged source EID and source RLOC, again with the source > EID and source RLOC being that of the system that he really wants to attack. > This causes each to send a map response to the system under attack. This > again would be intended to overwhelm the control plane and cache of the > system under attack. This is written well. Thanks. > Suppose that the attacker controls a moderate sized BOTNET, consisting of a > few thousand captive systems. He might install enough software on his BOT's > to send a packet that looks like a LISP packet. In this case each of the > attacks discussed above can be multiplied by having a wider range of systems > participating in the attack. Ditto. Thanks, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
