Subject: Re: [lisp] Need comments on LISP Threats Analysis

From: [email-masked] (Noel Chiappa)
Date: Wed, 20 Mar 2013 14:52:59 -0400 (EDT)

> From: Ronald Bonica <[email-masked]>

    > 3) query the map cache for each packet. If no entry exists, discard the
    > packet and query the map server

    > If you choose Option 3, won't the victim ETR map cache overflow?

We've been over this ground about 18 times, haven't we?

Answer #5: Don't have a fixed-sized cache. Then it cannot overflow.

	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Mar 2013 11:55:36 -0700

> Answer #5: Don't have a fixed-sized cache. Then it cannot overflow.

Yep, you are right Noel.

Just like the BGP RIB does not have a fixed-size cache. So what happens when there is no memory for BGP, ditto for LISP. There is no magic here folks.

Dino

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 Mar 2013 15:02:32 -0400

Well, there are regular reports of folks taking down BGP sessions 
because they exceed the number of prefixes they can handle.
And LISP EIDs are more granular and varied than BGP prefixes usually are.
So it does seem a reasonable question to ask how we will protect 
ourselves against this sort of problem.

It is true that a device with enough local memory for the whole mapping 
table is, by definition, not subject to this kind of attack.  But it 
seems doubtful that we can expect most ITRs or ETRs to have that much 
memory.

One of my concerns with the categorization is that the various practices 
needed to counter different threats are not inherently consistent.  or 
are they always generally applicable.  (Some of them are just plain good 
advice.  Some of them are good advice for internet deployment.  Some are 
good advice for VPN deployments.)   So will the reader be able to tell 
whether he is at risk for a given attack, and what he should be doing 
for his problem space while still keeping an effective and operable LISP 
infrastructure?

Yours,
Joel

---

From: Albert Cabellos <[email-masked]>
Date: Wed, 20 Mar 2013 15:35:06 -0400

I agree that having a fixed cache-size can always result in an overflow, even from legitimate traffic.

Then IMHO we should try to answer two questions:

1) What is legitimate traffic? If any node behind an xTR is legitimate to generate traffic and hence, trigger Map-Requests, then we should stick to the best-effort policy, and when the limited cache-size is overflown drop entries in the map-cache. In this context we have published a paper than analyzes the hit rate vs. the cache-size considering internet-like traffic.

http://personals.ac.upc.edu/acabello/Albert_Cabellos/Publications_files/LISP%20Cache.pdf

2) How can we mitigate such "attacks"? For this, there is a huge amount of literature dealing with cache eviction policies. Besides that, we are also preparing a study on this, for the specific case of LISP and considering Internet-like traffic, I´ll be happy to share it when it´s ready. However I agree that different solutions should be considered for different scenarios. 

Albert
 
On Mar 20, 2013, at 3:02 PM, Joel M. Halpern <[email-masked]> wrote:

> Well, there are regular reports of folks taking down BGP sessions because they exceed the number of prefixes they can handle.
> So it does seem a reasonable question to ask how we will protect ourselves against this sort of problem.
> 
> It is true that a device with enough local memory for the whole mapping table is, by definition, not subject to this kind of attack.  But it seems doubtful that we can expect most ITRs or ETRs to have that much memory.
> 
> One of my concerns with the categorization is that the various practices needed to counter different threats are not inherently consistent.  or are they always generally applicable.  (Some of them are just plain good advice.  Some of them are good advice for internet deployment.  Some are good advice for VPN deployments.)   So will the reader be able to tell whether he is at risk for a given attack, and what he should be doing for his problem space while still keeping an effective and operable LISP infrastructure?
> 
> Yours,
> Joel
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Mar 2013 13:43:52 -0700

Well we have postulated in many designs that if the use of an RTR is in place, that can help with all sorts of state-based scaling issues. We could have ITRs simply point a default or some /4, or /8 EID-prefixes to a set of RTRs that ARE on path.

So the map-cache can have very coarse entries and get everywhere on the network.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 20 Mar 2013 21:30:37 +0000

Joel,

Think that you have hit the nail on the head. So far in our discussion, we have mention a few possible mitigations. These are:

- Option #3, as mentioned in the threats document
- Option #4, as mentioned by Dino
- Option #5, as mentioned by Noel
- possibly an Option #6, as proposed by Dino in http://www.ietf.org/mail-archive/web/lisp/current/msg04417.html

Ideally, we know which option is best in each deployment scenario. If this is the case, we should capture what we know in the threats document. However, it is possible that we aren't in a position to give such concrete guidance, but, as Noel suggests:

"And I don't think there would be any _protocol_ changes needed to deal with such a thing, just implementation changes. And since we don't normally mandate implementation details, why can't we just say 'here's this thing -make sure your implementation deals with it if it happens'.

If so, we should say that in the document. (Naturally, we will need to polish the language before capturing it in a document.)

IMHO, making neither of the statement above leaves the reader with a false sense of understanding (and security).

                                                          Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joel M. Halpern
> Sent: Wednesday, March 20, 2013 3:03 PM
> To: Dino Farinacci
> Cc: Noel Chiappa; [email-masked]
> Subject: Re: [lisp] Need comments on LISP Threats Analysis
> 
> One of my concerns with the categorization is that the various
> practices needed to counter different threats are not inherently
> consistent.  or are they always generally applicable.  (Some of them
> are just plain good advice.  Some of them are good advice for internet
> deployment.  Some are
> for his problem space while still keeping an effective and operable
> LISP infrastructure?
> 
> Yours,
> Joel
> 
> >>> 3) query the map cache for each packet. If no entry exists, discard
> >>> the packet and query the map server
> >>
> > Just like the BGP RIB does not have a fixed-size cache. So what
> happens when there is no memory for BGP, ditto for LISP. There is no
> magic here folks.
> >
> > Dino
> >
> >>
> >> 	Noel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Mar 2013 14:40:05 -0700

> - possibly an Option #6, as proposed by Dino in http://www.ietf.org/mail-archive/web/lisp/current/msg04417.html

And Option 6 is written up in draft-ermagan-lisp-nat-traversal and draft-farinacci-lisp-te. Those are two use-cases for RTRs.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 21 Mar 2013 10:11:37 +0000

Damien,

In order to shed light on the relative merits of Options 1 through 6, you might want to consider the following attack in the threats document.

Modifying the Reference Network slightly, the LISP site at the bottom of the diagram is served by LR3 and LR4 (as it is in Figure 1). Behind LR3 and LR4 are two CPE routers, called CPE1 and CPE2. Behind CPE1 and CPE2 are IPv4 subnets A-Z. Each subnet is numbered from a /24. On average, 25 hosts are attached to each subnet.

An attacker sends a continuous stream of traffic towards the site. The stream is not particularly large, when compared to the aggregate of traffic flowing into the site. However, it does contain over 1K PPS. Each packet contained by the stream is unique, in that it contains:

- a spoofed source address that is selected at random from a pool of valid IPv4 prefixes
- a destination address that is selected at random from subnets A-Z
- protocol and port numbers that are selected at random from a pool of protocol and port numbers that represent applications that are likely to be running at the site

The attack stream can be sourced by either SA, by a host on the global Internet that is connected via a PITR, or by HA, if L1 and L2 don't validate source addresses as they should.

