Re: [lisp] Restarting last call on LISP threats

Damien Saucez <damien.saucez@gmail.com> Mon, 19 May 2014 22:25 UTC

Return-Path: <damien.saucez@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387931A0412 for <lisp@ietfa.amsl.com>; Mon, 19 May 2014 15:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxX_faafBma2 for <lisp@ietfa.amsl.com>; Mon, 19 May 2014 15:25:45 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F041A0195 for <lisp@ietf.org>; Mon, 19 May 2014 15:25:44 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id l18so8593125wgh.14 for <lisp@ietf.org>; Mon, 19 May 2014 15:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/IUsBEprB5Q+vPTkevOMzuiai+ioUurzreuJe3C5pbM=; b=yHO2LoA+IJnof0ERAs2Dj+x9+NrF9E9E1M+86oeQMs+GyQ0KNjqHqr2OQcYFWk6F83 mcx8wj+MWaoGBwdPReq9s5/JP/NuLes0GYXNVWmPZXqG4X8T/t9gwqnXhXoQkYBGQIhn 0LAFRLxIbyxiHk6PFmVp15eBz1ggTAlckm8YVn3zMgxuG82eEcrXkVapZNZmzw4oDROu VYQ7UNPch41pWoU1mgf4wk0X09ThR6CzVjMx6hGCHpwO8nCV2F55NUwSFUxHuPfchVSp SvPvmsvBl4Vh8zR2tC/o9SkLIhZzZ5Dwc5lBrrJlqLxA4Qp3ax4C9YAtWTpbfy0LpRL3 vg+g==
X-Received: by 10.180.13.139 with SMTP id h11mr1057706wic.34.1400538343652; Mon, 19 May 2014 15:25:43 -0700 (PDT)
Received: from [10.207.103.153] (LLagny-156-35-13-133.w80-14.abo.wanadoo.fr. [80.14.125.133]) by mx.google.com with ESMTPSA id j3sm15775428wjw.38.2014.05.19.15.25.40 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 15:25:42 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Damien Saucez <damien.saucez@gmail.com>
In-Reply-To: <4e6c0aaac8fb4aba87ab137cc49b51dc@CO2PR05MB636.namprd05.prod.outlook.com>
Date: Tue, 20 May 2014 00:25:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3FF60AE-ED9D-45E6-BBB5-AE3F6C6172F8@gmail.com>
References: <536CFA13.4010102@joelhalpern.com> <4e6c0aaac8fb4aba87ab137cc49b51dc@CO2PR05MB636.namprd05.prod.outlook.com>
To: Ross Callon <rcallon@juniper.net>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/Z9KK93Dqr1BmJsmL9ZyJ6xyHJ44
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Restarting last call on LISP threats
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 May 2014 22:25:49 -0000

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 <rcallon@juniper.net> 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:lisp-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Friday, May 09, 2014 11:54 AM
> To: lisp@ietf.org
> 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
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp