Subject: [lisp] uRPF as a possible solution

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Jul 2011 02:13:09 -0700

Sorry for my silence but I have caught up on this really good thread.  
I think everyone is learning from each other as well as being  
challenged. This is goodness.

To mitigate the DoS attack problem on filling up an ITR cache, uRPF  
can be done at these places in the network:

(1) At the ITR
(2) At the PE router connecting the site's ITR to the service provider  
PE
(3) At the ETR
(4) At a firewall router anywhere in the path.

I believe (3) and (4) shared the same disadvantages. Many have  
mentioned doing it at the ETR. It can be done there but it requires  
more work and in my opinion it is done too late in the data path.  
Ditto for a firewall at the destination site.

The best place is (1) and if you have a non-compromised ITR but  
compromised hosts, the ITR will drop packets that come from a spoofed  
EID. Today, if an ITR gets a packet from a source at the site where it  
does not match its EID-prefixes it will forward the packet natively  
because it thinks the packet is coming from an RLOC and going to  
either a non-LISP or LISP site (the destination doesn't matter for  
this discussion). We need to support this because a site might be  
partially converted to LISP so some hosts are assigned EIDs but others  
are not.

When an ITR is configured with "LISP-based uRPF checking", and is a  
fully converted to a LISP site, it can drop packets before ever  
leaving the site. This way an EID-prefix associated with a locator-set  
is consistent for any packets leaving the site. And that mapping is  
the same mapping registered to the mapping database system. The  
destination sites will not have to participate in the solution and  
won't have to do mapping database lookups during decapsulation (and  
therefore don't have to fill their cache up for uRPF reasons).

If we wanted cooperation from the service provider, the PE router  
could look deeper into the packet to verify the source EID in the  
packet is from a customer that owns it. This would require  
configuration of EID-prefixes (in ACLs perhaps) so it may be an OpEx  
burden. But having a PE router modified to look deeper into the packet  
is not much of a concern since the LISP encapsulation header is fixed  
length and the source EID can be found easily.

This is one way to protect remote ITR caches from reflection attacks.

Dino

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 21 Jul 2011 06:26:54 -0400

> (1) At the ITR

I think this presumes that a malicious end-user in the Locator address space
can't simply forge packets and pretend to be an ITR.  It would also rely on
most/all operators of ITRs to configure uRPF or BCP-38 at their site, which
historically has been impossible to achieve for a large enough portion of
the Internet to prevent large spoofed source attacks.

> (2) At the PE router connecting the site's ITR to the service provider PE
>

The PE router may not have routing tables for the given address-family.
 Even if the PE did, to do uRPF on the inner-payload, it would encounter the
same scaling limitations as xTRs.

> (3) At the ETR

How can the ETR do uRPF without also being subject to the same mapping churn
problem as an ITR?  It must have access to enough state information to check
all the packets flowing through it, so if under attack, it must have enough
FIB to install many entries from the MS.

Also another, different, problem is that if an ETR doing uRPF has routinely
20k flow cache entries, because around 20k sites are accessing the
downstream hosts, but suddenly a DoS begins at a high rate, it will take
some time for the FIB to become populated with enough of the address space
for the uRPF checks to be successful on most legitimate traffic arriving
from "new sites."  The reason is, for example, if there are 500k total
mappings possible and the FIB can punt and update at 20k/second, for around
25 seconds an initially high, and then decreasing toward zero, portion of
new flows will be dropped because the limit of punts has been reached.  TCP
will simply retransmit but performance of the downstream hosts will appear
to be affected temporarily.  As more negative entries can be installed to do
the uRPF failures without punting, the rate of successful punts, and mapping
FIB installs, for "good" sources will increase.  This assumes there is
enough FIB.

IMO this has the same scaling limitation as the ETR.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 21 Jul 2011 17:31:29 -0700

> I think this presumes that a malicious end-user in the Locator  
> address space can't simply forge packets and pretend to be an ITR.   
> It would also rely on most/all operators of ITRs to configure uRPF  
> or BCP-38 at their site, which historically has been impossible to  
> achieve for a large enough portion of the Internet to prevent large  
> spoofed source attacks.

