Subject: [lisp] Restarting last call on LISP threats

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 May 2014 11:53:55 -0400

Sorry for the delay getting this out.
This email starts a new (and hopefully final) last call on 
draft-ietf-lisp-threats, version 9:
http://datatracker.ietf.org/doc/draft-ietf-lisp-threats/

The last call will end in two weeks, close of business 23-May-2014.

Thank you,
Joel

---

From: Ross Callon <[email-masked]>
Date: Mon, 12 May 2014 17:11:23 +0000

Thanks Joel;

I think that draft-ietf-lisp-threats-09.txt is a start towards a threats document, but that it has serious omissions and needs more work before being progressed. Here are some specific comments: 

Section 2 (On-path Attackers), first paragraph: 

   On-path attackers are attackers that are able to capture and modify
   all the packets exchanged between an Ingress Tunnel Router (ITR) and
   an Egress Tunnel Router (ETR).  To cope with such an attacker,
   cryptographic techniques such as those used by IPSec ([RFC4301]) are
   required.  As with IP, LISP relies on higher layer cryptography to
   secure packet payloads from on path attacks, so this document does
   not consider on-path attackers.

To me an on-path attacker is one which is on the data path. Such an attacker might attack the contents of the data packet. In this case the paragraph seems mostly correct to me: You encrypt the contents if you don't want someone on the path to the destination to look at the contents. However, as is discussed later in the document, LISP allows systems which are not in the normal physical path, through a gleaning attack, to inject themselves into the data path. This could be applied to allow attacker's systems to inject themselves into the path of the key management protocol. This implies that a legitimate user could get keys supplied by an attacker, just as easily as it could get keys supplied by a legitimate Internet site. If you are proposing that end to end encryption is the solution to on path attackers then you need to understand the implications of LISP on the operation of the protocol needed for key management to support end to end encryption. 

Also, you should mention in this section that a gleaning attack would allow at least in the short term for an attacker to become temporarily on-path even if they are not on what should be the normal path to the destination. 

An on-path attacker might choose to only change something about the LISP handling details, such as exploding the map cache or redirecting a user to a different site. Some of this is mentioned later in the document. One thing that is not mentioned: Suppose that the encapsulated packet is encrypted. The on-path attacker could however see the LISP header, and thus could change the nonce, or add a nonce, or reply to the nonce, change versioning information,...  Are you proposing that the LISP header be encrypted also? If so, where is this specified and what does it do to forwarding performance in the xTR? 

Section 4.3.1, second paragraph, third sentence: 

   This is not different from today's
   Internet where a spoofing off-path attacker may inject data packets
   in any flow.

In terms of injecting traffic that the end system receives and acts upon, I believe that this sentence is entirely true. However, in terms of the effect on the router's control plane, and particularly the operation of xTR's, this sentence is not true. Today there is very little that a spoofing attacker that is outside of a particular service provider can do to exercise the control plane of that provider's routers. This is important and intentional (see DOS discussion below). 

Minor nit, next sentence:

   A non-spoofing off-path attacker (NSA)...

Given recent events, I think that "NSA" is an unfortunate acronym to use here. How about NSOA? 

Section 4.3.1.1 (Gleaning Attacks), last paragraph:

   By itself, an attack made solely using gleaning cannot last long,
   however it should be noted that with current network capacities, a
   large amount of packets might be exchanged during even a small
   fraction of time.

The amount of damage that might be caused by this may depend upon what happens to be exchanged in that "short amount of time". For example, the initial handshake between sites (at the application layer) could include sign in information (account names and passwords), on the basis that this is the sort of information that needs to be exchanged at the beginning of, for example, financial transactions. My understanding is that for Internet commerce, it is normal for users to be redirected to a different site to enter credit card information. This appears to constitute a "new session" (or at least may be to an entirely different location) and therefore the entire credit card exchange could occur in a small period of time. I think it would be worth mentioning here that the sensitivity of the information that could be exchanged during this "short amount of time" is not known, and could potentially be serious. 

Also, depending upon how long xTR's are willing to store gleaned information (before the map request comes back), the time that a user is misdirected due to a gleaning attack might be extended by coordinating a DDOS attack with the gleaning attack. For example, an attacker may send packets to a very large number of sites, with a source EID which is from a major stock broker or bank and an RLOC from the attacker's captive servers. The many sites glean the EID to RLOC mapping from the arriving packets. Each pretty much simultaneously initiates an EID lookup (to verify the EID to RLOC mapping). This creates a DOS attack on the control plane of the mapping function supporting that stock broker or bank. This implies that the responses are going to be delayed (and could be greatly delayed), which allows the incorrect mappings to last longer than they otherwise would. This allows any systems that actually happen to be trying to connect to that stock or banking site to be redirected to the attacker's site. The attacker then becomes a man in the middle and can for example can obtain the password and account information for users.  

Last paragraph of section 4.3.2.2: 

   If the size of the Map-Request
   message is larger than the size of the smallest LISP-encapsulated
   packet that could trigger such a message, this could lead to
   amplification attacks (see Section 4.4.1) so that more bandwidth is
   consumed on the target than the bandwidth necessary at the attacker
   side.

The size of the packet is not the only issue. If the amount of processing required to send a map-request and deal with the reply is greater than the amount of processing that is required to send a packet that triggers such a request, then this could also result in an amplification attack. In principle it would seem that sending out a large number of packets to trigger such a request would be relatively straightforward (for example the attacker might be sending out many packets only incrementing the EID in order to attack the ITR that will need to generate many map requests). We may note that for many systems, particularly very high speed routers (which might exist for example as PE routers connecting very large enterprise customers), the control plane may be several orders of magnitude slower than the data plane, so that an attack that requires response from the router's control plane would be much more serious than an attack of the same size that can be handled in the data plane. I will say more about this in my comments below regarding DOS attacks. 

Section 4.3.2.3, third paragraph (right after the bullets): 

   The first type of packet should not cause any major problem to ITRs.
   As the reachability test uses a 24 bits nonce, it is unlikely that an
   off-path attacker could send a single packet that causes an ITR to
   believe that the ETR it is testing is reachable while in reality it
   is not reachable.  To increase the success likelihood of such attack,
   the attacker should create a massive amount of packets carrying all
   possible nonce values.

However, this could be a problem if there are on-path attackers, since they will see the nonce. They could insert nonce's where none are present, requiring a response from the ETR. Given that the control plane of very high speed PE routers may be much slower than the data plane, this could cause a relatively moderate data stream that the data plane or the PE could easily handle to turn into a control plane attack that the control plane of a PE router could not handle. Also, the on-path attacker could see the nonce's and respond "correctly" (or in a way that the ITR that sent the nonce *thinks* is correct), thereby "verifying" connectivity when none is present. You dismissed on-path attacks earlier in the document on the basis that the user data could be encrypted, but these are examples of on-path attacks that would be on the LISP header and operation, and not on the user data. 

Section 5.2 (Denial of Service):

You need to mention here the relative difference in speed between the data plane and the control plane of high speed routers. For example, there are plenty of examples currently widely deployed of 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 I doubt that any of them could handle Map-Requests coming in at line rate at a gigabit. Thus the ratio between the speed of the control plane the speed of the data plane is significantly greater than 1000. I understand that many PE routers have slower data planes (and the CE "wireless router" that sits in each of our homes is of course a lot slower than this), but large data centers or large enterprise sites could very well be connected to their service provider via a few very high speed PE routers. Therefore an attack that would be trivial to handle in the data plane (say, a few gigabits) could overwhelm the control plane. 

Gleaning allows incoming packets to create map requests, which allows a data plane attack to turn into a control plane attack. Given the difference in speeds between the data plane and the control plane, this makes it much easier to create an effective DOS attack. 

Section 8 (Security Considerations). 

I am pleased that you removed the sentence from section 1 of the previous (-08) draft that read: "As a result of  the performed analysis, the document discusses the severity of the threats and proposes recommendations to reach the same level of security in LISP than in Internet today (e.g., without LISP)". This sentence was not actually correct. However, in looking through the document and in thinking about the implications (see the rest of this email) it is quite clear that the security of an Internet using LISP would be significantly less than the current Internet (at least if you assume that there is *any* security at all in the current Internet). I am thinking that there should be a sentence at the end of section 8 to the effect that "At the current time it appears that LISP would have significant security implications if deployed on an Internet-wide scale".

Finally, two items left out:

I don't see any discussion on the effect of LISP on firewalls. I am assuming that pretty much all currently deployed firewalls are not able to look past a LISP header to inspect the contents of packets. At a minimum, this would seem to imply that LISP will need to be deployed toward the Internet core from the current firewalls, so that the firewalls can be looking at normal (unchanged) IP packets.

There is another issue which might belong in the section on privacy: In the Internet today if you want to attack a network with prefix aa.bb/16, and you see this advertisement in the BGP routes, you can pick a random address and send a packet and see if anything happens. You get little feedback. With LISP you can send a map request to a random address in the block and get back a map reply. This gives you an RLOC which is in general the actual IP address of a real PE or CE router. Of course you can repeat this across the entire /16, or even the Internet (given sufficient time and traffic), and get something close to a complete list of LISP xTRs. This implies that if service providers implement LISP on PE routers, then they will be exposing the identity of their PE routers to worldwide inspection. Given the number of PE routers in the world (obviously much larger than the number of service providers, and given PA address aggregation probably larger than the number of routes that show up in the BGP routing table) we should expect that there are lots of PE routers that have not been carefully secured, and exposing their existence to open worldwide easy discovery would likely open the door to a number of attacks that involve compromise of PE routers. Of course if LISP is deployed on CE routers then their RLOC would similarly be exposed. 

Thanks, Ross

