Subject: [lisp] LISP Threats Document Review

From: Darrel Lewis <[email-masked]>
Date: Thu, 10 Jan 2013 09:40:17 -0800

Authors,

Overall this is a really meticulous document- it's clear that the authors have spent a lot of time thinking about security threats as they relate to the LISP protocol.  Most of my comments below are about wording and organization, there is only a few technical questions/comments.  

Comments to section 1: Introduction:

 Might want to add a note that the security evaluation is only from the perspective
 of use of LISP on the public Internet for the use of multi-homing (which is inferred 
 by the fact that the LISP specifications are only for that use case).  
 
 I believe this document would also benefit from some overall statement regarding
 the paramaters and posture of the analysis.  I.E. what standard are we evaluating
 the protocol against?  I think this intent is already in the document - that 
 this document is supposed to see how the LISP protocol might change the posture of
 networks that deploy it, vs networks that do not deploy LISP.

 In addition, section 8 doesn't seem to fit into the flow of the document.  It might 
 to fit better within the xTR threats section… having an outline that covers xTR
 (control/data), Interworking Components, Mapping System components in succession.
 
 Finally, this document could use a summary - either in each of the major subsections
 (control and data plane) or at the end, summarizing the threats and determining
 if there are any unmitigated vulnerabilities.  The recommendation section is a good
 section, but doesn't align exactly with the flow of the draft.  So I found it hard
 to find if there are any serious un-mitigated threats in the protocol or
 implementation.
 
 Comments to section 3: On Path Attackers
 
 "We do not consider that LISP has to cope with such kind of attackers."   Seems wordy
 and may hide some meaning.  I think you mean that the authors agree with the LISP
 protocol's design decision to not consider this type of threat.  Maybe a clear 
 statement like:  "As with IP, LISP relies on higher layer cryptography to secure 
 packet payloads from on path attacks".
  
  The second paragraph of this describes in detail something you are not going to consider
  (a subset of on-path attackers using time-shifted replay attacks) something that 
  while interesting I'm not sure is important given that you've already decided not
  to consider on-path attacks in the first paragraph.  I would consider deleting - maybe
  adding a parenthetical reference (including time-shifted replay attacks) in the first
  paragraph of section 3.
  
  Comments to 4: Off Path Attackers Reference environment
  
  Is there a reason why LR1 and LR2 connect to ISP-1 and ISP-2, while LR3 and LR4 
  connect only to 'Internet'?  I don't think it matters but I am just curious if
  you did it for a reason.
  
  Comments to 5.x)  
  
  A general comment about section 5 - many of these data plane black-holing
  issues are no different than IP - if I corrupt the IP data-plane  (BGP) then
  I can black-hole traffic.  I think its important to note that (like you did
  in section 4) where LISP is different or introduces new potential vulnerabilities.
  I think the difference from IP+BGP is mainly in its ability to encapsulate and
  redirect things to arbitrary destinations.  A short statement about this would 
  help put this section in context.

  Further down in the section:
  
   "A key component of the overall LISP architecture is the EID-to-RLOC
   Cache.  The EID-to-RLOC Cache is the data structure that stores the
   bindings between EID and RLOC (namely the "mappings") to be used
   later on."
   
   Is a little unclear to me. It might be clearer to say in the second sentance:
   
 " The EID-to-RLOC Cache (also called the Map-Cache) is the data structure that
   stores a copy of of the mapping retrieved from a remote ETR's mapping database
   via the LISP control plane." 
   
   So the above may not be great wording either, but the point I am trying to make 
   is that the map-cache is a copy of the ETR's map-database, which is generally 
   stored until replaced by a new mapping, or the mapping's TTL expires.
   
   In general this document uses the word 'can' to describe a possible attack 
   scenario.  I would think it would be better to say 'could', which is a minor
   nit but one that kept coming to mind as I read the document.
   
   Comments to section 5.2)
   
   This section, located in the data plane, has many repetitive references to 
   using the control plane to insert information into the map-cache data structure.
   When ever I see a list of 8 paragraphs all with similar wording at the end,
   (similarly to abive, again, again, etc) :-) I suggest revising these paragraphs
   structure.
   
  In this specific case. I think its appropriate to say that the ITR implementation
  can only, in general, trust what it learns from the control plane.  Compromising 
  the control plane therefor will compromise the integrity and correctness of any 
  copies made of this control plane's data (the map-cache).  You could then 
  serially list the Bad Things (TM) that could happen once the Control Plane 
  is compromised.

  Some further comments on the individual attacks you mention:
  
  (Reachability poisoning:) .... "If reachability information is not verified
         through the control-plane this attack can be simply achieved by
         sending a spoofed packet with swapped or all locator status
         bits reset."
         
         "simply achieved" I think is a qualitative analysis that should not be
         here - I would reword to say "this attack could be achieved" .
  
   Instance ID poisoning:  The LISP protocol allows using a 24-bit
         identifier to select the forwarding table to use on the
         decapsulating ETR to forward the decapsulated packet.  By
         spoofing this attribute the attacker is able to redirect or
         blackhole inbound traffic. 

    I think you mean, above, that by spoofing the IID value the attacker
    might be able to cause traffic to be either be dropped or decapsulated
    and then placed into the incorrect VRF at the destination ETR... is that 
    correct?
    
  "If the above listed attacks succeed, the attacker has the means of
   controlling the traffic."
   
   This seems an over-broad summary of the above.  I suggest something like:  
   
   "If the ITR's map-cache is compromised (likely via compromising the LISP 
   control plane) it is possible that traffic may be redirected (encapsulated 
   to the wrong destination) a or dropped by the ITR."
  
   It might also be good to make a recommendation that if data plane redirection
   is of a critical concern, then deploying some sort of IPSEC or TLS based security
   on a layer above LISP (just like you would on top of IP) is a good idea.
   
   Comments on section 5.4.1:
   
  "Rate limitation, as described in
   [I-D.ietf-lisp], does not allow sending high number of such a
   request, resulting in the attacker saturating the rate with these
   spoofed packets."
   
   The above assumes the implementation of the rate-limiter is primitive enough
   to classify map-requests generated by these types of failures to be classified.
   and limited, in the same bucket as map-requests generated by (legitimate) 
   data packets.  It might be better to make a recommendation - that indeed
   implementations should consider the instigation of the map-request - a data-packet 
   (and even from which source EID), SMR, reverse cache check failure, and selectively
    limit each accordingly.   Section 11 has a nice description of this - and seems
    to be in contradiction to the claims in the above sections.
   
   Comments on section 5.4.2:
   
   Maybe it should be noted that Map-Versioning is an optional part of the LISP protocol
   and not all implementations support it.  "If map-versioning has been implemented by 
   an xTR..")
   
   My comments to section 5.4.1 regarding rate-limiting apply here too, I think.
   
   Comments on section 5.4.4: 
   
   I think the title should read "instance id' instead of "id instance'
   
   Comments on Section 6.1:
   
      "The first possible exploitation is the P bit.  The P bit is used to
   probe the reachability of remote ETRs in the control plane."  
   
   Usually map-requests with the probe bit sent are sent from the the ITR's RLOC to 
   the ETR's RLOC.  Since sending them via the control plane might not guarantee that
   they arrive on the appropriate ETR.
   
   " Furthermore, appending Map-Records to Map-Request messages represents
   a major security risk since an off-path attacker could generate a
   (spoofed or not) Map-Request message and include in the Map-Reply
   portion of the message mapping for EID prefixes that it does not
   serve."
   
   While some sites have chosen to accept those security risks and use gleaning,
   I agree that (like your earlier reference to trusting LSBs), gleaning is 
   best used in more trusted environments, rather than the public Internet. In 
   addition, I think this paragraph should reference section 6.3.
   
   Comments on Section 6.2:
   
   "Negative Map-Reply messages are used to support PTR and interconnect
   the LISP Internet with the legacy Internet."
   
   I think you mean to say that Negative map-reply messages are used to indicate
   non-lisp prefixes.  ITRs can, if needed, be configured to send all traffic destined for 
   non-lisp prefixes to a Proxy-ETR.
   
   "Note, however, that the nonce only confirms that the Map-Reply was
   sent by the ETR that received the Map-Request.  It does not validate
   the content of the Map-Reply message."
   
   While the above seems correct, I had to read the text three times to make
   sure (was it originally written by Dino? :-)).  It might be clearer to say 
   "the nonce only confirms that the map-reply received was sent in response to
   a map-request sent', it does not validate the contents of that map-reply.
   
   "In addition, an attacker can perform EID-to-RLOC Cache overflow
   attack by de-aggregating (i.e., splitting an EID prefix into
   artificially smaller EID prefixes) either positive or negative
   mappings."
   
   I'm not sure I follow the above, in a couple of different ways.  First,
   it seems you are suggesting that a malicious ETR might fragment its 
   eid-to-rloc database and then instigate traffic to its site, therefor creating
   alot of state on the corresponding ITR's map-cache.  But this doesn't follow 
   the theme of the rest of the section which talks about off-path attackers
   sending map-replies.  Second, you mention that this type of thing 
   could occur with negative mappings.  I can only imagine this happening with
   negative mappings in the case where an ETR, in conjunction with a mapping
   service provider's Map-Server, allowed for such de-aggregation into the 
   control plane (DDT or ALT), or if a map-resolver was compromised and crafting
   specifically bogus information.   Neither of these scenarios seems in scope
   with the rest of the section.  I would recommend removing this paragraph.
   
   Comments on section 6.3:
   
   I suggest either an intro or summary (or both) to this very detailed section 
   that sums up what you want to say, which I think is:
   
   "Appending Map-Data into Map-Requests, and then having an ETR glean that information
   on receipt of said map-request, bypasses all security protections of the LISP control
   plane.  It is slightly less evil if used with verification.   Therefor we 
   recommend you do not do it unless you have a damn good reason to do so, or are in 
   a trusted (read, not the public internet) environment.  
   
   Comments on section 7:
   
   Unfortunately the Reference topology from section 4 doesn't include interworking
   components.  Some of this might be easier if it did, but I don't think its a 
   critical issue.
   
   "To limit such an issue it is recommended to use the current practice based on
   firewalls and ACLs on the machine running the Proxy-ITR service."
   
   This seems a little unclear to me, I suggest something like:
   
   "To limit Proxy-ITRs being used as relays for attacks, Proxy-ITR operators are
   encouraged to implement best practices for data plane access control on the 
   proxy-ITR and the boarder of the network, that is the edge of  the scope of
   the Proxy-ITR's announcement of the EID-Prefix."
   
   Note that Access Control Lists placed in front of Proxy-ETRs could be populated with 
   the RLOC's of ITRs that are allowed to use said Proxy-ETR, which will greatly
   limit the possibility of traffic being injected by 3rd parties.
     
   Comments on Section 8:
   
   One general comment, this section has many long paragraphs, and might benefit 
   from some additional hierarchy.
   
   "In this section, we discuss the threats that could be caused by
   malicious xTRs."
   
   This section seems to be somewhat contradicting section 5.1, which implies 
   that compromised xTRs are out of scope.  If I understand your intent,
   I think you mean to say that you want to analyze how the LISP architecture 
   handles parts of it being compromised. I think there is a 
   disconnect in the flow of the document - to this point it has been a 
   thorough analysis of the protocol, and now it becomes a review of the LISP 
   architecture's  operational security posture.  Now I definitely think a 
   discussion like this belongs in this document, but I think further 
   introductory text could frame this either in the introduction or via 
   organizing the outline differently.  In fact, I would consider 
   changing the wording of the introduction - instead of having two main parts, 
   the control and data plane, this document has two main parts - a protocol 
   security analysis and a system security analysis.
   
   Ok, some specific comments about this section's text follows:
   
   "Malicious xTRs are probably the most serious threat to the LISP
   control plane from a security viewpoint."
   
   I might suggest a bit more detail here maybe something talking about
   why its so important, and why any shared control plane is easiest
   to attack from within the system (exactly like BGP).
   
   "The impact of a compromised lisp control plane can be severe, and
   the most effective way to attack any multi-organizational control 
   plane is from within the system itself"
   
   Later in section 8:
   
   "The current LISP specification briefly discusses the overclaiming
   problem [I-D.ietf-lisp], but does not propose any specific solution
   to solve the problem.  Nevertheless, [I-D.ietf-lisp-sec] proposes a
   solution to protect LISP against overclaiming attacks under the
   assumption that the mapping system can be trusted."
   
   Not sure if the above commentary adds anything to the document.  The over claiming
   threat was discussed in Stockholm and Hiroshima, and determined to be important
   enough that a detailed proposal was developed as a separate draft.  In my 
   opinion it solves the problem it was designed for elegantly and comprehensively.
   (also, what cryptographic solution to security doesn't have a trust anchor?)

   Later in section 8:
   
   "An important point to note about this flooding attack is that it
   reveals a limitation of the LISP architecture.  A LISP ITR relies on
   the received mapping and possible reachability information to select
   the RLOC of the ETR that it uses to reach a given EID or block of
   EIDs.  However, if the ITR made a mistake, e.g., due to
   misconfiguration, wrong implementation, or other types of errors and
   has chosen a RLOC that does not serve the destination EID, there is
   no easy way for the LISP ETR to inform the ITR of its mistake.  A
   possible solution is to enforce an ETR to perform a reachability test
   with the selected ITR as soon as there is LISP encapsulated traffic
   between the two."
   
   As you say, an ITR can make a reachability test (probe) to an ETR as soon
   as it receives a map-reply (in fact our implementation does this).  Also
   an ETR that receives traffic by mistake by sending a Solicit Map-Request
   back to the sending ITR.  So i strongly disagree with the wording above.

   Comments on section 9:
   
   Unfortunately, experience with BGP on the global Internet has shown
   that BGP is subject to various types of misconfiguration problems and
   security attacks.  The SIDR working group is developing a more secure
   inter-domain routing architecture to solve this problem ([RFC6480]).

   And yet, in-spite of this, BGP manages to do quite well on the global
   internet for tens of thousands of organizations and hundreds of 
   thousands of routes.  SIDR comes at a complexity and operational cost
   which, in the case of ALT, might be low enough to see deployment.  In
   short, there is no free lunch.  The ALT would be at least as secure
   as the current global BGP infrastructure - and isn't that the bar we
   are trying to meet to see LISP be deployable?
	
   Comments on Section 10.1. Map Server:

  "Similarly to the previous case, a malicious ETR can register an
   invalid EID-prefix to attract Map-Requests or to redirect them to a
   target to mount a DoS attack.  To avoid this kind of attack, the Map
   Server must check that the prefixes registered by an ETR belong to
   that ETR.  One method could be to manually configure EID-prefix
   ranges that can be announced by ETRs."
   
   In every MS implementation I'm aware of, the MS strictly checks the 
   EID prefix being registered against a static configuration.  We 
   use operational techniques to validate the ownership of the prefix
   by the operator of the ETR.

   Comments on section 10.2. Map Resolver:
	
   While it is allowed within the architecture to have a caching Map-Resolver
   to my knowledge one has not been implemented.  The reason is that,
   aside from security, cache coherency in an environment that can support
   fast moves (like LISP-MN) is very hard.  So some mention of this
   might be good - its not like we have a mixture of caching and non caching
   resolvers deployed...

   Comments on section 11
	
   This is a really nice set of recommendations, however, it might be nice 
   to cross reference the recommendations with the sections (gleaning, etc).
   that they apply to.  For example, the rate limiting section applies to 5.4.1 etc.
	
   I think this would go along way to my comment in the beginning that in 
   this document its hard to get a concise list of threats and recommendations
   for their mitigation, and any outstanding threats that need further work.
	
   "In order to mitigate flooding attacks it would be worth consider
   developing secure mechanisms to allow an ETR to indicate to an ITR
   that it does not serve a particular EID or block of EIDs."
   
   We have this, its called an SMR :-)

	-Darrel