No, you build it into the implementation.

> The PE router may not have routing tables for the given address- 
> family.  Even if the PE did, to do uRPF on the inner-payload, it  
> would encounter the same scaling limitations as xTRs.

Right, like I said doing it at the ITR is the best place.

> (3) At the ETR
>
> How can the ETR do uRPF without also being subject to the same  
> mapping churn problem as an ITR?  It must have access to enough  
> state information to check all the packets flowing through it, so if  
> under attack, it must have enough FIB to install many entries from  
> the MS.

I said don't solve the problem here.

> Also another, different, problem is that if an ETR doing uRPF has  
> routinely 20k flow cache entries, because around 20k sites are  
> accessing the downstream hosts, but suddenly a DoS begins at a high  
> rate, it will take some time for the FIB to become populated with  
> enough of the address space for the uRPF checks to be successful on  
> most legitimate traffic arriving from "new sites."  The reason is,  
> for example, if there are 500k total mappings possible and the FIB  
> can punt and update at 20k/second, for around 25 seconds an  
> initially high, and then decreasing toward zero, portion of new  
> flows will be dropped because the limit of punts has been reached.   
> TCP will simply retransmit but performance of the downstream hosts  
> will appear to be affected temporarily.  As more negative entries  
> can be installed to do the uRPF failures without punting, the rate  
> of successful punts, and mapping FIB installs, for "good" sources  
> will increase.  This assumes there is enough FIB.
>

I gave you alternatives and told you that (1) is the best place. So  
you are agreeing with me for (2) through (4).

Dino

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

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 22 Jul 2011 10:28:57 -0400

On Thu, Jul 21, 2011 at 8:31 PM, Dino Farinacci <[email-masked]> wrote:

>> I think this presumes that a malicious end-user in the Locator address
>> space can't simply forge packets and pretend to be an ITR.  It would also
>> rely on most/all operators of ITRs to configure uRPF or BCP-38 at their
>> site, which historically has been impossible to achieve for a large enough
>> portion of the Internet to prevent large spoofed source attacks.
>>
>

How will the ETRs know if packets have come from a "real ITR" that follows
this part of the specification, or if the packets came from malicious hosts
masquerading as ITRs?  It is obvious that an attacker will simply originate
encapsulated packets from machines with native Internet access, so they
appear to come from ITRs, but really come from his tool that does not obey
this rule.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 22 Jul 2011 09:04:07 -0700

> How will the ETRs know if packets have come from a "real ITR" that  
> follows this part of the specification, or if the packets came from  
> malicious hosts masquerading as ITRs?  It is obvious that an  
> attacker will

So we are thinking of putting some data-plane authentication in which  
we can talk about later. This is work in progress and nothing has been  
published yet.

> simply originate encapsulated packets from machines with native  
> Internet access, so they appear to come from ITRs, but really come  
> from his tool that does not obey this rule.

This is where you need a firewall (at the access SP) to do mapping  
database lookups to verify the (source-EID, source-RLOC) binding.

Also, we do have data-plane gleaning in an ETR specified in the spec.  
So the packet could be accepted in an ETR, source-EID and RLOC  
gleaned, and when the SYN-ACK is returned, the map-cache can be  
verified. That way, you put the mapping database lookup in the place  
where it is already being done for other reasons.

This is a tough problem. We will probably discuss this next week.  
Luigi has an agenda slot to discuss LISP related security threats.

Dino

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 22 Jul 2011 12:42:14 -0400

On Fri, Jul 22, 2011 at 12:04 PM, Dino Farinacci <[email-masked]> wrote:

> So we are thinking of putting some data-plane authentication in which we
>> can talk about later. This is work in progress and nothing has been
>> published yet.
>
>
How might this work without the ETR being required to do look-ups in order
to perform the authentication check?