-----Original Message-----
From: lisp [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, May 09, 2014 11:54 AM
To: [email-masked]
Subject: [lisp] Restarting last call on LISP threats

Thank you,
Joel

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

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 13 May 2014 09:47:51 +0200

Hi Ross,

See inline,

> To me an on-path attacker is one which is on the data path. Such an attacker might attack the contents of the data packet. In this case the paragraph seems mostly correct to me: You encrypt the con…

There exist two draft that are relevant to what you address.

You have https://datatracker.ietf.org/doc/draft-farinacci-lisp-crypto/
where the payload of a LISP encapsulated packet are encrypted. None of
the keys for encrypting/decrypting are stored in the mapping system
but is calculated by the xTR's involved.
Then you have https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/
that attempts to secure the xTR to xTR relationship.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Ross Callon <[email-masked]>
Date: Tue, 13 May 2014 16:31:20 +0000

I don't think that the two drafts that you reference solve the problem that I am concerned about (they address and may solve other problems, of course). 

For example, looking at draft-ietf-lisp-sec-06, it says:

   This memo specifies LISP-SEC, a set of security mechanisms that
   provides origin authentication, integrity and anti-replay protection
   to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
   process.  LISP-SEC also enables verification of authorization on EID-
   prefix claims in Map-Reply messages.

Thus if we assume that draft-ietf-lisp-sec-06 works, then what we hear back from the mapping system should be correct (or should be equally reliable to what we hear back from the DNS system today, and we do today rely on DNS when we are contacting our bank or brokerage service to conduct financial transactions). 

What I am concerned about is that *before* we hear back from the mapping system, we are believing what we have gleaned, and this may cause us to be talking to the wrong system. We might be conducting key negotiation with the wrong system just as easily as we could be exchanging banking or brokerage information with the wrong system. 

Ross  

-----Original Message-----
From: Roger Jørgensen [mailto:[email-masked]] 
Sent: Tuesday, May 13, 2014 3:48 AM
To: Ross Callon
Cc: [email-masked]
Subject: Re: [lisp] Restarting last call on LISP threats

Hi Ross,

See inline,

--

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 13 May 2014 17:21:50 +0000

Hi Roger,

Can this draft stand on its own, without integrating content from the documents that you reference?

                                                                                             Ron

> where the payload of a LISP encapsulated packet are encrypted. None of the
> keys for encrypting/decrypting are stored in the mapping system but is
> calculated by the xTR's involved.

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 13 May 2014 17:31:45 +0000

Hi Roger,

Or asked more explicitly, can the level of security claimed by the threats document be achieved without implementing the protocol extensions described in lisp-sec and lisp-crypto?

                                                          Ron

> From: Ronald Bonica
> Sent: Tuesday, May 13, 2014 1:22 PM
> To: 'Roger Jørgensen'; Ross Callon
> Cc: [email-masked]
> Subject: RE: [lisp] Restarting last call on LISP threats
> 
> Hi Roger,
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 13 May 2014 10:47:00 -0700

> Thus if we assume that draft-ietf-lisp-sec-06 works, then what we hear back from the mapping system should be correct (or should be equally reliable to what we hear back from the DNS system today,…

The main LISP spec (RFC6830) indicates if you want to trust the mapping system you can use the gleaned information as soon as you receive it. And if you don't trust the mapping system, you can send a "verifying Map-Request" to the mapping system which results in a signed Map-Reply returned ala draft-ietf-lisp-sec-06.

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 May 2014 17:56:30 -0400

Ron, I am having trouble with the question.

The threats document describes the threats as they exist today, without 
the adoption of either document that Roger pointed to.  Thus, I do not 
see any dependence.

If there is a threat that is not well described in the base spec or this 
document, then we should add it.  We should add it even if there are 
proposals to remediate it.  But if there is a clear proposal of a 
missing threat, I missed it.

Yours,
Joel

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 14 May 2014 09:58:51 +0200

> Or asked more explicitly, can the level of security claimed by the threats document be achieved without implementing the protocol extensions described in lisp-sec and lisp-crypto?

I've been pondering on what to answer you since yesterday but think
the reply from Joel cover it well. However as an addon to Joel and
partly reply to your question, see more inline.

On Tue, May 13, 2014 at 11:56 PM, Joel M. Halpern <[email-masked]> wrote:
> The threats document describes the threats as they exist today, without the
> adoption of either document that Roger pointed to.  Thus, I do not see any
> dependence.
>
> proposals to remediate it.  But if there is a clear proposal of a missing
> threat, I missed it.

Your question made me question the purpose of the LISP threats draft -
should it cover potential problem with RFC6830 and include pointers to
other work that cover them? That will include we'll get a document
that will be updated over time and is that a good thing?

The other way to look at LISP threats document is to have it as a
"review" of RFC6830, point out weaknesses and discuss them but with no
references to other documents. It will be a upstream document that we
can refer to from like the two draft I mention.

I don't think LISP threat should point to the two draft I mention, but
both drafts should have a reference to LISP threat since this will be
create a more stable threat document.

Then Dino mention:

On Tue, May 13, 2014 at 7:47 PM, Dino Farinacci <[email-masked]> wrote:
<snip>
> The main LISP spec (RFC6830) indicates if you want to trust the mapping system you can use the gleaned information as soon as you receive it. And if you don't trust the mapping system, you can send…

Is this covered in the document? I didn't see it but it's still early here...

--

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 15 May 2014 18:15:39 +0000

Joel,

The threats document should not depend on lisp-sec or lisp-crypto. However, Roger's response did rely on those documents (see his response, below). 

So, we are left to explore whether something was omitted from the threats document. Standby for my response to Roger.

                                                                        Ron

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2014 5:57 PM
> To: Ronald Bonica; Roger Jørgensen; Ross Callon
> Cc: [email-masked]
> proposals to remediate it.  But if there is a clear proposal of a missing threat, I
> missed it.
> 
> Yours,
> Joel
> 
> > Or asked more explicitly, can the level of security claimed by the threats
> document be achieved without implementing the protocol extensions
> described in lisp-sec and lisp-crypto?
> >
> >                                                            Ron
> >
> >
> >>> You have
> >>> https://datatracker.ietf.org/doc/draft-farinacci-lisp-crypto/
> >>> where the payload of a LISP encapsulated packet are encrypted. None
> >>> of the keys for encrypting/decrypting are stored in the mapping
> >>> system but is calculated by the xTR's involved.

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 15 May 2014 14:29:28 -0400

The threats document does not specify how to resolve the threats.  It
identifies problems.  In this particular case, it already identifies the
problem that Ross raised.  Quite clearly.

There is no dependence on the documents Roger pointed to.  They are ways 
of remediating the threat.

Yours,
Joel

On 5/15/14, 2:15 PM, Ronald Bonica wrote:
> Joel,
>
> The threats document should not depend on lisp-sec or lisp-crypto.
> However, Roger's response did rely on those documents (see his
> response, below).
>
> So, we are left to explore whether something was omitted from the
> threats document. Standby for my response to Roger.
>
> Ron
>
>
>
>> -----Original Message----- From: Joel M. Halpern
>> [mailto:[email-masked]] Sent: Tuesday, May 13, 2014 5:57 PM
>> To: Ronald Bonica; Roger Jørgensen; Ross Callon Cc: [email-masked]
>> The threats document describes the threats as they exist today,
>> without the adoption of either document that Roger pointed to.
>> Thus, I do not see any dependence.
>>
>> If there is a threat that is not well described in the base spec or
>> this document, then we should add it.  We should add it even if
>> there are proposals to remediate it.  But if there is a clear
>> proposal of a missing threat, I missed it.
>>
>> Yours, Joel
>>
>>>> -----Original Message----- From: Ronald Bonica Sent: Tuesday,
>>>> May 13, 2014 1:22 PM To: 'Roger Jørgensen'; Ross Callon Cc:
>>>> [email-masked] Subject: RE: [lisp] Restarting last call on LISP
>>>> threats
>>>>
>>>> Hi Roger,
>>>>
>>>>> of the keys for encrypting/decrypting are stored in the
>>>>> mapping system but is calculated by the xTR's involved. Then
>>>>> you have
>>>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ that
>>>>> attempts to secure the xTR to xTR relationship.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>
>>> _______________________________________________ lisp mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/lisp
>>>

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 15 May 2014 18:42:20 +0000

Joel,

Please standby for my response to Roger.

                                    Ron

> From: Joel Halpern Direct [mailto:[email-masked]]
> Sent: Thursday, May 15, 2014 2:29 PM
> To: Ronald Bonica; Joel M. Halpern; Roger Jørgensen; Ross Callon
> Cc: [email-masked]
> identifies problems.  In this particular case, it already identifies the problem
> that Ross raised.  Quite clearly.
> 
> >> this document, then we should add it.  We should add it even if there
> >> are proposals to remediate it.  But if there is a clear proposal of a
> >>>> -----Original Message----- From: Ronald Bonica Sent: Tuesday, May
> >>>> 13, 2014 1:22 PM To: 'Roger Jørgensen'; Ross Callon Cc:
> >>>>> system but is calculated by the xTR's involved. Then you have
> >>> _______________________________________________ lisp
> mailing list
> >>> [email-masked] https://www.ietf.org/mailman/listinfo/lisp
> >>>

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 15 May 2014 19:47:04 +0000

Dino,

Don't you always have to trust the mapping system? 

Did you mean to say, "If you want to trust the originator of the gleaned information, ...." ?

                                                                           Ron

> From: lisp [mailto:[email-masked]] On Behalf Of Dino Farinacci
> Sent: Tuesday, May 13, 2014 1:47 PM
> To: Ross Callon
> Cc: Roger Jorgensen; [email-masked]
> > Thus if we assume that draft-ietf-lisp-sec-06 works, then what we hear
> back from the mapping system should be correct (or should be equally
> reliable to what we hear back from the DNS system today, and we do today
> rely on DNS when we are contacting our bank or brokerage service to
> conduct financial transactions).
> 
> The main LISP spec (RFC6830) indicates if you want to trust the mapping
> system you can use the gleaned information as soon as you receive it. And if
> you don't trust the mapping system, you can send a "verifying Map-Request"
> to the mapping system which results in a signed Map-Reply returned ala
> draft-ietf-lisp-sec-06.
> 
> Dino
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 May 2014 15:55:44 -0400

> Don't you always have to trust the mapping system? 

Yes. 

> Did you mean to say, "If you want to trust the originator of the gleaned information, ...." ?

Yes. But what I wrote was not incorrect. If the gleaned information comes from an xTR from the site, you are not trusting the mapping system at this point. 

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 15 May 2014 21:02:26 +0000

Roger,

Having considered this, it appears that the LISP data plane can operate in trusted or untrusted mode. In the trusted mode, when one XTR receives a data-plane packet from another, it can trust control plane information that it might glean from the packet's outer IP header and LISP header. Such trust is based on the assumption that:

- the sending XTR is who it claims to be
- the sending XTR is not intentionally offering bad mapping information to the receiving XTR

In trusted mode, the receiving XTR can glean control information from the data plane. However, in untrusted mode, the receiving XTR must not do so. Alternatively, it must send a verifying MAP-REQUEST to the mapping system.

So far, all of this is covered nicely between RFC 6830 and the LISP threats document. However, we have yet to explore the threats associated with unsecured mode operation, where gleaned information cannot be used.

For example, assume that two XTRs and an attacker are connected to the global Internet. The attacker is neither an XTR nor contained by a LISP site. The attacker is capable of spoofing its sources address.

The attacker can launch a DoS attack against an XTRs control plan by sending a barrage of crafted packets to the victim XTR. Each crafted packet cause the victim XTR to send a verifying MAP-REQUEST to the mapping system.  The attack stream may be so large that it causes the victim XTR to exceed the rate limit for MAP-REQUEST messages. 

                                                                                                           Ron

> Sent: Wednesday, May 14, 2014 3:59 AM
> To: Ronald Bonica
> Cc: Ross Callon; [email-masked]
> I've been pondering on what to answer you since yesterday but think the
> reply from Joel cover it well. However as an addon to Joel and partly reply to
> your question, see more inline.
> 
> 
> > without the adoption of either document that Roger pointed to.  Thus,
> > I do not see any dependence.
> >
> should it cover potential problem with RFC6830 and include pointers to other
> work that cover them? That will include we'll get a document that will be
> updated over time and is that a good thing?
> 
> The other way to look at LISP threats document is to have it as a "review" of
> RFC6830, point out weaknesses and discuss them but with no references to
> other documents. It will be a upstream document that we can refer to from
> like the two draft I mention.
> 
> I don't think LISP threat should point to the two draft I mention, but both
> drafts should have a reference to LISP threat since this will be create a more
> stable threat document.
> 
> 
> 
> Then Dino mention:
>

---

From: Ross Callon <[email-masked]>
Date: Thu, 15 May 2014 21:39:35 +0000

I raised a list of problems. They are not all already mentioned in the threats document (eg, note the privacy issue at the end of my detailed email). 

Ross

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Thursday, May 15, 2014 2:29 PM
To: Ronald Bonica; Joel M. Halpern; Roger Jørgensen; Ross Callon
Cc: [email-masked]
Subject: Re: [lisp] Restarting last call on LISP threats

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 May 2014 17:42:18 -0400

I may have misread the discussion.
I was commenting only on the one topic of gleaning.  I was leaving it to 
the authors to respond to your other comments.
Yours,
Joel

---

From: Ross Callon <[email-masked]>
Date: Thu, 15 May 2014 21:47:43 +0000

No problem. I just didn't want the other issues to be forgotten in the excitement over gleaning. 

Ross

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 May 2014 11:36:18 -0700

> - the sending XTR is not intentionally offering bad mapping information to the receiving XTR

Determining "who" is rather nebulous. How can I trust this email is from you Ron? It's because I have ultra meta-data about you. That is, I know you can be versed in LISP so I am likely talking to another LISP spoofer that looks like Ron.

So if I am getting packets from an xTR that has a global locator that is your DSL router at your house, I would expect to see the inner source EID be from the mapping. I can tell that the EID->RLOC mapping is authenticated and validated by asking the mapping system, but if Roger managed to get packets to me with BOTH your EID and RLOC, then I really don't know if those packets are coming from Ron. 

Now how Roger does this will be an amazing feat because a lot of ISPs between Roger and me would be very broken.

> In trusted mode, the receiving XTR can glean control information from the data plane. However, in untrusted mode, the receiving XTR must not do so. Alternatively, it must send a verifying MAP-REQUE…

If you encrypt data to me, I cannot tell you are actually Roger or Ron. But the conversation between me and Roger (who is spoofing Ron) will be confidential.  ;-)

We either have total privacy or we have NSA intrusion.  ;-)  You can't have both so we should have the former.

> So far, all of this is covered nicely between RFC 6830 and the LISP threats document. However, we have yet to explore the threats associated with unsecured mode operation, where gleaned information…

This is true. When a system receives an ARP-request it gleans the source information in there to minimize broadcast traffic for returned unicast traffic. That is a benefit willing to receive at a cost of knowing a LAN is secure and scoped (if that is really true, it is another story). So there is a value/risk tradeoff here.

