Re: [lisp] Restarting last call on LISP threats

[Damien Saucez <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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:[e-mail]] 
> 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,
> 
> 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 <[e-mail]> wrote:
>> 
>> 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:[e-mail]] 
>> 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.
>> 
>> 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.
>> 
>>> On 12 May 2014, at 19:11, Ross Callon <[e-mail]> wrote:
>>> 
>>> 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.
>> 
>> 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 normal path to the destination.
>> 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 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?
>> 
>> The document is just an analysis, hence your question, while valid, is
>> outside the scope of this document.
>>> 
>>> 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).
>> 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.
>> 
>>> 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?
>> 
>> This can be fixed before pushing the document to the IESG.
>> 
>> 
>>> 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.
>> 
>> 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.
>> 
>> 
>> 
>>> 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.
>> 
>> 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.
>> 
>>> 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.
>> 
>> 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.
>> 
>> 
>>> 
>>> 
>>> 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.
>> 
>> 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 plane, this makes it much easier to create an effective DOS attack.
>> 
>> RFC6830 already considered rate limiting fo this very reason.
>> 
>>> 
>>> 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".
>> 
>> 
>> 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)
>> 
>> 
>>> 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.
>> 
>> 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.
>> 
>> 
>>> Thanks, Ross
>>> 
>>> -----Original Message-----
>>> From: lisp [mailto:[e-mail]] On Behalf Of Joel M. Halpern
>>> Sent: Friday, May 09, 2014 11:54 AM
>>> To: [e-mail]
>>> Subject: [lisp] Restarting last call on LISP threats
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>