---

From: "Vina Ermagan (vermagan)" <[email-masked]>
Date: Thu, 10 Jan 2013 22:50:50 +0000

Hi All,

Some general comments, followed by a few more detailed/minor suggestions.
Thanks to the authors for a very thorough analysis.

Best,
Vina

General Comments:

- Abstract:

Draft reads:
"This document analyzes the threats against the security of the
 Locator/Identifier Separation Protocol (LISP) and proposes a set of
 recommendations to mitigate some of the identified security risks."

Suggestion: This leaves the reader unclear about what the security state
would be after following the recommendations by this draft. Adding a
sentence such as the following is helpful: "By following the
recommendations of this draft a LISP deployment can achieve a security
level that is comparable to the existing Internet architecture."

- 6.Control Plane Threats

Section 6 talks about control plane threats. A reference to LISP-SEC in
this section seems appropriate. The first 5-6 sections of the threat
analysis draft were originally written before the LISP-SEC draft was
introduced and adopted by the WG (and hence they were very much
impact-full). It would be very helpful if the current version however
points out the security properties LISP-SEC brings to LISP, for instance
adding a sentence to 6.2 to this effect: "By enabling LISP-SEC Map-Reply
based threats are alleviated.".

- 5.2.1. EID-to-RLOC Cache Poisoning

The draft is pointing out that the list of cache poisoning examples here
are mostly enabled by (1) gleaning and (2) attacking the control plane.
>From attacks listed in the control plane in section 6, (a) Map-Reply based
attacks as well as (b) adding Map-Reply data to a Map-Request can lead to
these cache poisoning attacks. From these, Map-Reply based attacks are
alleviated by adopting LISP-SEC. It may be very helpful to bring this
information out by adding a summary at the end of this subsection noting
that: 
"By disabling gleaning and piggybacked Map-Replies, and enabling LISP-SEC,
most (if not all) of the cache poisoning threats are mitigated."

- 11. Suggested Recommendations

Many of the recommendations here are regarding removing risky
optimizations such as gleaning, piggybacked Map-Replies, etc. Depending on
the security requirements of a specific LISP deployment, these risks may
be acceptable. To clarify this, it may be helpful to add a paragraph in
the beginning of this section to the following effect:
"Different deployments of LISP may have different security requirements.
The recommendations in this section mitigate the threats enumerated in
this document."  

- 11. Suggested Recommendations - Last paragraph, page 27:

Page 27 reads:
"In [I-D.ietf-lisp], there is no mechanism that allows an xTR to
   verify the validity of the content a Map-Reply message that it
   receives.  Besides the attacks discussed earlier in the document, a
   time-shifted attack where an attacker is able to modify the content
   of a Map-Reply message but then needs to move off-path could also
   create redirection attacks.  The nonce only allows an xTR to verify
   that a Map-Reply responds to a previously sent Map-Request message.
   In order to allow verifying the validity and integrity of bindings
   between EID-Prefixes and their RLOCS solutions proposed in
   [I-D.saucez-lisp-mapping-security] and [I-D.ietf-lisp-sec] should be
   deployed.  Having such kind of mechanisms would allow ITRs to ignore
   non-verified mappings, thus increasing security."

I think the last sentence can be much stronger. Having LISP-SEC and
lisp-mapping-security in place would alleviate all the threats raised in
this paragraph.

Detailed/minor comments:

1. Introduction

Draft reads: 
"The document is composed of two main parts: the first discussing the LISP
data plane; while the second discussing the LISP control-plane."

Suggestion: A third, and important, part is the Recommendations part.

5.2.2. EID-to-RLOC Cache Overflow

It may be very helpful if a summary paragraph is added pointing out that
"Disabling gleaning and enabling LISP-SEC would protect against the
threats enumerated in this section."

5.3

Last paragraph of this section is more of a suggestion/recommendation.
Same for last paragraphs of section 7. I think it would be helpful in
general if the recommendation information through-out the draft is called
out
, perhaps by adding a Mitigations/Recommendations label to the beginning
of such paragraphs.

8. Threats with Malicious xTRs

Draft reads:

The last sentence seems a little vague. I suggest changing it to something
like this: " By enabling [I-D.ietf-lisp-sec] overclaiming attacks are
mitigated under the assumption that the mapping system can be trusted."

10.1 Map-Server

Page 24 reads: 

This is already done today and is explained in the Mapping System draft,
right? Perhaps this paragraph can be removed.

10.2 Map-Resolver

Page 25 reads:
  "A possible way to limit the above-described attacks is to introduce
   strong identification in the Map-Request/Map-Reply by using the
   Encapsulated Control Message with authentication enabled."

Are you referring to LISP-SEC here? Calling it out may be helpful.

11. Suggested Recommendations

Title of this section seems repetitive. "Security Recommendations" or just
"Recommendations" may be better alternatives.

11.

Page 27 reads: 
"In order to allow verifying the validity and integrity of bindings
between EID-Prefixes and their RLOCS solutions proposed in
[I-D.saucez-lisp-mapping-security] and [I-D.ietf-lisp-sec] should be
deployed.  Having such kind of mechanisms would allow ITRs to ignore
non-verified mappings, thus increasing security."

A minor technical question: is it ok to use "should" in "In order to allow
verifying the validity and integrity of bindings between EID-Prefixes and
their RLOCS solutions proposed in [I-D.saucez-lisp-mapping-security] and
[I-D.ietf-lisp-sec] should be deployed. ", considering that
[I-D.saucez-lisp-mapping-security] is an independent draft? Perhaps should
is too strong, "could" may be a better choice here?