> For example, assume that two XTRs and an attacker are connected to the global Internet. The attacker is neither an XTR nor contained by a LISP site. The attacker is capable of spoofing its sources…

But will the entire path to any destination let him?

> The attacker can launch a DoS attack against an XTRs control plan by sending a barrage of crafted packets to the victim XTR. Each crafted packet cause the victim XTR to send a verifying MAP-REQUEST…

You can trust sources less if they ARE NOT in the mapping database. That is, if you are a LISP site, you have more tools be verify trust.

Dino

---

From: Sander Steffann <[email-masked]>
Date: Fri, 16 May 2014 21:11:00 +0200

Hi Dino,

> If Roger managed to get packets to me with BOTH your EID and RLOC, then I really don't know if those packets are coming from Ron. 
> 

Unfortunately this is not unlikely :(  I certainly wouldn't consider it an amazing feat... BCP38 is not implemented as much as it should be.

Cheers,
Sander

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 May 2014 19:37:14 -0400

> Unfortunately this is not unlikely :(  I certainly wouldn't consider it an amazing feat... BCP38 is not implemented as much as it should be.

I know there are many cases where BCP38 is not practice but more and more access providers due uRPF. 

You only need one in the path. And the ones that don't do it are using resources to transit packets to possible black holes. 

Dino

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 17 May 2014 22:36:54 +0200

> The attacker can launch a DoS attack against an XTRs control plan by sending a barrage of crafted packets to the victim XTR. Each crafted packet cause the victim XTR to send a verifying MAP-REQUEST…

Lots of other people that know LISP way better than I do have responded already.

Do I understand you correct that you think there is a hole in the
threat draft, or are you talking about another miss, that is what will
happen if the mapping-system fail to reply in time when encryption or
other form for verification of both ends (iTR and eTR) are used?

--

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 19 May 2014 14:14:05 +0000

Dino,

The Spoofer Project (http://spoofer.cmand.org/summary.php) offers a longitudinal view of BCP 38 deployment. I think that the results that they report validate Sander's objection. Furthermore, they may suggest that Sander's objection will remain valid for years to come.

                                                                                                                                   Ron

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Friday, May 16, 2014 7:37 PM
> To: Sander Steffann
> Cc: Ronald Bonica; Roger Jorgensen; [email-masked]
> > Unfortunately this is not unlikely :(  I certainly wouldn't consider it an
> amazing feat... BCP38 is not implemented as much as it should be.
> 
> You only need one in the path. And the ones that don't do it are using
> resources to transit packets to possible black holes.
> 
> Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 May 2014 13:56:59 -0400

In those cases we do mapping database RPF lookups. 

Dino

> On May 19, 2014, at 10:14 AM, Ronald Bonica <[email-masked]> wrote:
> 
> Dino,
>

---

From: Damien Saucez <[email-masked]>
Date: Tue, 20 May 2014 00:25:40 +0200

Dear Ross,

Thank you for your time.

Before detailed comments below, we have to remind that the objective
of this document is to identify global threats potentially introduced
by LISP w.r.t.  what exists today in the legacy Internet.  The problem
space is out of the scope of the document.

comments inline.

> To me an on-path attacker is one which is on the data path. Such an attacker might attack the contents of the data packet. In this case the paragraph seems mostly correct to me: You encrypt the con…

The paragraph you are citing end with this document does _not_
consider on-path attackers..  While you remarks are generally valuable
they do not apply here, the document is not proposing anything, it i
just stating what is _not_ considered.

> Also, you should mention in this section that a gleaning attack would allow at least in the short term for an attacker to become temporarily on-path even if they are not on what should be the norma…
The definition we give about on-path attacker includes your
sub-category.  It does not matter where you attacker physically is.
If it is able to capture and modify packets then it is on-path (does
not matter if physical shorter or not).

> An on-path attacker might choose to only change something about the LISP handling details, such as exploding the map cache or redirecting a user to a different site. Some of this is mentioned later…

The document is just an analysis, hence your question, while valid, is
outside the scope of this document.
> In terms of injecting traffic that the end system receives and acts upon, I believe that this sentence is entirely true. However, in terms of the effect on the router's control plane, and particula…
The section actually does not enter in any discussion about
quantifying the damages.  So the second part of your comment is
correct if it does apply to section 4.3.1.

The first half of your comment is, however, unfounded.  Section 4.3.1
is about attacks _not_ leveraging on LISP header, so from this side it
is exactly the same case like any other IP spoofed packet.  In
particular since LISP header is not used, xTR functions are not
actually attacked.

> Given recent events, I think that "NSA" is an unfortunate acronym to use here. How about NSOA? 

This can be fixed before pushing the document to the IESG.

> The amount of damage that might be caused by this may depend upon what happens to be exchanged in that "short amount of time". For example, the initial handshake between sites (at the application l…

Exchanging critical information (e.g.  password) in clear means that
you have a serious problem, but not at the network layer.  Also, the
situation with LISP would not be worse than without LISP.

> 
> Also, depending upon how long xTR's are willing to store gleaned information (before the map request comes back), the time that a user is misdirected due to a gleaning attack might be extended by coordinating a DDOS attack with the gleaning attack. For example, an attacker may send packets to a very large number of sites, with a source EID which is from a major stock broker or bank and an RLOC from the attacker's captive servers. The many sites glean the EID to RLOC mapping from the arriving packets. Each pretty much simultaneously initiates an EID lookup (to verify the EID to RLOC mapping). This creates a DOS attack on the control plane of the mapping function supporting that stock broker or bank. This implies that the responses are going to be delayed (and could be greatly delayed), which allows the incorrect mappings to last longer than they otherwise would. This allows any systems that actually happen to be trying to connect to that stock or banking site to be redirected to the a
> ttacker's site. The attacker then becomes a man in the middle and can for example can obtain the password and account information for users.  
> 
> 

Such a scenario would require a lot of synchronisation.  Anyway, our
opinion is that the current text is stating exactly the same thing you
describe just in a succinct way.

As a reminder, the present document studies LISP in a public network
deployment.

> The size of the packet is not the only issue. If the amount of processing required to send a map-request and deal with the reply is greater than the amount of processing that is required to send a packet that triggers such a request, then this could also result in an amplification attack. In principle it would seem that sending out a large number of packets to trigger such a request would be relatively straightforward (for example the attacker might be sending out many packets only incrementing the EID in order to attack the ITR that will need to generate many map requests). We may note that for many systems, particularly very high speed routers (which might exist for example as PE routers connecting very large enterprise customers), the control plane may be several orders of magnitude slower than the data plane, so that an attack that requires response from the router's control plane would be much more serious than an attack of the same size that can be handled in the data plane. I 
> will say more about this in my comments below regarding DOS attacks. 
> 
> 

Your first point can be easily fixed by substituting the word
bandwidth with bandwidth and/or processing or "resource"

Your statement on the speed difference between control and data plane
is true and is a general observation not limited to LISP.  Note that
one of the advantages of having the Map-Server/Map-Resolver elements
in the LISPa architecture is exactly to avoid situations you are
describing.

> However, this could be a problem if there are on-path attackers, since they will see the nonce. They could insert nonce's where none are present, requiring a response from the ETR. Given that the c…

It is clearly stated at the beginning of the document that on-path
attacks are out of the scope of the document.  Also, Sec.  2 does not
limit cryptography technique to the payload, actually section 2 makes
the distinction saying:

1)
 "To cope with such an attacker, cryptographic techniques such as
 those used by IPSec ([RFC4301 ]) are required."

which is reported to any form of packet manipulation

and 2)
"As with IP, LISP relies on higher layer cryptography to secure packet
payloads from on path attacks, so this document does not consider
on-path attackers."

which is related to attacks targeting the payload.

> You need to mention here the relative difference in speed between the data plane and the control plane of high speed routers. For example, there are plenty of examples currently widely deployed of…

You are absolutely right, but why this is specific to LISP?  It is not
specific to LISP, so there is no reason to discuss such an issue in
this document.

> Gleaning allows incoming packets to create map requests, which allows a data plane attack to turn into a control plane attack. Given the difference in speeds between the data plane and the control…

RFC6830 already considered rate limiting fo this very reason.

> I am pleased that you removed the sentence from section 1 of the previous (-08) draft that read: "As a result of  the performed analysis, the document discusses the severity of the threats and prop…

Such sentence would not represent the discussions that took place in
the LISP WG in the last four years.

The arguments that you raised in the previous part of this mail are
mainly not LISP-specific, while the experience gathered in the last
years show that LISP is not worst that what we have today (and
actually research work out there shows that it can even be helpful to
use LISP)

> I don't see any discussion on the effect of LISP on firewalls. I am assuming that pretty much all currently deployed firewalls are not able to look past a LISP header to inspect the contents of pac…

Deployment model is out of the scope of this document and the problem
is not specific to LISP.

> There is another issue which might belong in the section on privacy: In the Internet today if you want to attack a network with prefix aa.bb/16, and you see this advertisement in the BGP routes, you can pick a random address and send a packet and see if anything happens. You get little feedback. With LISP you can send a map request to a random address in the block and get back a map reply. This gives you an RLOC which is in general the actual IP address of a real PE or CE router. Of course you can repeat this across the entire /16, or even the Internet (given sufficient time and traffic), and get something close to a complete list of LISP xTRs. This implies that if service providers implement LISP on PE routers, then they will be exposing the identity of their PE routers to worldwide inspection. Given the number of PE routers in the world (obviously much larger than the number of service providers, and given PA address aggregation probably larger than the number of routes that show u
> p in the BGP routing table) we should expect that there are lots of PE routers that have not been carefully secured, and exposing their existence to open worldwide easy discovery would likely open the door to a number of attacks that involve compromise of PE routers. Of course if LISP is deployed on CE routers then their RLOC would similarly be exposed. 
> 

If routers are not correctly secured, there is no problem linked to
LISP as today it is already possible to discover the IP address of
theses routers thanks to various techniques.  Moreover, section 6
already clearly states that privacy is not discussed in the document
but that the attacks presented in the document can potentially play a
role in privacy threats.

Regards,

The authors of the threats document.

---

From: Ross Callon <[email-masked]>
Date: Wed, 21 May 2014 15:16:05 +0000

I will respond to your email in detail (in a separate email), but I also 
have one higher level meta-comment which is important which I think that 
we should discuss first. 

Specifically, we need to remember what LISP is proposed to do. LISP 
has been proposed as a new routing and addressing architecture for the 
Internet. If we believe this goal is realistic, and if we believe that 
LISP could actually end up being deployed as the routing and addressing 
architecture for the Internet, then the Internet could someday be entirely 
dependent upon LISP actually working and actually being secure when 
deployed at scale. 

The Internet has been described as the control plane for the world. The 
Internet is of enormous importance for the world's economy (and all of 
our jobs, and millions of others). IT HAS TO WORK.

As such, any attack that might have the potential of disrupting the 
operation of LISP, or that can be made worse by LISP, MUST be taken 
seriously. If you declare some attacks as "outside of the scope of 
LISP threats document" then either you are saying that the LISP WG is 
not serious about widespread deployment of LISP, or you are putting the 
world's economy at risk. 

If there are any threats which is likely to be waged against the operation 
of LISP, then it is not acceptable to declare these threats as out of scope,
unless we are also going to agree that LISP must not be deployed on a wide
scale. As such, as currently written the threats document is not ready for
publication. 

Sincerely, 
Ross

-----Original Message-----
From: Damien Saucez [mailto:[email-masked]] 
Sent: Monday, May 19, 2014 6:26 PM
To: Ross Callon
Cc: Joel M. Halpern; LISP mailing list list; Luigi Iannone
Subject: Re: [lisp] Restarting last call on LISP threats

Dear Ross,

Thank you for your time.

comments inline.

1)

and 2)

Regards,

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 May 2014 15:40:41 +0000

Dino,

I don't understand your response. So, I will ask the question another way.

Imagine a scenario in which a victim XTR and an attacker are attached to the global Internet. The attacker is neither an XTR nor contained by a LISP site.

The attacker sends a flow of crafted packets to the victim XTR. Each packet is a well-formed LISP data packet. It contains:

- an outer IP header (LOC->LOC)
- a UDP header
- a LISP Header
- an IP header (EID->EID)
- payload