> This is where you need a firewall (at the access SP) to do mapping database
> lookups to verify the (source-EID, source-RLOC) binding.
>

I'm not clear on what you are suggesting.  Certainly it will not be the case
that "native Internet" service providers will gain the ability to peek into
LISP inner-headers and do any kind of check.

> Also, we do have data-plane gleaning in an ETR specified in the spec. So
> the packet could be accepted in an ETR, source-EID and RLOC gleaned, and
> when the SYN-ACK is returned, the map-cache can be verified. That way, you
> put the mapping database lookup in the place where it is already being done
> for other reasons.
>

You are describing a case where the ETR is also the ITR?

---

From: Patrick Frejborg <[email-masked]>
Date: Sun, 24 Jul 2011 11:32:58 +0300

On Fri, Jul 22, 2011 at 7:04 PM, Dino Farinacci <[email-masked]> wrote:
> Also, we do have data-plane gleaning in an ETR specified in the spec. So the
> packet could be accepted in an ETR, source-EID and RLOC gleaned, and when
> the SYN-ACK is returned, the map-cache can be verified. That way, you put
> the mapping database lookup in the place where it is already being done for
> other reasons.
>
> This is a tough problem. We will probably discuss this next week. Luigi has
> an agenda slot to discuss LISP related security threats.
>

Dino,
I don't know if this is an appropriate moment to step forward and say
that this issue can be mitigated if you give up one of the LISP
principles, i.e. no changes to endpoint stacks. If LISP also supports
upgraded stacks then the enterprise have a choice - live with the risk
of a potential DoS attack or mitigate it for the most important
services by upgrading the stack at some endpoints. Of course, both
endpoints of a session needs to be upgraded to mitigate the attack.
By going after the stack we also gain a bunch of new incentives that
enterprises should be interested in.
Have a look at RFC 6306 but the new architecture that I'm thinking of
is best described in
http://www.cs.princeton.edu/research/techreps/TR-885-10
LISP is the first important step towards this kind of architecture -
thus I don't want to lose it.

Patrick

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 24 Jul 2011 11:14:33 -0700

How about a simpler solution where an ITR at a site does not accept any UDP 4341 packets? So when a host that wants to spoof a source-EID with a valid RLOC in the outer header (so the uRPF check succeeds), can be caught by an non-compromised ITR. 

Routers today can do this by uRPFing solely on the EIDs and since the RLOC belongs to the ITR itself, anyone at the site originated a packet with that RLOC will uRPF fail.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 24 Jul 2011 11:22:33 -0700

If people agree with this, we could add text to reflect this extra check.

Dino

---

From: Jeff Wheeler <[email-masked]>
Date: Sun, 24 Jul 2011 21:35:04 -0400

On Sun, Jul 24, 2011 at 2:14 PM, Dino Farinacci <[email-masked]> wrote:

> How about a simpler solution where an ITR at a site does not accept any UDP
> 4341 packets? So when a host that wants to spoof a source-EID with a valid
> RLOC in the outer header (so the uRPF check succeeds), can be caught by an
> non-compromised ITR.
>
> Routers today can do this by uRPFing solely on the EIDs and since the RLOC
> belongs to the ITR itself, anyone at the site originated a packet with that
> RLOC will uRPF fail.
>

I do not understand how this is helpful.  Perhaps you could give an example
of how this would work if the Internet were in a transition state, with both
many LISP sites, and many "legacy" sites?

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 25 Jul 2011 10:39:13 +0300

On Mon, Jul 25, 2011 at 4:35 AM, Jeff Wheeler <[email-masked]> wrote:
>> How about a simpler solution where an ITR at a site does not accept any
>> UDP 4341 packets? So when a host that wants to spoof a source-EID with a
>> valid RLOC in the outer header (so the uRPF check succeeds), can be caught
>> by an non-compromised ITR.
>>

Me either.

