Subject: [lisp] Need comments on LISP Threats Analysis

From: Damien Saucez <[email-masked]>
Date: Fri, 15 Mar 2013 09:55:50 -0400

Dear all,

As requested by chairs in today's meeting we would like to ask you to
comment on the threats analysis.

Here are the there questions that must be precisely answered by you:

1. are the 4 severity levels well defined? (do you see intermediate levels?)

2. do you agree with the level of severity given for each threat (yes/no/why)?

3. if a feature has to be deactivated, do you agree for having it deactivated?

Thank you.

Damien Saucez

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 20 Mar 2013 14:31:27 +0000

Hi Damien,

I am not sure that Threat Level 2 is appropriate in Section 5.2  (EID-to-RLOC Cache Threats). This is because the threats described in Section 5.2.2 (EID-to-RLOC Cache overflow) may be more difficult to mitigate than we realize.

In Section 5.2.2, you consider scenarios in which "an attacker could try to fill the cache with fake mappings." However, you do not consider scenarios in which an attacker behind LR1 attacks LR3 and LR4 by causing multiple devices behind LR4 and LR4 to send traffic to a wide variety of prefixes. This makes the caches in LR3 and LR4 overflow with legitimate mappings. 

I can think of mitigations to this class of attacks, but they all require LR1 to protect LR2 and LR3.

                                                          Ron

P.S. More comments to follow.

---

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

Damien,

Also regarding EID-to-RLOC Cache overflow, in Paragraph 3 of Section 5.4, you suggest that an ETR, upon receiving a LISP encapsulated packet, might consult its EID-to-RLOC Cache to verify that the sending RLOC is authorized to originate traffic from the packet's source EID. If the ETR does not have a map entry for that EID, it might originate a Map-Request for the EID.

Might SA use this behavior to overflow the ETRs map-cache? What would happen if SA sent a sustained flow of packets, spoofing many RLOCs and many EID prefixes. The victim ETR has three options:

1) pass each packet without verification
2) query the map cache for each packet. If no entry exists, discard the packet and do not query the map server
3) query the map cache for each packet. If no entry exists, discard the packet and query the map server

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

Option #2 appears to be a non-starter.

Option #1 leaves you open to other types of attacks.

                             Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Damien Saucez
> Sent: Friday, March 15, 2013 9:56 AM
> To: LISP mailing list list
> Subject: [lisp] Need comments on LISP Threats Analysis
> 
> Dear all,
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Mar 2013 09:39:47 -0700

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

4) Create an entry in another data structure which is smaller and has compressed entries in it. So verification checks can be done quickly and less often the need to do MDB lookups. 

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 20 Mar 2013 16:46:23 +0000

Dino,

Do you agree that Options 1, 2 and 3 are all bad ideas? 

Also, before I ask a dumb question, can you point me at something that I can read that describes how the entry in Option 4 is used? If not, could you provide some detail?

                                  Ron

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2013 12:40 PM
> To: Ronald Bonica
> Cc: Damien Saucez; LISP mailing list list
> Subject: Re: [lisp] Need comments on LISP Threats Analysis
> 
> > 2) query the map cache for each packet. If no entry exists, discard
> the packet and do not query the map server
> 4) Create an entry in another data structure which is smaller and has
> compressed entries in it. So verification checks can be done quickly
> and less often the need to do MDB lookups.
> 
> Dino

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 20 Mar 2013 17:31:59 +0000

Damien,

I am not sure that Threat Level 1 is appropriate in Section 6.1 (Attacks With Map-Request Messages). Again, this attack may be harder to mitigate than we realize.

Consider the attack that you describe in Paragraph 5 of Section 6.1. Assume that the attacker runs that attack, not with the goal of overrunning the ITR with Map-Reply messages, but with the goal of hitting the victim ITRs rate limit for Map-Reply messages on the ETR. When SA causes that rate limit to be hit, he makes it difficult for the ITR to obtain mappings outside of 192.0.2.0/24 from ETR that is involved.

                                        Ron

---

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

> Do you agree that Options 1, 2 and 3 are all bad ideas?

I can't with a binary answer. 

Without verification (option 1) is the way most implementations will go. Just like we don't do source checks on every router by default today. 

Option 2 is definitely useful if the map-cache entry is already there. Should one create one by doing a lookup. Well that is a lot of work and would have scaling implications if not rate-limited properly from a message rate as well as a cache size perspective. 

> Also, before I ask a dumb question, can you point me at something that I can read that describes how the entry in Option 4 is used? If not, could you provide some detail?

There is nothing to read. It was a newer idea. Not all good (and bad ideas) are written down but could be hidden in code. :-)

Dino

---

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

Inline....

> Sent: Wednesday, March 20, 2013 2:15 PM
> To: Ronald Bonica
> Without verification (option 1) is the way most implementations will
> go. Just like we don't do source checks on every router by default
> today.

Just to be sure that I am understanding your words...

An implementation (e.g., IOS version x.y.z) may support multiple options. A specific XTR will select one or more implemented options by configuration.

Do I have that right?

> 
> Option 2 is definitely useful if the map-cache entry is already there.
> Should one create one by doing a lookup. Well that is a lot of work and
> would have scaling implications if not rate-limited properly from a
> message rate as well as a cache size perspective.

I should have been more specific about expressing Option 2. I should have read:

2) Query the map-cache. If an entry exists and it indicates that the RLOC is authorized to originate traffic sourced by the EID, pass the packet. If an entry exists and it indicates that the RLOC is not authorized to originate traffic sourced by the EID, discard the packet.

2a) if no entry exists, pass the packet, without sending a map-request
2b) if no entry exists, discard the packet without sending a map-request

Option 2b is the non-starter. Option 2a is only a slight improvement over #1 because, in the attack that I describe, the map-entry is not very likely to be present. Option 

> 
> > Also, before I ask a dumb question, can you point me at something
> that I can read that describes how the entry in Option 4 is used? If
> not, could you provide some detail?
> 
> There is nothing to read. It was a newer idea. Not all good (and bad
> ideas) are written down but could be hidden in code. :-)

        :-)

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Mar 2013 15:09:50 -0700

> An implementation (e.g., IOS version x.y.z) may support multiple options. A specific XTR will select one or more implemented options by configuration.

That could be a way to go yes.

> Option 2b is the non-starter. Option 2a is only a slight improvement over #1 because, in the attack that I describe, the map-entry is not very likely to be present. Option 

Did you not finish writing? Looks like you were done with a trailing word "Option" or you were going to begin something and didn't finish the sentence.

Dino