Re: [lisp] possible text for LISP threats

[Ross Callon <[e-mail]>]

> ... and I can propose you to write a
> whitepaper with examples of attacks, and in each example showing to
> which part of the abstraction of the threats document they refer.

What do you propose would be done with this whitepaper? 

Thanks, Ross

-----Original Message-----
From: Damien Saucez [mailto:[e-mail]] 
Sent: Friday, June 13, 2014 12:54 PM
To: Ross Callon
Cc: Luigi Iannone; Olivier Bonaventure; LISP mailing list list
Subject: Re: [lisp] possible text for LISP threats

Hello Ross,

Thank you for the input.  Indeed we are working on the new version of
the draft that will arrive for the cut-off date and hence for a big (huge?)
discussion at IETF. 90 

For the moment, I am compiling all the comments and examples given on
the list to construct the most compact abstraction that covers everything.

To avoid delaying the document any longer and hence the working group,
I however think that we should not provide any example of attack in
the draft but instead provide the most compact abstraction of attacks
that permits to reconstruct any possible attack.  Why?  Because if we
open the Pandora box of putting examples in the document, then we will
never be able to close the document as it will always be possible to
add an example even though these example would not add any information
to the system.  Another reason is that providing a 100 pages document
would make it useless as the potential readers would get lost while
reading which is not the case if the document is synthetic but still
complete.  Hence all the work we are doing for the moment is to
construct the right abstraction so that any possible attack can really
be casted into something in the document.

Nevertheless, we all value examples, and I can propose you to write a
whitepaper with examples of attacks, and in each example showing to
which part of the abstraction of the threats document they refer.

So as you can understand with this vision the challenge is to make the
right abstraction.

What do you think of all this?

Damien Saucez 

On 13 Jun 2014, at 18:26, Ross Callon <[e-mail]> wrote:

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