The only way (except from going after the stack) I see to get around
this is to have the following:
- have ETR and ITR in the same box (xTR).
- ETR is not doing uRPF but it inspect the incoming SYN-packets and
pre-select mappings for the ITR so that ITR is "warned" when
ACK-packtes are returned from the server
- the mapping database has to be installed locally at the xTR, because
the time of the reply from the mapping system must be shorter than it
takes for the SYN packet to become an ACK packet. If not, then the xTR
needs to store the packet in memory (which is expensive at higher
speeds) or drop it but we have to assume that valid traffic have
already been dropped or delayed at the ingress ITR. So doing that a
second time is not helpful. Also the mapping system must always
respond promptly to an ITR, if there are several ITRs using the same
server how to ensure that an ITR under attack gets priority so that
the mapping requests are further delayed (apart from the light of
speed issue).
- make sure that the punting resources are higher than the bandwidth
capacity at the xTR.

Then if LISP gets widely deployed there is the botnet issue with
clients at dispersed EID prefixes, these will not be caught by a uRPF
filter but they could generate a lot of cache entries depending on how
many +/- mappings each EID prefix provides.

Patrick

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Jul 2011 06:12:26 -0700

>> many LISP sites, and many "legacy" sites?

I was focusing one case at the moment. That was the one that Jeff brought up. It was a compromised host in a LISP site with non-compromised ITRs. This case can be solved.

For your reference to "transition state", there isn't this same issue on a PITR because it receives and forwards packets from non-LISP sites, where there is one IP header in the packet, and the source address is subject to uRPF and forwarding rules as it is today.

> - have ETR and ITR in the same box (xTR).

For which case, can you be specific please?

> ACK-packtes are returned from the server

Let's be careful how you use the term uRPF in context to LISP. Let's keep the definition as the current definition. Let's refer to an ETR doing a mapping database lookup to verify the source locator and the source EID are in sync to be "binding verification".

The ETR can do binding verification when it decapsulates packets. It doesn't matter what type of packet it is and it doesn't have to be an ITR to do this and it doesn't have to correlate with any other cross packet state.

I am not suggesting this is the best way. We are just discussing options.

> already been dropped or delayed at the ingress ITR. So doing that a

Right, so you have some hard decisions to make. The ETR can do lookup in its cache to figure out if the (source-RLOC, source-EID) is in its cache and if not, drop the packet, then do a lookup so subsequent packets can have the cache populated so the check can pass.

I would prefer to not propose this solution. I'd rather try to solve on the ITR and make the solution closer to the source.

