[lisp] possible text for LISP threats

[Ross Callon <[e-mail]>]

We have had significant discussion of attacks against the control plane of routers, and some discussion of the relative capacity of the control plane versus data plane. I have been thinking that the LISP threats document should give examples of DoS attacks against the control plane of the xTR's. If this will help with progression of the document, some possible text is below. I am not sure if this is complete but it might be a start. 

It is not completely obvious where this text would best fit into the existing document, and my understanding is that some restructuring of the document is underway. Perhaps as new subsection(s) at the end of section 5.2 (Denial of Service) of the existing document might be appropriate. I have written the text below as two subsections 5.2.3 and 5.2.4 of section 5.2, but of course there are other ways that this could be incorporated into the threats document. 

Thanks, Ross
------------

5.2.3 Control Plane versus Data Plane DOS attacks

In some cases, particularly very high speed routers, there may be a very large difference between the capacity of the data plane versus the control plane. For example, at the time this is written there are widely deployed routers which can handle a few terabits of data in the data plane. These routers might typically have gigabit Ethernet links to the control processor, but it is unlikely that they could handle Map-Requests coming in at line rate at a gigabit. Thus in some routers (particularly very high speed ones) the ratio between the speed of the control plane and the speed of the data plane may be significantly greater than 1,000.

This implies that DoS attacks against the control plane of routers may be more serious than DOS attacks which only target the data plane. LISP allows data plane traffic to impact the control plane. Examples are included in the following section. 

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): 

1. Attacker could send a lot of packets to one address behind a particular xTR, each packet with a different source EID. This causes the xTR to do a mapping lookup for each one. This causes two problems in the xTR: (i) control plane load (a simple data plane DOS has turned into a control plane DOS); (ii) potential exhaustion of the cache. 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. 

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. 

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. 

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.