Now assume that LR3 and LR4 allow the stream to pass into the site (Option #1). CPE1 and CPE2 will send an ICMP Destination Unreachable Message in response in response to each packet that is destined for an address to which no host is assigned. The hosts will most likely send an ICMP Port Unreachable message in response to each packet that is actually delivered to the host. Because each ICMP message is destined for a randomly selected, spoofed address, EID-to-RLOC cache thrashing is a real possibility.

Option #5 prevents cache thrashing by sizing the cache appropriately. Option #6 allows LR3 and LR4 to provide continue to serve the site, even in the face of cache thrashing. None of the other options appear to help much.

Do you agree? If so, are Options #5 or #6 required whenever LISP is deployed in an uncontrolled environment (e.g., on the global Internet)?

                                      Ron

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 21 Mar 2013 17:00:46 +0000

Damien,

In a private email, someone pointed out that the attack described below will generate at most 1K ICMP messages per second and that won't be enough to case thrashing. In order to make the attack work, we will need to:

- increase the number of hosts in the site
- increase number of packets per second in the attack flow
- engineer the attack flow so that the majority of packets actually reach hosts and elicit ICMP Port Unreachable messages.

Assuming that it is possible to engineer such an example, are Options #5 and #6 our only mitigation?

                                                      Ron

> From: Ronald Bonica
> Sent: Thursday, March 21, 2013 6:12 AM
> To: 'Joel M. Halpern'; 'Dino Farinacci'; [email-masked]'
> Cc: 'Noel Chiappa'; [email-masked]'
> Subject: Analyzing Options 1 - 6 (was: Need comments on LISP Threats
> Analysis)
> 
> Damien,
> 
> In order to shed light on the relative merits of Options 1 through 6,
> you might want to consider the following attack in the threats
> document.
> 
> Modifying the Reference Network slightly, the LISP site at the bottom
> of the diagram is served by LR3 and LR4 (as it is in Figure 1). Behind
> LR3 and LR4 are two CPE routers, called CPE1 and CPE2. Behind CPE1 and
> CPE2 are IPv4 subnets A-Z. Each subnet is numbered from a /24. On
> average, 25 hosts are attached to each subnet.
> 
> An attacker sends a continuous stream of traffic towards the site. The
> stream is not particularly large, when compared to the aggregate of
> traffic flowing into the site. However, it does contain over 1K PPS.
> Each packet contained by the stream is unique, in that it contains:
> 
> - protocol and port numbers that are selected at random from a pool of
> protocol and port numbers that represent applications that are likely
> to be running at the site
> 
> The attack stream can be sourced by either SA, by a host on the global
> Internet that is connected via a PITR, or by HA, if L1 and L2 don't
> validate source addresses as they should.
> 
> Now assume that LR3 and LR4 allow the stream to pass into the site
> (Option #1). CPE1 and CPE2 will send an ICMP Destination Unreachable
> Message in response in response to each packet that is destined for an
> address to which no host is assigned. The hosts will most likely send
> an ICMP Port Unreachable message in response to each packet that is
> actually delivered to the host. Because each ICMP message is destined
> for a randomly selected, spoofed address, EID-to-RLOC cache thrashing
> is a real possibility.
> 
> Option #5 prevents cache thrashing by sizing the cache appropriately.
> Option #6 allows LR3 and LR4 to provide continue to serve the site,
> even in the face of cache thrashing. None of the other options appear
> to help much.
> 
> Do you agree? If so, are Options #5 or #6 required whenever LISP is
> deployed in an uncontrolled environment (e.g., on the global Internet)?
> 
>                                       Ron

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Mar 2013 10:06:23 -0700

> - increase the number of hosts in the site

But then the bottleneck of the attack is limited to the site's bandwidth to the backbone.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 21 Mar 2013 17:10:45 +0000

Assume that the site is sufficiently well-connected so that the entire attack flow and all of the ICMP responses can get through. 

                      Ron

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Thursday, March 21, 2013 1:06 PM
> To: Ronald Bonica
> Cc: Joel M. Halpern; [email-masked]; Noel Chiappa;
> [email-masked]
> Subject: Re: Analyzing Options 1 - 6 (was: Need comments on LISP
> Threats Analysis)
> 
> > Damien,
> >
> > In a private email, someone pointed out that the attack described
> below will generate at most 1K ICMP messages per second and that won't
> be enough to case thrashing. In order to make the attack work, we will
> need to:
> >
> > - engineer the attack flow so that the majority of packets actually
> reach hosts and elicit ICMP Port Unreachable messages.
> >
> >> An attacker sends a continuous stream of traffic towards the site.
> >> The stream is not particularly large, when compared to the aggregate
> >> of traffic flowing into the site. However, it does contain over 1K
> PPS.
> >> - protocol and port numbers that are selected at random from a pool
> >> of protocol and port numbers that represent applications that are
> >> likely to be running at the site
> >>
> >> The attack stream can be sourced by either SA, by a host on the
> >> global Internet that is connected via a PITR, or by HA, if L1 and L2
> >> don't validate source addresses as they should.
> >>
> >> Message in response in response to each packet that is destined for
> >> an address to which no host is assigned. The hosts will most likely
> >> send an ICMP Port Unreachable message in response to each packet
> that
> >> is actually delivered to the host. Because each ICMP message is
> >> destined for a randomly selected, spoofed address, EID-to-RLOC cache
> >> thrashing is a real possibility.
> >>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Mar 2013 10:15:53 -0700

Understand, but the further we qualify, the harder it will be to launch a real attack. I am not saying it is happening, but just want to be practical.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Fri, 22 Mar 2013 09:09:45 +0100

Dear all,

I will not interact with the mailing list for now to avoid putting
biased in the discussion. As soon as I will see a convergence
to something, I will reflect this in the draft and propose a new
version for revision.

Thank you all  for your contribution.

Damien Saucez