> the mapping requests are further delayed (apart from the light of

Agree, but these issues are no different than what we see in the DNS today. It is too hard and won't scale to differentiate and if anyone tries to figure a solution to this bit, it probably can't work.

I call this the "needle in the haystack" problem. And we have had to deal with this with hardware packet punting for a number of decades.

> - make sure that the punting resources are higher than the bandwidth

Yep.

> many +/- mappings each EID prefix provides.

That is why you solve it at the encapsulator end of this so you don't have to query the mapping database *for your own EID-prefixes*. The ITR has all the information it needs locally to determine to pass a packet from a source or not.

Dino

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 25 Jul 2011 13:41:09 -0400

> For your reference to "transition state", there isn't this same issue on a PITR because it receives and forwards packets from non-LISP sites, where there is one IP header in the packet, and the sou…

The reason I mention "transition state" is you seem to be gravitating
towards ideas that require new inspection capabilities at
substantially all "legacy Internet" access providers in order to
protect the new LISP infrastructure.  If I can use any source IP
address I want when sending crafted packets, including crafted LISP
outer-header, to your LISP site, then the chances are good that I can
disable your site as long as I can generate enough PPS and there are
enough mappings in the system to produce cache churn in your xTR.

So relying on ITRs to prevent "bad traffic" from ever entering the
system will not work because there will be a large, legacy Internet
with no ability to prevent that traffic from reaching your site.

> Right, so you have some hard decisions to make. The ETR can do lookup in its cache to figure out if the (source-RLOC, source-EID) is in its cache and if not, drop the packet, then do a lookup so su…

Except the ETR is bounded by the same cache scaling limits as an ITR
subject to a reflection attack, meaning its cache can churn, and
substantially all traffic needing to be decapsulated by that ETR would
be dropped.

> I call this the "needle in the haystack" problem. And we have had to deal with this with hardware packet punting for a number of decades.

Even if you imagine that the xTR control-plane is not a bottleneck,
presuming that the data-plane can generate MS queries directly and can
update its FIB at an unlimited rate, the result of having a limited
FIB size plus an attack designed to take advantage of that means the
MS infrastructure will be required to have very low latency and very
high throughput to keep up with an xTR experiencing high PPS and low
cache hit rate because of churn.  This essentially would mean that the
MS infrastructure is directly involved in a substantial fraction of
packet forwarding decisions on that xTR.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Jul 2011 11:03:28 -0700

> with no ability to prevent that traffic from reaching your site.

How many times do I have to say we should not solve this on the ETR?

> substantially all traffic needing to be decapsulated by that ETR would

Right, agree. Don't do this on the ETR. DO NOT SOLVE THIS ON THE ETR.

> presuming that the data-plane can generate MS queries directly and can

Why do you want to presume that?

> packet forwarding decisions on that xTR.

That doesn't follow at all and I don't know why you want to make this conclusion.

Dino

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 25 Jul 2011 15:20:46 -0400

> Why do you want to presume that?

To demonstrate that this is not simply a control-plane bottleneck.

> That doesn't follow at all and I don't know why you want to make this conclusion.

It is correct.  If the xTR does not have the necessary state to
forward a packet, it must communicate with the MS infrastructure.  As
cache hit rate goes down, direct MS involvement in forwarding
operations goes up.  The MS does not see the packet itself, but it
must perform work for each miss.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Jul 2011 12:26:10 -0700

> must perform work for each miss.

Darrel has already mentioned that the ITR can "forward-on-cache-miss" by default if the implementation wants to protect its cache.

Dino

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 25 Jul 2011 15:39:46 -0400

> Darrel has already mentioned that the ITR can "forward-on-cache-miss" by default if the implementation wants to protect its cache.

How can these packets arrive at their destination?

---

From: Damien Saucez <[email-masked]>
Date: Mon, 25 Jul 2011 15:40:47 -0400

> How can these packets arrive at their destination?
PITR

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Jul 2011 12:42:58 -0700

> How can these packets arrive at their destination?

If destined to non-LISP sites, they go natively, just like they would in a router today. If destined for LISP sites and sent natively because you don't want to store the locator-set for the site (due to the cache filling up), they go natively and will hit the closest PITR which will encapsulate to the destination LISP site.

Dino

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 25 Jul 2011 23:24:21 +0300

> For which case, can you be specific please?

Hope I don't mess up the discussion but here are my inputs and think
their aligned with Jeff's.

First I'm discussing the case when a fake ITR (or several fake ITRs)
sends bogus LISP packets to a selected ETR

> I am not suggesting this is the best way. We are just discussing options.

Yes, agree - the fake ITR sends bogus packets to the selected ETR and
that ETR is not applying "binding verification" but instead it does a
preview at the packet so that it can inform the ITR of the forthcoming
returning packets from the destination EID. ITR and ETR resides in the
same box, this feature suggestion is there to buy some time for ITR so
it is prepared for what is going to come.
I think you had some ideas in this direction but it could be a
misinterpretation...

> I would prefer to not propose this solution. I'd rather try to solve on the ITR and make the solution closer to the source.

Me either, no cache and mapping functionality at the ETR but instead
have a quick look at the incoming packets so that ITR doesn't have to
fetch the information from a very slow memory (e.g. hard disk).
Assumption here is that there is a local database at the ITR - but
that is not the case in current I-Ds, this is an option but it has
other problems...

> Agree, but these issues are no different than what we see in the DNS today. It is too hard and won't scale to differentiate and if anyone tries to figure a solution to this bit, it probably can't w…

There is a huge difference between a DNS and a MS lookup, DNS is not
in the forwarding plane at all but to build forwarding plane in LISP
you need to ask the MS on how to build it - the forwarding plane is
not prepared in advance. And if the MS system is fair away or can't
reply to the requests at the same pace as the bogus ITR sends packets
to a targeted ETR, then the ITR (that is handling the returning
packets on behalf of the targeted ETR) can't establish forwarding
plane in time.

> That is why you solve it at the encapsulator end of this so you don't have to query the mapping database *for your own EID-prefixes*. The ITR has all the information it needs locally to determine t…

For the first case, i.e. an attacker using a fake ITR - the attacker
owning the fake ITR(s) will not do that :-)

