Subject: [lisp] possible text for LISP threats

From: Ross Callon <[email-masked]>
Date: Fri, 13 Jun 2014 16:26:31 +0000

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.

---

From: Damien Saucez <[email-masked]>
Date: Fri, 13 Jun 2014 18:53:35 +0200

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 <[email-masked]> wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Ross Callon <[email-masked]>
Date: Fri, 13 Jun 2014 17:38:43 +0000

> ... and I can propose you to write a

What do you propose would be done with this whitepaper? 

Thanks, Ross

-----Original Message-----
From: Damien Saucez [mailto:[email-masked]] 
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,

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Jun 2014 10:54:42 -0700

> 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 ut…

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 th…

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 th…

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 packe…

Ditto.

Thanks,
Dino

---

From: Ross Callon <[email-masked]>
Date: Fri, 13 Jun 2014 18:36:16 +0000

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...

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, Ross

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 13 Jun 2014 12:36:27 -0700

> 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…

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.

> 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

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 16 Jun 2014 17:16:31 +0200

Hi,

I guess that Damien’s point was about the fact that we could find zillions of examples on how to carry out the very same attack.

Whitepaper is an “example” of where those examples can be written, he was not proposing to actually write one.

The threats document is an analysis of LISP-related threats and IMHO should not be transformed in a LISP-hacking 101 guide.

Luigi