Each packet contains control plane information that is new to the victim XTR. For example, the victim XTR has no mapping information regarding either the source LOC or source EID prefix. Rather than gleaning this mapping information from the crafted packet, the victim XTR sends a verifying MAP-REQUEST to the mapping system.

Assume that the attack flow is large (N packets per second). Assume also that the XTRs rate limit for MAP-REQUEST messages is less than N packets per second. Has the attack not effectively DoS'd the victim XTR?

To make this attack work, every packet in the attack flow may need to have a unique, spoofed, source LOC.

                                                                                                                        Ron

> > The attacker can launch a DoS attack against an XTRs control plan by
> sending a barrage of crafted packets to the victim XTR. Each crafted packet
> cause the victim XTR to send a verifying MAP-REQUEST to the mapping
> system.  The attack stream may be so large that it causes the victim XTR to
> exceed the rate limit for MAP-REQUEST messages.
> 
> You can trust sources less if they ARE NOT in the mapping database. That is, if
> you are a LISP site, you have more tools be verify trust.
> 
> Dino
>

---

From: Damien Saucez <[email-masked]>
Date: Wed, 21 May 2014 17:41:25 +0200

Hello,

I fully agree with your argument that security breach could have impact at large scale. 

However we have to consider this document at the light of what is in the charter. As a matter of fact the charter states lisp as a mean to make the internet more scalable. From that point if view I think lisp is very well designed. From this angle, the document only aim to show if the proposition makes security worst, same, or better than the system lisp is supposed to replace: the legacy internet. For that I think the document is complete as it focuses on what are the risks introduced by the new architecture, ignoring problems that are not lisp specific. 

Despite this, we see many activities around high security features leveraging lisp. Unfortunately these propositions are still out if the scope if the charter as security improvement is not part if current charter. For these proposition to become part of lisp we first have to finish what the charter is asking us. Then we will be able to discuss whether or not we want lisp to be also a solution for security issues currently in the internet.

Thank you,

Damien Saucez 
> On 21 May 2014, at 17:16, Ross Callon <[email-masked]> wrote:
>

---

From: Ross Callon <[email-masked]>
Date: Wed, 21 May 2014 16:45:28 +0000

To get the charter to say "fix these security holes" we need to know what the security holes are. The point of the threats document is to understand what threats are there, not to limit ourselves to only discuss threats that we are already chartered to fix. I am pretty sure that a thorough and complete threats document is in the charter.

There were multiple items in my original comments that point to places where LISP makes security worse than what we have today in the current Internet. I could point these out again in my detailed reply to your email (which might take me a couple of work days to complete, and I am off on Friday and for the long weekend). 

Thanks, Ross

-----Original Message-----
From: Damien Saucez [mailto:[email-masked]] 
Sent: Wednesday, May 21, 2014 11:41 AM
To: Ross Callon
Cc: Joel M. Halpern; LISP mailing list list; Luigi Iannone
Subject: Re: [lisp] Restarting last call on LISP threats

Hello,

Thank you,

Damien Saucez

---

From: Damien Saucez <[email-masked]>
Date: Wed, 21 May 2014 19:25:09 +0200

For me the wg is working on "LISP for improving Internet routing 
scalability. " not lisp to improve security. 

There are threats of course and they are listed in the document. Actually except the on path attacks all the points you discuss are variations of the general categories and vectors listed in the document. So that unless you can give one case not covered by the document, I don't see the need to argue.  

Regarding on-path attacks the risk is at least as high on today's Internet and is for me out of the scope of the draft. Nevertheless, the draft does not say that the problem does not exist it just says that it is not a problem specific to lisp. Nothing precludes to fix the problem and we can even use the draft to justify the necessity to solve the problem! Also it is worth to notice that what you consider as off path attack is already covered in the document as it is a particular instance of subversion attack (see sec 5.3) where the sensitive information the attacker gains access is the packet itself and that can be achieved with vectors listed in 5.3.2. 

I would like to have the feedback from the list to know if really there is a problem with section 2. 

Thank you, 
Damien Saucez
Ps: happy holidays :)

> On 21 May 2014, at 18:45, Ross Callon <[email-masked]> wrote:
>

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 21 May 2014 17:41:34 +0000

Dino,

Aren't we talking about a scenario where the victim XTR has no information regarding the EID or LOC in its map-cache?

                                    Ron

> Sent: Monday, May 19, 2014 1:57 PM
> To: Ronald Bonica
> Cc: Sander Steffann; Roger Jorgensen; [email-masked]
> > The Spoofer Project (http://spoofer.cmand.org/summary.php) offers a
> longitudinal view of BCP 38 deployment. I think that the results that they
> report validate Sander's objection. Furthermore, they may suggest that
> Sander's objection will remain valid for years to come.
> >
> >
> > Ron
> >
> >
> >> You only need one in the path. And the ones that don't do it are
> >> using resources to transit packets to possible black holes.
> >>
> >> Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 May 2014 18:57:41 -0400

> - an IP header (EID->EID)

Just like a regular packet I can send to your home router today. So yes okay. So let's continue. See comments below. 

> Each packet contains control plane information that is new to the victim

Be more specific about what control information are in these encapsulated packets. 

> XTR. For example, the victim XTR has no mapping information regarding either the source LOC or source EID prefix. Rather than gleaning this mapping information from the crafted packet, the victim XTR sends a verifying MAP-REQUEST to the mapping system.
> 

It caches the rate the rate the packets are coming in and eventually stops sending Map-Requests completely. 

It cannot stop the incoming rate of packets today just like a roque BGP attacker can send millions of packets per second to a peer regardless if it does or does not have the peer authentication key. 

> To make this attack work, every packet in the attack flow may need to have a unique, spoofed, source LOC.

An implementation can detect that after rate limiting 1000s of such requests are happening that it just stops operation. 

What if I sent a Juniper 20 million routes today?

The Internet is very fragile and LISP IS NOT making it worse. And in some cases it is making it better with integrated techniques. 

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 22 May 2014 20:57:15 +0000

Dino,

Today's Internet is not as fragile as you think. This mail traversed many routers between my house and yours. If those routers are well-managed, there is nothing that I can do from my house that will cause any of those routers to consume control plane resources. Therefore, there is nothing that I can do from my house that will cause a DoS attack against those routers' control planes.

In LISP, separation between the forwarding and control plane is lost. As a matter of course, forwarding plane activity causes control plane activity. Since forwarding plane bandwidth exceeds control plane bandwidth, DoS attacks against the control plane are possible.

In order to be complete, the threats document must describe the DoS threat. It should also describe mitigations, if any exist.

                                                                                               Ron

> Sent: Wednesday, May 21, 2014 6:58 PM
> To: Ronald Bonica
> > The attacker sends a flow of crafted packets to the victim XTR. Each packet
> is a well-formed LISP data packet. It contains:
> >
> > XTR. For example, the victim XTR has no mapping information regarding
> either the source LOC or source EID prefix. Rather than gleaning this mapping
> information from the crafted packet, the victim XTR sends a verifying MAP-
> REQUEST to the mapping system.
> >
> > Assume that the attack flow is large (N packets per second). Assume also
> that the XTRs rate limit for MAP-REQUEST messages is less than N packets
> per second. Has the attack not effectively DoS'd the victim XTR?
> 
> It cannot stop the incoming rate of packets today just like a roque BGP
> attacker can send millions of packets per second to a peer regardless if it
> does or does not have the peer authentication key.
> 
> An implementation can detect that after rate limiting 1000s of such requests
> are happening that it just stops operation.
> 
> The Internet is very fragile and LISP IS NOT making it worse. And in some
> cases it is making it better with integrated techniques.
> 
> Dino

---

From: Damien Saucez <[email-masked]>
Date: Fri, 23 May 2014 15:06:34 +0200

Hello Ronald,

> Today's Internet is not as fragile as you think. This mail traversed many routers between my house and yours. If those routers are well-managed, there is nothing that I can do from my house that wi…
We tend to disagree with that, for example you have ICMP today...

> In order to be complete, the threats document must describe the DoS threat. It should also describe mitigations, if any exist.

DoS is already explained and the definition given:

" A Denial of Service (DoS) attack aims at disrupting a specific
   targeted service either by exhausting the resources of the victim up
   to the point that it is not able to provide a reliable service to
   legit traffic and/or systems or by exploiting vulnerabilities to make
   the targeted service unable to operate properly.
"

is covering the case you mention.

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 23 May 2014 06:29:57 -0700

> Dino,
> 
> Today's Internet is not as fragile as you think. This mail traversed many routers between my house and yours. 

Ron, I know for a fact, it is fragile. I know most of the code that runs the Internet. And you said yourself that uRPF is not used in many places, so that, in and of itself, makes it fragile for spoofing.

> If those routers are well-managed, there is nothing that I can do from my house that will cause any of those routers to consume control plane resources. Therefore, there is nothing that I can do from my house that will cause a DoS attack against those routers' control planes.

My example, I wanted to take you out, not the PE router at AT&T that could take out all customers attached to that PE. Which has happned before by bad vendor code. LOL. So I don't have to play there. 

But I can use up all your resources at your house so your kids can get their homework assignments done on time.

It happens to me all the time at Starbucks when 15 people are watching videos and all I want is some decent response in my emacs window.  ;-)  That is not a DoS, in this case but normal usage. So DoSing something is as simple as bringing up an innocent applicaiton and lauching UDP streams to your home router.

> In LISP, separation between the forwarding and control plane is lost. As a matter of course, forwarding plane 

That is not true. And in most cases, when xTRs are behind NATs, there is NEVER a map-cache miss. I assume you are referring to that when you claim there is lost separation. If not, please clarify.

> activity causes control plane activity. Since forwarding plane bandwidth exceeds control plane bandwidth, DoS attacks against the control plane are possible.

Yes, for every protocol we have invented. But like I said, there are better ways to solve this with LISP. If you look at all the drafts in totality, you will see we have a decent toolbox of solutions that COULD fight this traditional problem.

You are merely (and continually) looking ONLY at the map-cache miss problem.

> In order to be complete, the threats document must describe the DoS threat. It should also describe mitigations, if any exist.

I agree with that. No one is arguing your point or Ross point. But rather than just documenting what they are, we want to fix them. So that is were we should put our attention. So let's have all of us work together and identify the problems and brainstorm about fixes. 

Rather than just saying what is wrong.

Dino

---

From: Ross Callon <[email-masked]>
Date: Fri, 23 May 2014 14:36:56 +0000

Detailed comments below. To summarize, these details include three threats which are new to LISP and which are not adequately explained in the current threats document:

 (1) The Control Plane Threat: LISP allows a dataplane DOS attack (lots of packets sent to overwhelm a site) to turn into a control plane attack (the router is forced to respond to the attack in the control plane, which is of course frequently multiple orders of magnitude slower than the data plane, particularly for very high speed routers). 

 (2) The Privacy Threat: LISP provides an attacker with a relatively easy way to determine the identity of large numbers of PE and/or CE routers (globally, if LISP is deployed on that level) .

 (3) the Traffic Gleaning Threat: If an xTR gleans EID -> RLOC mappings from incoming packets, this provides an easy way for hackers to intercept traffic. I put this threat third because gleaning can be turned off, and thus this threat can be defeated simply by not gleaning EID -> RLOC mappings. 

WRT the first of these, Dino has pointed out that the control plane of routers already receive BGP packets from sources outside their domain. Thus a DOS attack on the control plane of routers can be launched through BGP. However, the number of BGP peers that a router has is limited, and can be known a priori. Thus it is possible, and relatively common, for a router to be configured to only accept BGP updates from a very limited number of identified other routers (in many cases a moderate number of external peers plus a few internal route reflectors). Each of these known BGP sessions can be individually rate limited, and no other source can be allowed to send BGP updates to the router. Also, other control traffic to the router can be limited to internal peers (eg, OSPF, IS-IS, LDP, and/or RSVP from other internal routers, plus network management traffic from internal sources only). Thus today every source of control plane traffic to the router can be controlled and rate limited. For CE routers the number of BGP peers can be even more limited, possibly to one (the PE) or even none (for stub domains use manually configured static routes). 

If LISP were ubiquitously and globally deployed across the Internet, then mapping requests could come from pretty much anywhere. Similarly incoming data plane traffic which contains EID's that are not currently listed in your EID -> RLOC mapping would cause a mapping request to be generated in the control plane. I understand that mapping requests (both incoming and outgoing) can be rate limited, but this simply turns a "shut down the router's control plane" attack to turn into a "shut down the router's mapping function" attack. If correct operation relies on the mapping function, then you have still broken the router. 