The second case is far in the future, LISP has been deployed and well
established. Imagine if you have 200 000 botnet clients, each client
is attached to their dedicated EID prefix and each client generates
1-10 +/- mappings  per EID prefix. Now the botnet admin decides that a
EID site will be attacked, he triggers a timestamped HTTP request to
that EID site, a SYN goes out at the very same seconds from 200 000
botnet clients. No fake source/destination are used, all EIDs are
legal and they don't get caught by uRPF. But the ITR (handling the
ACKs from the attacked EID site) has to create somewhere between 200
000 to 2 millions cache entries at a pace that depends on how powerful
server/servers are used to generate the 200 000 ACKs. And if there is
no local database at the ITR (that is handling the ACKs) it has to
consult the MS, resolve each entry and that will take some time. And
if the cache size is limited, you need adjust the timers and flush the
cache more often, but then the attacker can do this trick more often.
After a while, when there is analyzed data, you could create a
blacklist at the ITR (that is handling the returning ACKs). The
numbers used here are taken from nowhere, I had to use some numbers to
explain the possible scenario that could happen in the future.

Patrick

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 25 Jul 2011 16:24:34 -0400

> If destined to non-LISP sites, they go natively, just like they would in a router today. If destined for LISP sites and sent natively because you don't want to store the locator-set for the site (d…

But the PITR is subject to the same scaling limitations.  The problem
is unchanged.  The only difference in the case of the PITR is it can
be responsible for less than the entire destination address space; but
an ITR could also be implemented that way.

---

From: Damien Saucez <[email-masked]>
Date: Mon, 25 Jul 2011 17:58:30 -0400

> If destined to non-LISP sites, they go natively, just like they would in a router today. If destined for LISP sites and sent natively because you don't want to store the locator-set for the site (d…

If you are using ALT, you can also imagine that the PITR will "pre-fetch" the
EID mappings for "all" the EID prefixes announced on the ALT. You thus
have mappings for "all" the potential EID. For this kind of PITR, the only
limit is the price of the box, but you can have distribution or hierarchy of
such PITRs: a CDN of PITR :-D

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Jul 2011 15:02:17 -0700

> other problems…

It is described or else the ITR does not know how to set locator-status-bits.

> you need to ask the MS on how to build it - the forwarding plane is

There is not a huge difference, the rate of incoming requests is what is the difference. And if data-plane induced Map-Requests are rate-limited to the same rate a control-plane protocol, like DNS, is being used, it is exactly the same.

> reply to the requests at the same pace as the bogus ITR sends packets

The draft talks about how to pace. And if a DNS server can't reply because of the 1,000,000 requests coming to it from 1,000,000 places, you won't get your TCP connection established too.

> owning the fake ITR(s) will not do that :-)

And you can't stop me bombarding your home router with packets. There are some solutions that can help some situations but you are not going to find a silver bullet.

> 1-10 +/- mappings  per EID prefix. Now the botnet admin decides that a

What does that mean? Each EID-prefix is one mapping so what are you saying "10 per EID-prefix".

> botnet clients. No fake source/destination are used, all EIDs are

What makes you think 200,000 requests will hit the same map-server and ETR at the same time? 

If you frame a problem to your advantage, all my answer is going to be is "packets will get dropped". And that is goodness. If we rate-limite, 200 botnets will get map-replies and 10% of good clients will get service.

It is not LISP that causes this problem, it is the rate the ETR can receive and process packets. 

> 000 to 2 millions cache entries at a pace that depends on how powerful

So the xTR can handle 200,000 incoming requests but can't cache 2 million entries? How does that exactly work?

> no local database at the ITR (that is handling the ACKs) it has to

I am not following, you logic is not making any sense.

> cache more often, but then the attacker can do this trick more often.

Who says you should flush the cache.

> explain the possible scenario that could happen in the future.

No, no, no. I don't know where to start to reply to this. I can't actually because I don't understand the sequence and believe it contradicts itself.

Dino

---

From: Darrel Lewis <[email-masked]>
Date: Tue, 26 Jul 2011 07:44:49 -0700

> How can these packets arrive at their destination?

If they were destined non-LISP, they will get there like normal. (forward would have been your action anyway)

If they were destined to LISP, they might end up on a PITR some where that already has a mapping, and then delivered to a destination ETR.

-Darrel

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 26 Jul 2011 17:52:11 +0300

> No, no, no. I don't know where to start to reply to this. I can't actually because I don't understand the sequence and believe it contradicts itself.

I'll start over and skip the first case, and trying to simplify my
questions/concerns in parts. Let me first describe the environment to
check that I have understood LISP correctly.

We are in the future and LISP has been deployed. There are residences
that have IPv6 in their local networks but the DFZ is still only using
IPv4, then there is one content site (providing IPv6 based services)
that the residences are reaching by using LISP. The packet flow goes
as following (jump in where I get lost):

The ITR at the residence (hereafter called rITR) receives a packet
from the local network, there is no entry in the cache for the
destination and thus it consults the MS. The rITR receives a reply
from MS, creates the cache entry and adds the LISP header to the
packet and the encapsulated packet is routed to the ETR of the content
site (cETR). The cETR removes the LISP header and the packet is routed
to the server of the content site.

Since this is a valid connection, the server replies and the packet is
routed to the ITR of the content site (cITR),  No cache entry exists,
thus the cITR is consulting the MS, a reply is received, a cache entry
is created at the cITR and the returning packet gets encapsulated and
routed over DFZ to the ETR taking care of the residence (rETR). The
rETR removes the LISP header and the session is established.

If I got it so far right, we can proceed to the next step - if not, stop reading

There is an event - there are about 200 000 residences behind rITRs
(no residence shares an rITR) that want to buy a ticket from the
content site at a certain day and time. Thus these residences logs
into the server at the content site slightly before the ticket sale
begins.

For DNS and rITR lookup at MS there are no issues, the distributed DNS
cache architecture prevents that authoritative DNS server doesn't get
all requests - and I guess that is similar for the MS.

No issues exists at the cETR either.

But for the returning packets at the cITR I have _questions_.

For returning packets there is no need to do DNS lookups but if I have
understood LISP correctly the cITR needs to do MS lookups so that
returning packets gets routed back to the residences. If the cITR uses
only one MS server there will be intensive traffic between the cITR
and the MS server - and I think the cache mechanism used in DNS can
not be applied here, right??

Also the MS server and cITR aren't necessary located in the same
premises, the round trip delay between cITR and MS most likely will
have an impact on the time it takes to build 200 000 new cache
entries. And if the MS provider has installed a bad performing MS
server then that will further have an impact on how fast the cITR's
cache is built. The status of my forwarding plane is no longer solely
in my hands. The major difference with today's architecture is that
there is no need to do a lookup in DNS for returning traffic, thus we
cannot completely compare DNS and MS scalability - I think there is a
new pattern in MS that doesn't exist in DNS, but I might have it
wrong.

If the cITR cache doesn't scale enough and I would prefer to add a
second cITR (instead of using the PITR) to deal locally with my cache
issues. How do I ensure that the returning packets are routed to the
correct cITRs? No changes is applied on the server stack and thus
there is a 0/0 route at the server pointing to one next-hop. Should I
install a server load balancer in front of the two cITRs to fix this?

Patrick