The second of these is a big deal which has not been talked about much. We don't want hackers to know the identity of all PE and/or CE routers. It is difficult to fully anticipate what attacks will occur, but there certainly have already been intrusions of various kinds against routers and making it fundamentally easier for hackers to know the identity of a large number of routers is something that it at least important enough to mention. 

Regarding the third of these, there have already been attacks which mis-route traffic. Eg:
http://www.wired.com/2013/12/bgp-hijacking-belarus-iceland/   

However, we don't want to make it easier to launch attacks of this kind, and there is other work currently underway to make BGP more difficult to hijack (but of course, gleaning can be turned off). 

More details in-line below, marked with "RWC>" in the left margin...

-----Original Message-----
From: Damien Saucez [mailto:[email-masked]] 
Sent: Monday, May 19, 2014 6:26 PM
To: Ross Callon
Cc: Joel M. Halpern; LISP mailing list list; Luigi Iannone
Subject: Re: [lisp] Restarting last call on LISP threats

Dear Ross,

Thank you for your time.

comments inline.

RWC>  The existing paragraph clearly states "LISP relies on higher layer
RWC>  cryptography to secure packet payloads from on path attacks".
RWC>  However, higher layer cryptography does not protect the LISP header.
RWC>  Thus LISP cannot rely on higher layer cryptography to protect the 
RWC>  LISP header. There is an real attack here that you have just ruled 
RWC>  out of scope without justification. More on this below...

RWC>  Okay, we are agreed that if a gleaning attack allows an attacker to
RWC>  put themselves on-path, then they are considered to be an on-path
RWC>  attacker. LISP therefore makes it easier to launch on-path attacks.
RWC>  This is not a justification to refuse to consider such attacks and 
RWC>  simply rule them "out of scope". 

RWC>  If I understand your reasoning: You don't know how to handle such 
RWC>  attacks. Therefore you don't discuss them and you rule these attacks
RWC>  as "out of scope". Since you don't discuss them, therefore LISP is
RWC>  secure. I must not have understood your reasoning. 

RWC>  This gets back to my meta-comment that I sent earlier in an separate
RWC>  email. We need to understand the attacks that might actually occur.
RWC>  It is not acceptable to just rule an attack out of scope without 
RWC>  considering it, and then decide that LISP is secure because the 
RWC>  attacks that you did consider can be handled. 

> (deleted nit about abbreviation for A non-spoofing off-path attacker)

RWC>  You are correct that exchanging passwords or other login credentials in  
RWC>  the clear is a bad idea, and not LISP's problem. I had a rather long 
RWC>  discussion with a security expert over this, and the bottom line seems
RWC>  to be a bit muddled: The primary security for critical sensitive data
RWC>  (such as passwords) is at the application layer, but this is not perfect
RWC>  -- attacks on the certificates are conceivable -- and thus it is not 
RWC>  ideal to remove another imperfect layer of security. My conclusion from
RWC>  this is that I am not comfortable with the risks of gleaning, but at 
RWC>  worse it just needs to be turned off for operation over non-trusted 
RWC>  environments (such as the Internet). 

RWC>  No. Synchronization is trivial because the attack that inserts wrong 
RWC>  information into the EID -> RLOC mappings **is the same attack** that 
RWC>  creates a DDOS attack against the mapping system.  I believe that the
RWC>  current text understates the risk (which appears to be the purpose 
RWC>  of the entire document). 

RWC>  As it should. 

Your statement on the speed difference between control and data plane
is true and is a general observation not limited to LISP.  

RWC>  of course. But other aspects of router operations are carefully set up
RWC>  to avoid overloading the control plane. 

Note that

RWC>  I don't think that this has succeeded. 

It is clearly stated at the beginning of the document that on-path
attacks are out of the scope of the document. 

RWC>  True. But since you have agreed that gleaning attacks that cause 
RWC>  traffic to be mis-routed cause additional systems to be on-path 
RWC>  and that this constitutes an on-path attack, and since you have 
RWC>  ruled out on-path attacks against the LISP headers, therefore you
RWC>  have failed to adequately consider LISP security. You can't just 
RWC>  rule important attacks out of scope and then claim that you have 
RWC>  any valid conclusion regarding the overall security of LISP. 

 Also, Sec.  2 does not

1)

and 2)

RWC> But doesn't address the issue of on-path attacks on the LISP header. 

RWC>  Discussed elsewhere, but this is specific to LISP because with 
RWC>  LISP data-plane traffic can trigger control-plane map requests. 

RWC>  Of course you can rate limit map requests and responses and thus 
RWC>  turn a "shut the control-plane" attack into a "shut the mapping 
RWC>  system" attack, but this still can take out the mapping system (or a
RWC>  part thereof).

RWC>  LISP has not been sufficiently widely deployed to be of interest to 
RWC>  serious professional attackers. My concerns are LISP-specific and I
RWC>  would hope that you would make an honest attempt to adequately 
RWC>  understand the security aspects of it, rather than just trying to 
RWC>  whitewash the approach. 

RWC>  This would be a trivial update to the document that would make it 
RWC>  more complete, but is not a major point. 

RWC>  Again, saying in the document that some important security aspects
RWC>  are not considered is not a valid way to produce a sound analysis
RWC>  of the security implications of LISP. Privacy is a valid issue that 
RWC>  needs to be considered. 

Thanks, Ross

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 26 May 2014 04:51:22 +0000

Dino,

You have a very good point! Rather than arguing about whether DoS attacks against the control plane are possible, a more constructive course of action might be:

a) to document the attacks
b) to brainstorm for mitgations

IMHO, a) should definitely happen in the threats document. It should include DoS attacks initiated by attackers:

a1) who are outside of LISP sites
a2) who are inside of LISP sites

Mitigations could be documented in the threats document or somewhere else. The AD's and chairs will probably want to make that call.

Do you see an obvious mitigation to A1 and A2?

                                                              Ron

> 
> > activity causes control plane activity. Since forwarding plane bandwidth
> exceeds control plane bandwidth, DoS attacks against the control plane are
> possible.
> 
> Yes, for every protocol we have invented. But like I said, there are better
> ways to solve this with LISP. If you look at all the drafts in totality, you will see
> we have a decent toolbox of solutions that COULD fight this traditional
> problem.
> 
> > In order to be complete, the threats document must describe the DoS
> threat. It should also describe mitigations, if any exist.
> 
> I agree with that. No one is arguing your point or Ross point. But rather than
> just documenting what they are, we want to fix them. So that is were we
> should put our attention. So let's have all of us work together and identify
> the problems and brainstorm about fixes.
>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 26 May 2014 05:06:16 +0000

From: Damien Saucez [mailto:[email-masked]]
Sent: Friday, May 23, 2014 9:07 AM
To: Ronald Bonica
Cc: Dino Farinacci; Roger Jorgensen; LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats

Hello Ronald,

On 22 May 2014, at 22:57, Ronald Bonica <[email-masked]<mailto:[email-masked]>> wrote:

Dino,

Today's Internet is not as fragile as you think. This mail traversed many routers between my house and yours. If those routers are well-managed, there is nothing that I can do from my house that will cause any of those routers to consume control plane resources. Therefore, there is nothing that I can do from my house that will cause a DoS attack against those routers' control planes.
We tend to disagree with that, for example you have ICMP today...
[RPB] Because ICMP is susceptible to DoS attacks, it wouldn't make a very good routing protocol. That's why we don't use it for routing. By contrast, LISP map-request messages are susceptible to DoS attacks and they do carry routing information.

is covering the case you mention.
[RPB]
You might want to add the following details to section 5.2:

-          A DoS attack can be launched by anybody who can send a packet to the XTR's LOC

-          DoS attacks can render an XTR inoperable

-          DDoS attacks can render the mapping system inoperable.

This is what differentiates LISP from today's routing system.

                                      Ron

Damien Saucez

                                                                                              Ron

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]]
Sent: Wednesday, May 21, 2014 6:58 PM
To: Ronald Bonica
Cc: Roger Jorgensen; [email-masked]<mailto:[email-masked]>
Subject: Re: [lisp] Restarting last call on LISP threats

Just like a regular packet I can send to your home router today. So yes okay.
So let's continue. See comments below.

Be more specific about what control information are in these encapsulated
packets.

It caches the rate the rate the packets are coming in and eventually stops
sending Map-Requests completely.

To make this attack work, every packet in the attack flow may need to have
a unique, spoofed, source LOC.

Dino

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

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 26 May 2014 13:03:44 +0200

A general reply, we were on the way to getting into a head-to-head
discussion instead of being constructive. The last few email I read
moved away from that path.

I think we should discuss all threat, not just define them to be out of scope.

some comments:

>  (1) The Control Plane Threat: LISP allows a dataplane DOS attack (lots of packets sent to overwhelm a site) to turn into a control plane attack (the router is forced to respond to the attack in th…

Seems like we all disagree on how serious this is, how much harm it
can do. But it should be mention.

I think I remember an earlier discussion on a very similar topic that
just ended with people disagreeing and stopped discussing it.
This is probably a new topic, but where is the weakness really,
Mapping-System or on the xTR side? ...?
Could be that our ongoing discussion here might be because it's not
good enough explained?

>  (2) The Privacy Threat: LISP provides an attacker with a relatively easy way to determine the identity of large numbers of PE and/or CE routers (globally, if LISP is deployed on that level) .

I agree there are privacy threats.

LISP is no better or worse compared to current internet on privacy for
end-user, it's reveled one way or another somehow unless you encrypt
your data (HTTPs etc).
What LISP add to the pool is the possibility to collect the IP for
many end-sites with ease, xTR sides. Is that the same thing as what
you're describing?

>  (3) the Traffic Gleaning Threat: If an xTR gleans EID -> RLOC mappings from incoming packets, this provides an easy way for hackers to intercept traffic. I put this threat third because gleaning c…

Isn't this the same as on-path and Man-in-the-middle attack? Or do you
describe something else?

--

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 26 May 2014 11:46:34 -0400

Top posting to make sure I am understanding:

You asssert that any xTR is subject to a DoS attack.  And that such a 
DoS attack can render the mapping system unusable.

It targeting an ITR, this would need to be from within ths cope the ITR 
serves.  I believe that is discussed.

If I have connected the dots correctly, the attack you are contemplating 
is sending a large stream of packets with different inner source 
addresses to an ETR.  This would prompt the ETR to check with the 
mapping system about each and every address.

If I have understood this properly, while there are several very 
effective mitigations, that does not change the basic message that this 
is an attack, and as such ought to be described in the threats document. 
  There are clealry a number of variations on this attack.  For example, 
using the same outer source address makes mitigation easier, while using 
different outer source addresses either requires a bot-net or a large 
unchecked BCP38 hole (and those can be used for MANY attacks on many 
systems.)  Both presumably should be described.

Have I captured your request accurately?

Yours,
Joel

On 5/26/14, 1:06 AM, Ronald Bonica wrote:
> *From:*Damien Saucez [mailto:[email-masked]]
> *Sent:* Friday, May 23, 2014 9:07 AM
> *To:* Ronald Bonica
> *Cc:* Dino Farinacci; Roger Jorgensen; LISP mailing list list
> *Subject:* Re: [lisp] Restarting last call on LISP threats
>
> Hello Ronald,
>
>     Today's Internet is not as fragile as you think. This mail traversed
>     many routers between my house and yours. If those routers are
>     well-managed, there is nothing that I can do from my house that will
>     cause any of those routers to consume control plane resources.
>     Therefore, there is nothing that I can do from my house that will
>     cause a DoS attack against those routers' control planes.
>
> */[RPB] Because ICMP is susceptible to DoS attacks, it wouldn’t make a
> very good routing protocol. That’s why we don’t use it for routing. By
> contrast, LISP map-request messages are susceptible to DoS attacks and
> they do carry routing information./*
>
>
>
>     In LISP, separation between the forwarding and control plane is
>     lost. As a matter of course, forwarding plane activity causes
>     control plane activity. Since forwarding plane bandwidth exceeds
>     control plane bandwidth, DoS attacks against the control plane are
>     possible.
>
> */[RPB] /*
> */You might want to add the following details to section 5.2:/*
>
> *//*
>
> -A DoS attack can be launched by anybody who can send a packet to the
> XTR’s LOC
>
> -DoS attacks can render an XTR inoperable
>
> -DDoS attacks can render the mapping system inoperable.
>
> This is what differentiates LISP from today’s routing system.
>
>                                        Ron
>
> Damien Saucez
>
>
>
>                                                                                                    Ron
>
>
>
>         Cc: Roger Jorgensen; [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 26 May 2014 15:57:37 +0000

Inline.....

> Sent: Monday, May 26, 2014 11:47 AM
> To: Ronald Bonica; Damien Saucez
> Cc: Roger Jorgensen; LISP mailing list list
> You asssert that any xTR is subject to a DoS attack.  And that such a DoS
> attack can render the mapping system unusable.
[RPB] 
Exactly!

> 
> It targeting an ITR, this would need to be from within ths cope the ITR serves.
[RPB] 
I don't understand this sentence. Please try again.

> I believe that is discussed.
[RPB] 
Given that I don't understand the sentence above, I have no idea if this sentence is true.

> 
> If I have connected the dots correctly, the attack you are contemplating is
> sending a large stream of packets with different inner source addresses to an
> ETR.  This would prompt the ETR to check with the mapping system about
> each and every address.
[RPB] 
Exactly!

> 
> If I have understood this properly, while there are several very effective
> mitigations, that does not change the basic message that this is an attack, and
> as such ought to be described in the threats document.
[RPB] 
Even if there are effective mitigations, the attack should be described.

However, I am not convinced that an effective mitigation exists.

>   There are clealry a number of variations on this attack.
[RPB] 
True!

  For example, using
> the same outer source address makes mitigation easier, while using different
> outer source addresses either requires a bot-net or a large unchecked BCP38
> hole (and those can be used for MANY attacks on many
[RPB] 
Yes, both should be described.

Also, recall that large BCP38 holes exist in today's internet.

> Have I captured your request accurately?
[RPB] 
Pretty much.

Thanks for taking the effort.

                    Ron

> > */[RPB] Because ICMP is susceptible to DoS attacks, it wouldn't make a
> > very good routing protocol. That's why we don't use it for routing. By
> > XTR's LOC

---

From: Sharon <[email-masked]>
Date: Mon, 26 May 2014 09:06:21 -0700

Joel, thanks for clearing.
It was hard to follow.

If the challenge is for a distributed mapping system to keep track and protect itself from a "sick" xTR, sick because of a bug or an attack..
Then perhaps we could maintain mapping lookup per sec counters per xTR in the mapping. It adds some overhead to the mapping, but doesn't slow down forwarding. Can be aggregated by map servers for efficiency.

--szb

On May 26, 2014, at 8:46 AM, "Joel M. Halpern" <[email-masked]> wrote:

You asssert that any xTR is subject to a DoS attack.  And that such a DoS attack can render the mapping system unusable.

It targeting an ITR, this would need to be from within ths cope the ITR serves.  I believe that is discussed.

If I have connected the dots correctly, the attack you are contemplating is sending a large stream of packets with different inner source addresses to an ETR.  This would prompt the ETR to check with the mapping system about each and every address.

If I have understood this properly, while there are several very effective mitigations, that does not change the basic message that this is an attack, and as such ought to be described in the threats document.  There are clealry a number of variations on this attack.  For example, using the same outer source address makes mitigation easier, while using different outer source addresses either requires a bot-net or a large unchecked BCP38 hole (and those can be used for MANY attacks on many systems.)  Both presumably should be described.

Yours,
Joel

---

From: Paul Vinciguerra <[email-masked]>
Date: Mon, 26 May 2014 19:28:17 +0000

Every host on the Internet is subject to a DoS attack.  An xTR is no more so.  I am also not clear on how a DoS attack on an xTR would create any more risk than an attack directly against the mapping system.  

Joel describes Ronald's scenario of an attack where a large stream of packets with different inner source addresses to an ETR.  I don't call this an attack.  I call this our steady-state.  These would be the PxTR's we operate across the US.  The PxTR's on the beta-network are no different.  We take in packets from anywhere.  This is a "Free" attacker if you will.  All that really means is that you do not have to incur the computational cost of encapsulating the packet.

I would defer to Dino and others on the list, but I do not believe that the ETR does a reverse lookup on every packet.  At least that is not the behavior we observe.  What we see happen is that the packet is decapsulated and sent to the destination.  If a valid destination host responds, then the ITR does a map-request for the reply packet.  There is not a 1:1 relationship between the number of packets and the number of map-requests.

Map-replies for IP addresses return prefixes. These prefixes can cover larger address spaces than the map-request and limit the number of future map-requests needed.

Can you provide more specific details on how you see the xTR rendering the mapping system unusable? 

For what its worth, I still support the decision for last call and not to place mitigations within the document.  Without knowing the specifics of a configuration and implementation, that just leads to a false sense of security.  

________________________________________
From: lisp [[email-masked]] on behalf of Ronald Bonica [[email-masked]]
Sent: Monday, May 26, 2014 11:57 AM
To: Joel M. Halpern; Damien Saucez
Cc: Roger Jorgensen; LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats

Inline.....

[RPB]
Exactly!

[RPB]

[RPB]

[RPB]
Exactly!

[RPB]

[RPB]
True!

  For example, using
[RPB]

[RPB]
Pretty much.

                    Ron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 26 May 2014 15:34:31 -0400

It sounds like the PxTRs you are using are already implementing sensible 
mitigations.  But the base document does not actually call this out.

On the base document, the ETR can do gleaning (and by some readings 
mgiht be being encouraged to do so).  Because of the security threat 
from gleaning, and because the Etr wants to avoid the delay on returning 
traffic, nor use a false glean to direct returning traffic, there is 
text suggesting that the ETR would, immediately upon gleaning, check the 
information with the mapping system.

That would mean that a packet flow to an ETR (which all nodes are, as 
you say, subject to) could become a significant load on the mapping system.

Making different choices about when to learn or verify entries changes 
that dramatically.  But since the document does currently include the 
problematic behavior as legitimate, we need to document that it can 
cause problems.

I am glad to hear that sensible implementations are already dealing with 
this well.

Yours,
Joel

On 5/26/14, 3:28 PM, Paul Vinciguerra wrote:
> Every host on the Internet is subject to a DoS attack.  An xTR is no
> more so.  I am also not clear on how a DoS attack on an xTR would
> create any more risk than an attack directly against the mapping
> system.
>
> Joel describes Ronald's scenario of an attack where a large stream of
> packets with different inner source addresses to an ETR.  I don't
> call this an attack.  I call this our steady-state.  These would be
> the PxTR's we operate across the US.  The PxTR's on the beta-network
> are no different.  We take in packets from anywhere.  This is a
> "Free" attacker if you will.  All that really means is that you do
> not have to incur the computational cost of encapsulating the
> packet.
>
> I would defer to Dino and others on the list, but I do not believe
> that the ETR does a reverse lookup on every packet.  At least that is
> not the behavior we observe.  What we see happen is that the packet
> is decapsulated and sent to the destination.  If a valid destination
> host responds, then the ITR does a map-request for the reply packet.
> There is not a 1:1 relationship between the number of packets and the
> number of map-requests.
>
> Map-replies for IP addresses return prefixes. These prefixes can
> cover larger address spaces than the map-request and limit the number
> of future map-requests needed.
>
> For what its worth, I still support the decision for last call and
> not to place mitigations within the document.  Without knowing the
> specifics of a configuration and implementation, that just leads to a
> false sense of security.
>
>
> ________________________________________ From: lisp
> [[email-masked]] on behalf of Ronald Bonica
> [[email-masked]] Sent: Monday, May 26, 2014 11:57 AM To: Joel M.
> Halpern; Damien Saucez Cc: Roger Jorgensen; LISP mailing list list
>> [mailto:[email-masked]] Sent: Monday, May 26, 2014 11:47 AM
>> To: Ronald Bonica; Damien Saucez Cc: Roger Jorgensen; LISP mailing
>> list list Subject: Re: [lisp] Restarting last call on LISP threats
>>
>> You asssert that any xTR is subject to a DoS attack.  And that such
>> a DoS attack can render the mapping system unusable.
> [RPB] Exactly!
>
>>
> [RPB] I don't understand this sentence. Please try again.
>
> [RPB] Given that I don't understand the sentence above, I have no
> idea if this sentence is true.
>
>>
>> If I have connected the dots correctly, the attack you are
>> contemplating is sending a large stream of packets with different
>> inner source addresses to an ETR.  This would prompt the ETR to
>> check with the mapping system about each and every address.
> [RPB] Exactly!
>
>>
>> effective mitigations, that does not change the basic message that
>> this is an attack, and as such ought to be described in the threats
>> document.
> [RPB] Even if there are effective mitigations, the attack should be
> described.
>
> [RPB] True!
>> the same outer source address makes mitigation easier, while using
>> different outer source addresses either requires a bot-net or a
>> large unchecked BCP38 hole (and those can be used for MANY attacks
>> on many systems.)  Both presumably should be described.
> [RPB] Yes, both should be described.
>
> [RPB] Pretty much.
>>> *From:*Damien Saucez [mailto:[email-masked]] *Sent:*
>>> Friday, May 23, 2014 9:07 AM *To:* Ronald Bonica *Cc:* Dino
>>> Farinacci; Roger Jorgensen; LISP mailing list list *Subject:* Re:
>>> [lisp] Restarting last call on LISP threats
>>>
>>> Hello Ronald,
>>>
>>> Today's Internet is not as fragile as you think. This mail
>>> traversed many routers between my house and yours. If those
>>> routers are well-managed, there is nothing that I can do from my
>>> house that will cause any of those routers to consume control
>>> plane resources. Therefore, there is nothing that I can do from
>>> my house that will cause a DoS attack against those routers'
>>> control planes.
>>>
>>> */[RPB] Because ICMP is susceptible to DoS attacks, it wouldn't
>>> make a very good routing protocol. That's why we don't use it for
>>> routing. By contrast, LISP map-request messages are susceptible
>>> to DoS attacks and they do carry routing information./*
>>>
>>>
>>>
>>> control plane bandwidth, DoS attacks against the control plane
>>> are possible.
>>>
>>> In order to be complete, the threats document must describe the
>>> DoS threat. It should also describe mitigations, if any exist.
>>>
>>> -A DoS attack can be launched by anybody who can send a packet to
>>> the XTR's LOC
>>>
>>> -----Original Message----- From: Dino Farinacci
>>> [mailto:[email-masked]] Sent: Wednesday, May 21, 2014 6:58
>>> PM To: Ronald Bonica Cc: Roger Jorgensen; [email-masked]
>>> <mailto:[email-masked]> Subject: Re: [lisp] Restarting last call
>>> on LISP threats
>>>
>>>
>>> - an outer IP header (LOC->LOC) - a UDP header - a LISP Header -
>>> an IP header (EID->EID) - payload
>>>
>>>
>>> Just like a regular packet I can send to your home router today.
>>> So yes okay. So let's continue. See comments below.
>>>
>>>
>>> either the source LOC or source EID prefix. Rather than gleaning
>>> this mapping information from the crafted packet, the victim XTR
>>> sends a verifying MAP- REQUEST to the mapping system.
>>>
>>>
>>> that the XTRs rate limit for MAP-REQUEST messages is less than N
>>> packets per second. Has the attack not effectively DoS'd the
>>> victim XTR?
>>>
>>> It caches the rate the rate the packets are coming in and
>>> eventually stops sending Map-Requests completely.
>>>
>>> It cannot stop the incoming rate of packets today just like a
>>> roque BGP attacker can send millions of packets per second to a
>>> peer regardless if it does or does not have the peer
>>> authentication key.
>>>
>>>
>>> An implementation can detect that after rate limiting 1000s of
>>> such requests are happening that it just stops operation.
>>>
>>> The Internet is very fragile and LISP IS NOT making it worse. And
>>> in some cases it is making it better with integrated techniques.
>>>
>>> Dino
>>>
>>>
>>> list [email-masked] <mailto:[email-masked]>
> _______________________________________________ lisp mailing list

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 27 May 2014 00:58:43 -0700

Hello Joel et al.

interesting discussion. I wonder if other Internet protocols would have ever 
"made it" if they would have started with such an intense threat discussion 
as LISP does now :-)

Nevertheless, my understanding of what Ross and Ronald bring up is indeed a 
potential risk with any data-driven "pull" protocols like LISP: your data 
plane may overwhelm the data channel to the control plane.

One could argue this is an implementation aspect but as we go already into 
great detail in the draft maybe it's worthwhile to mention?

The discussion was IMHO too much focused on gleaning. LISP is made for a 
large number of EID networks. If e.g. someone scans the address ranges of an 
ISP and the PiTR(s) of the ISP have no forwarding entry then they need to 
send a map-request - a task typically done in control plane. Punting packets 
from data to control plane may saturate the punt channel for a time T, during 
which a legitimate request may not be processed.

To be fair, even for a large number of EID networks (e.g. lots of /29) the 
period T should not be more than several minutes (my guess, assuming 1k 
lookup per second) and it would not affect already established flows, only 
the establishment of new flows during the time T, assuming the (P)iTR can 
hold all the map-cache entries.

Regards, Marc

On Mon, 26 May 2014 15:34:31 -0400, Joel M. Halpern wrote:
> On the base document, the ETR can do gleaning (and by some readings mgiht 
> be being encouraged to do so).  Because of the security threat from 
> gleaning, and because the Etr wants to avoid the delay on returning 
> traffic, nor use a false glean to direct returning traffic, there is text 
> suggesting that the ETR would, immediately upon gleaning, check the 
> That would mean that a packet flow to an ETR (which all nodes are, as you 
> say, subject to) could become a significant load on the mapping system.
> 
> Making different choices about when to learn or verify entries changes that 
> dramatically.  But since the document does currently include the 
> problematic behavior as legitimate, we need to document that it can cause 
> problems.
>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 27 May 2014 14:17:05 +0000

Hi Sharon,

We may be talking about an XTR that is sick due to a bug or attack. We may also be talking about an attacker that isn't an XTR at all, just impersonating one.

                                                                              Ron

> From: Sharon [mailto:[email-masked]]
> Sent: Monday, May 26, 2014 12:06 PM
> To: Joel M. Halpern
> Cc: Ronald Bonica; Damien Saucez; Roger Jorgensen; LISP mailing list list
> If the challenge is for a distributed mapping system to keep track and protect
> itself from a "sick" xTR, sick because of a bug or an attack..
> Then perhaps we could maintain mapping lookup per sec counters per xTR in
> the mapping. It adds some overhead to the mapping, but doesn't slow down
> forwarding. Can be aggregated by map servers for efficiency.
> 
> --szb
> 
> as such ought to be described in the threats document.  There are clealry a
> number of variations on this attack.  For example, using the same outer
> source address makes mitigation easier, while using different outer source
> addresses either requires a bot-net or a large unchecked BCP38 hole (and
> those can be used for MANY attacks on many systems.)  Both presumably
> should be described.
> 
> >        this mapping
> >        packets
> >        roque BGP
> >        such requests

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 May 2014 08:04:42 -0700

> Also, recall that large BCP38 holes exist in today's internet.

And I am going to repeat again, this is not a binary statement. That is, if a BCP38 hole exists in one part of the network, source spoofing can still be detected in other parts of the network.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 May 2014 08:11:55 -0700

> I would defer to Dino and others on the list, but I do not believe that the ETR does a reverse lookup on every packet.  At least that is not the behavior we observe.  What we see happen is that the packet is decapsulated 

Right Paul. We did not document an ETR doing reverse lookups to solve this problem. When I mentioned it, I said it is something that COULD be done. It comes at a cost but wouldn't come at a per-packet cost, not even close. And as you said if the inner source is changing but the mapping system covers those addresses with a coarse prefix (that is returned from a lookup), then that reduces the number of RPF lookups, in addition to rate-limiting the number you do.

But I would suggest that implementations do what they are already doing. That is what you describe here:

> and sent to the destination.  If a valid destination host responds, then the ITR does a map-request for the reply packet.  There is not a 1:1 relationship between the number of packets and the number of map-requests.

The mapping system is no different in its load then the DNS system. We engineer and build that infrastructure the same way to protect it. 

So how many more magnitudes of hosts are sending DNS queries than xTRs sending Map-Requests (and please normalize this to every site having at least 2 xTRs per site).

We are over-reacting a bit, but just saying that is not going to calm fears. With continued experimentation and deployment, we will prove it.

Dino

P.S. Don't eat that burger today, it will kill you just like the cigarette you may smoke today.  ;-)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 May 2014 11:12:14 -0400

Can we please not get into a debate about how well BCP38 is or is not 
deployed, whether violations are remotely detectable, ...This is NOT the 
working group for that.

For our purposes, given that source address forging is known to occur, 
we have to allow it in the threat analysis.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 May 2014 08:17:14 -0700

> Can we please not get into a debate about how well BCP38 is or is not deployed, whether violations are remotely detectable, ...This is NOT the working group for that.

The point is that LISP makes spoofing no worse even though many think that it could because there are more addreses in the packet to manipulate. This aspect is on topic.

> For our purposes, given that source address forging is known to occur, we have to allow it in the threat analysis.

I agree.

Dino

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 27 May 2014 15:23:41 +0000

Hi Roland, Got it. Tnx.

 I thought that since the mapping is in the underlay, then existing underlay protections apply.. unless "outerlay" elements use the XTRs in order to indirectly attack the mapping service.
I thought that's what you meant.. 

And that the problem of why this is not a trivial throttling is because the mapping itself is distributed so no one place can identify the XTR being leveraged for the attack. That's why I thought keeping an mapping internal lcaf/counter-Schema can help.

But I think Joel is correct, and let's first phrase the problem.
Thanks for the clarification.

--szb

On May 27, 2014, at 7:17 AM, "Ronald Bonica" <[email-masked]> wrote:

Hi Sharon,

                                                                             Ron

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 May 2014 08:49:42 -0700

Ross, see my responses inline.

> (1) The Control Plane Threat: LISP allows a dataplane DOS attack (lots of packets sent to overwhelm a site) to turn into a control plane attack (the router is forced to respond to the attack in the…

It turns into a control-plane request stream which is many orders of magnitude less than the data packet stream. And since the data-plane bandwidth to the control-plane bandwidth inside of the xTR is also orders of magnitude of difference, you will find this will protect the mapping database control-plane.

That is, no router control-plane will be capable of sending Map-Requests at any rate faster than at least 2 orders of magnitude of what the control-plane in that router implementation can do. And then, if this xTR will rate-limit on top of the Map-Request rate, it is even slower.

This is not speculation. This has been proven with many different implementation attempts over the last 7 years.

> (2) The Privacy Threat: LISP provides an attacker with a relatively easy way to determine the identity of large numbers of PE and/or CE routers (globally, if LISP is deployed on that level) .

We should document this, but there are tons of easily accessible databases in protocols, operational data structures, key management data, and application systems that do this as well.

But LISP can encrypt or require authentication of this information, so it can be hidden from potential attackers.

When we built the mapping database system, we wanted it to look like DNS for scale and accessiblility but knew the security concerns and hence why we have several mechanisms to allow a mapping database to be a closed system, even at Internet scale.

> (3) the Traffic Gleaning Threat: If an xTR gleans EID -> RLOC mappings from incoming packets, this provides an easy way for hackers to intercept traffic. I put this threat third because gleaning ca…

This is why the spec says MAY for data gleaning. We put this in the main specification because in closed enterprise environments people wanted this feature.

> WRT the first of these, Dino has pointed out that the control plane of routers already receive BGP packets from sources outside their domain. Thus a DOS attack on the control plane of routers can be launched through BGP. 

I don't want to make this a LISP versus BGP debate. Because if we do, we won't make any progress.

But with a centrally managed database system, you can put controls in without getting an entire Internet peering topology to buy in. The security systems we can put into the mapping database, can be incrementally added and provide benefit to xTRs that don't even know what was added.

The mapping database is distributed like DNS to scale but managed centrally. And I am not talking about using SDN type approaches either to achieve this.

> However, the number of BGP peers that a router has is limited, and can be known a priori. Thus it is possible, and relatively common, for a router to be configured to only accept BGP updates from a very limited number of identified other routers (in many cases a moderate number of external peers plus a few internal route reflectors). Each of these known BGP sessions can be individually rate limited, and no other source can be allowed to send BGP updates to the router. Also, other control traffic to the router can be limited to internal peers (eg, OSPF, IS-IS, LDP, and/or RSVP from other internal routers, plus network management traffic from internal sources only). Thus today every source of control plane traffic to the router can be controlled and rate limited. For C

If you compare the IGPs and protocols that run inside of an AS with LISP, then LISP has all the same benefits because a single organization is managing the architecture, so they can decide unilaterally decide how much security, gleaning, uRPFing they use.

I often compare LISP to BGP because of the scale we want LISP to grow to. 

> E routers the number of BGP peers can be even more limited, possibly to one (the PE) or even none (for stub domains use manually configured static routes). 
> 
> If LISP were ubiquitously and globally deployed across the Internet, then mapping requests could come from pretty much anywhere. Similarly incoming data plane traffic which contains EID's that are not currently listed

But those Map-Requests can be authenticated if the attacker chose a Map-Resolver that wanted to operate at a high security level.

There will always be open Map-Resolvers (just like DNS server 8.8.8.8) which has to scale for good and bad requests. Those systems have dozens of implementation techniques to do signature detection and mitigation of suspicious packet-request trains.

>  in your EID -> RLOC mapping would cause a mapping request to be generated in the control plane. I understand that mapping requests (both incoming and outgoing) can be rate limited, but this simply turns a "shut down the router's control plane" attack to turn into a "shut down the router's mapping function" attack. If correct operation relies on the mapping function, then you have still broken the router. 

You have to couple rate-limiting with some cacheing and timing information.

> The second of these is a big deal which has not been talked about much. We don't want hackers to know the identity of all PE and/or CE routers. It is difficult to fully anticipate what attacks will…

If I traceroute to your house Ross, I know all routers on the path. LISP does not make this problem worse. 

And we cannot practically say every weakness in the Internet is also a weakness in LISP, so we may as well not deploy LISP. That will give people the wrong impression. We want to be honest and document threats, but we can't get out of hand, because we will ALWAYs be incomplete.

And the danger and effort spent on LISP will be what it can't do rather than what new things it brings to the Internet.

> http://www.wired.com/2013/12/bgp-hijacking-belarus-iceland/   

I recommend that no one use data-packet gleaning in an ETR unless the mapping system knows all sources sending map-requests to a closed and control mapping system.

Data-plane gleaning should not be used generally on the capital-I Internet.

Dino

---

From: Damien Saucez <[email-masked]>
Date: Tue, 27 May 2014 18:05:55 +0200

Dear all,

Thank you all for the passion you put in discussing the threats
document.  We have read all the arguments and arrived to the
conclusion that the threat document needs to be reshaped so to clear
all misunderstandings.  We will provide a new version for early July
that does not exclude any scenarios.  Actually most of problems
pinpointed are already covered somehow in the document but
precisions/rephrasing have to be done to make things clear.

For the sake of efficiency, while writing the new proposal in the
coming weeks, we will make point-to-point exchanges with the different
people that contributed to the discussion so to be sure that we
address all their comments.

Thanks,

Damien Saucez

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 27 May 2014 22:45:02 +0000

Hi Paul,

The attack scenario that I envision is slightly different from the on that you describe below:

- LISP is widely deployed. Tens of thousands of XTRs are deployed world-wide. The mapping system data base contains hundreds of thousands of EID prefixes.
- The attack stream is large
- Each packet in the attack stream has a unique source LOC
- All packets in the attack stream have the same destination LOC. This LOC represents the XTR under attack.
- Each packet in the attack stream has a destination EID that will cause it to reach a valid destination (i.e., a destination that will respond). However, all packets in the attack stream don't have the same destination. The attack stream is spread out across multiple valid EID destinations to make it less detectable.
- Each packet in the attack stream has a carefully chosen source EID. It is chosen to maximize the ratio of attack packets to map-requests.

One attack stream attacks an XTR. Multiple simultaneous attacks against multiple XTRs can DoS the mapping system, itself.

A PxTR probably won't generate this attack stream. However, an attack tool might.

Hope this helps.

                                                            Ron

> From: Paul Vinciguerra [mailto:[email-masked]]
> Sent: Monday, May 26, 2014 3:28 PM
> To: Ronald Bonica; Joel M. Halpern; Damien Saucez
> Every host on the Internet is subject to a DoS attack.  An xTR is no more so.  I
> am also not clear on how a DoS attack on an xTR would create any more risk
> than an attack directly against the mapping system.
> 
> Joel describes Ronald's scenario of an attack where a large stream of packets
> with different inner source addresses to an ETR.  I don't call this an attack.  I
> call this our steady-state.  These would be the PxTR's we operate across the
> US.  The PxTR's on the beta-network are no different.  We take in packets
> from anywhere.  This is a "Free" attacker if you will.  All that really means is
> that you do not have to incur the computational cost of encapsulating the
> packet.
> 
> I would defer to Dino and others on the list, but I do not believe that the ETR
> does a reverse lookup on every packet.  At least that is not the behavior we
> observe.  What we see happen is that the packet is decapsulated and sent to
> the destination.  If a valid destination host responds, then the ITR does a
> map-request for the reply packet.  There is not a 1:1 relationship between
> the number of packets and the number of map-requests.
> 
> Map-replies for IP addresses return prefixes. These prefixes can cover larger
> address spaces than the map-request and limit the number of future map-
> requests needed.
> 
> For what its worth, I still support the decision for last call and not to place
> mitigations within the document.  Without knowing the specifics of a
> configuration and implementation, that just leads to a false sense of security.
> 
> 
> serves.
> > inner source addresses to an ETR.  This would prompt the ETR to check
> > with the mapping system about each and every address.
> [RPB]
> Exactly!
> 
> >
> > > */[RPB] Because ICMP is susceptible to DoS attacks, it wouldn't make
> > > a very good routing protocol. That's why we don't use it for
> > > routing. By contrast, LISP map-request messages are susceptible to
> > > DoS attacks and they do carry routing information./*
> > >
> > >
> > >

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 27 May 2014 22:54:46 +0000

> large number of EID networks. If e.g. someone scans the address ranges of
> an ISP and the PiTR(s) of the ISP have no forwarding entry then they need to
[RPB] 
Agreed. The attack scenario that I describe in my previous message relies neither on gleening nor source address spoofing.

> hold all the map-cache entries.
[RPB] 
Also agreed. We should say something in a threats document about the relationship between period T and the size of memory available for the map-cache.

> > It sounds like the PxTRs you are using are already implementing
> > sensible mitigations.  But the base document does not actually call this out.
> >
> > from gleaning, and because the Etr wants to avoid the delay on
> > returning traffic, nor use a false glean to direct returning traffic,
> > there is text suggesting that the ETR would, immediately upon
> > gleaning, check the information with the mapping system.
> >
> > I am glad to hear that sensible implementations are already dealing
> > with this well.
> >
> > Yours,
> > Joel
> >
> >> not have to incur the computational cost of encapsulating the packet.
> >>
> >>>> traversed many routers between my house and yours. If those routers
> >>>> are well-managed, there is nothing that I can do from my house that
> >>>> will cause any of those routers to consume control plane resources.
> >>>> [mailto:[email-masked]] Sent: Wednesday, May 21, 2014 6:58 PM
> >>>> To: Ronald Bonica Cc: Roger Jorgensen; [email-masked]
> >>>> <mailto:[email-masked]> Subject: Re: [lisp] Restarting last call on
> >>>> LISP threats
> >>>>
> >>>>
> >>>> - an outer IP header (LOC->LOC) - a UDP header - a LISP Header - an
> >>>> IP header (EID->EID) - payload
> >>>>
> >>>>
> >>>> packets per second. Has the attack not effectively DoS'd the victim
> >>>> XTR?
> >>>>
> >>>> It cannot stop the incoming rate of packets today just like a roque
> >>>> BGP attacker can send millions of packets per second to a peer
> >>>> regardless if it does or does not have the peer authentication key.
> >>>>
> >>>>
> >>>> An implementation can detect that after rate limiting 1000s of such
> >>>> requests are happening that it just stops operation.
> >>>>
> list

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 May 2014 16:18:37 -0700

> A PxTR probably won't generate this attack stream. However, an attack tool might.

Ignoring the unique source RLOC (which makes no difference in this attack because we are not doing a RPF check on the ETR), it is the same as if a PITR was encapsulating from the same set of source-EIDs to the same set of destination-EIDs you describe above.

That was his point.

So some clarifications:

(1) What does unique source LOC mean? I assume you mean each packet as a different source RLOC and that the address is not duplicated from multiple sites (i.e. is it not a private address like 192.168.1.1), or do you meawn something else?

(2) And what is carefully chosen mean? You might mean a scan of differnet source EIDs in each packet so the xTR that returns packets will get more map-cache misses? 

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 28 May 2014 00:18:29 +0000

Inline....

> Sent: Tuesday, May 27, 2014 7:19 PM
> To: Ronald Bonica
> Cc: Paul Vinciguerra; Joel M. Halpern; Damien Saucez; Roger Jorgensen; LISP
> mailing list list
> > - LISP is widely deployed. Tens of thousands of XTRs are deployed world-
> wide. The mapping system data base contains hundreds of thousands of EID
> prefixes.
> > - Each packet in the attack stream has a destination EID that will cause it to
> reach a valid destination (i.e., a destination that will respond). However, all
> packets in the attack stream don't have the same destination. The attack
> stream is spread out across multiple valid EID destinations to make it less
> detectable.
> > - Each packet in the attack stream has a carefully chosen source EID. It is
> chosen to maximize the ratio of attack packets to map-requests.
> >
> > One attack stream attacks an XTR. Multiple simultaneous attacks against
> multiple XTRs can DoS the mapping system, itself.
> >
> Ignoring the unique source RLOC (which makes no difference in this attack
> because we are not doing a RPF check on the ETR), it is the same as if a PITR
> was encapsulating from the same set of source-EIDs to the same set of
> destination-EIDs you describe above.
> 
> That was his point.
> 
> So some clarifications:
> 
> (1) What does unique source LOC mean? I assume you mean each packet as
> a different source RLOC and that the address is not duplicated from multiple
> sites (i.e. is it not a private address like 192.168.1.1), or do you meawn
> something else?
[RPB] 
No two packets in the attack stream have the same Source RLOC.

> 
> (2) And what is carefully chosen mean? You might mean a scan of differnet
> source EIDs in each packet so the xTR that returns packets will get more map-
> cache misses?
[RPB] 
Exactly. Source EIDs are chosen to maximize the ratio of attack packets to map-requests sent by the victim XTR.

This is what make the attack stream so different from a stream that a PiTR is likely to send during normal operation.

                                                                                                 Ron

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 May 2014 18:12:24 -0700

> On May 27, 2014, at 5:18 PM, Ronald Bonica <[email-masked]> wrote:
> 
> RPB] 

It is not different for that reason. It is different because packets encapsulated by PITRs originate from non-LISP sources. Thereby the ITR at the LISP site will natively-forward to those random places. And those native-forward map-cache entries are very coarse since the mapping system returns the least specific prefix that covers all non-LISP sites. 

I believe Paul is still right IMO. 

Dino

---

From: Florin Coras <[email-masked]>
Date: Wed, 28 May 2014 07:50:35 +0200

Hi Ron,

It turns out that just doing a flat scan of the EID-prefix space, i.e., 
using as source EID an IP in each existing EID-prefix, has the most 
damaging consequences (see fig. 5 in [1]). This, if you contrast it with 
the case when you try to craft packets whose replies (coming from 
intra-domain sources) will always generate misses in the xTR under attack.

If the attack intensity (attack packet rate to legitimate traffic rate 
ratio) is high, say above 0.01, you are right to assume that such an 
attack could cripple an xTR and generate lots of misses. However, as we 
mention in the paper, some simple solutions could be set in place to 
avoid this. For instance:

1) When the attack is detected (due to the higher than normal miss 
rate), the most important entries in the cache, the most popular (say, 
Google, Fb, Amazon ..) can be protected from eviction. Thereby, on the 
one hand, set up flows won't have their entries evicted and on the 
other, this set of entries will ensure that a very large part of the new 
outgoing flows will cache hit.

2) Just add more memory! Besides the TCAM in the xTR we could use a 
large second level memory able to cache the whole EID address space.  
Alternatively, you could imagine having an xTR per site, capable of 
holding the whole EID address space, that could act as default for 
packets that miss in all the other sub-provisioned xTRs.

[1] http://arxiv.org/pdf/1312.1378v2.pdf

Florin

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 28 May 2014 00:37:56 -0700

Hello Florin et al.,

interesting discussion and I think some aspects should continue to be 
discussed. But I start wondering: where is this thread heading? It doesn't 
seem to move forward with respect to the "last call" topic :-)

Florin, your reply seems to indicate that Ronald's scenario is a valid attack 
as you describe mitigation strategies. But is Ronald's scenario really _new_ 
with respect to the draft?  It seems to be covered by section 4.2/4.3.1.1 (?).

If the opinion is that Ron's scenario is not covered by the draft yet then do 
we need additional text in the draft?  Any proposal, Ron?

Myself I'm expecting from the draft that it provides an overview of the 
potential problems and some attack vectors to stimulate ideas. I do not 
assume that the level of details in the draft and the "relevance" of the 
attack correspond - what is relevant or not may depend on whom you ask. 

Thanks & Regards,
Marc

On Wed, 28 May 2014 07:50:35 +0200, Florin Coras wrote:
> ratio) is high, say above 0.01, you are right to assume that such an attack 
> could cripple an xTR and generate lots of misses. However, as we mention in 
> the paper, some simple solutions could be set in place to avoid this. For 
> instance:
> 
> 1) When the attack is detected (due to the higher than normal miss rate), 
> the most important entries in the cache, the most popular (say, Google, Fb, 
> Amazon ..) can be protected from eviction. Thereby, on the one hand, set up 
> flows won't have their entries evicted and on the other, this set of 
> entries will ensure that a very large part of the new outgoing flows will 
> cache hit.
> 
> 2) Just add more memory! Besides the TCAM in the xTR we could use a large 
> second level memory able to cache the whole EID address space.  
> Alternatively, you could imagine having an xTR per site, capable of holding 
> the whole EID address space, that could act as default for packets that 
> miss in all the other sub-provisioned xTRs.
> 
>> - LISP is widely deployed. Tens of thousands of XTRs are deployed 
>> world-wide. The mapping system data base contains hundreds of thousands of 
>> EID prefixes.
>> - Each packet in the attack stream has a destination EID that will cause 
>> it to reach a valid destination (i.e., a destination that will respond). 
>> However, all packets in the attack stream don't have the same destination. 
>> The attack stream is spread out across multiple valid EID destinations to 
>> make it less detectable.
>> - Each packet in the attack stream has a carefully chosen source EID. It 
>> is chosen to maximize the ratio of attack packets to map-requests.
>> 
>>>>> traversed
>>>>>              Assume that the attack flow is large (N packets per 
>>>>> second).
>>>>>              Assume also
>>>>>

---

From: Florin Coras <[email-masked]>
Date: Wed, 28 May 2014 10:50:27 +0200

Hi Marc,

Thanks for the reply and apologies for not being clear enough. More inline.

> with respect to the draft?  It seems to be covered by section 4.2/4.3.1.1 (?).
It is. We've previously had discussions concerning cache poisoning on 
the mailing list and I wrongly assumed the subject as 
known-and-documented in the draft. In fact, Damien mentioned this 
several times in his replies. My previous email was only meant to bring 
this up to Ron's attention and answer his specific concerns.

So, to clear up the confusion: Section 4.2 already mentions cache 
poisoning attacks and offers a pointer to an analysis and possible 
mitigation strategies.

> we need additional text in the draft?  Any proposal, Ron?

IMO, we do not need additional text.

Regards,
Florin

---

From: Ross Callon <[email-masked]>
Date: Wed, 28 May 2014 17:52:55 +0000

Thanks for agreeing to update the document. I would be happy to contribute to discussions related to the update. Please include me on the appropriate point to point exchanges. 

Thanks, Ross

-----Original Message-----
From: lisp [mailto:[email-masked]] On Behalf Of Damien Saucez
Sent: Tuesday, May 27, 2014 12:06 PM
To: LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats

Dear all,

Thanks,

Damien Saucez

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 May 2014 11:31:03 -0700

> Thanks for agreeing to update the document. I would be happy to contribute to discussions related to the update. Please include me on the appropriate point to point exchanges. 

Thanks a lot Ross. And I'd be willing to help with the document that identifies mitigation techniques to each of the threats in the threats document.

Dino