Re: [lisp] Restarting last call on LISP threats

Ross Callon <> Fri, 23 May 2014 14:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AA6421A017A for <>; Fri, 23 May 2014 07:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WRp1xAFD8UgA for <>; Fri, 23 May 2014 07:37:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C77331A0168 for <>; Fri, 23 May 2014 07:37:07 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.944.11; Fri, 23 May 2014 14:36:57 +0000
Received: from ([]) by ([]) with mapi id 15.00.0944.000; Fri, 23 May 2014 14:36:57 +0000
From: Ross Callon <>
To: Damien Saucez <>
Thread-Topic: [lisp] Restarting last call on LISP threats
Thread-Index: AQHPa58M9eFhkxJvMEaw1MEc+Ryfdps9FMJAgAt2hwCABcOvgA==
Date: Fri, 23 May 2014 14:36:56 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0220D4B98D
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(13464003)(37854004)(199002)(189002)(377454003)(51444003)(164054003)(52314003)(76482001)(33646001)(77982001)(83322001)(19580405001)(19580395003)(81542001)(81342001)(4396001)(99396002)(99286001)(46102001)(551544002)(92566001)(21056001)(86362001)(74662001)(31966008)(101416001)(80022001)(74316001)(74502001)(15975445006)(66066001)(87936001)(76576001)(20776003)(85852003)(64706001)(50986999)(54356999)(15202345003)(76176999)(77096999)(83072002)(79102001)(2656002)(24736002)(559001)(579004); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB635;; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: LISP mailing list list <>
Subject: Re: [lisp] Restarting last call on LISP threats
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 May 2014 14:37:13 -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:   

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 [] 
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 <> 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.

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...

> 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).

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". 

> 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.

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. 

> 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.

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)

> Section (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.

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). 

> 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.

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). 

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

RWC>  As it should. 

> Last paragraph of section 
>   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.  

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

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

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

> Section, 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. 

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
limit cryptography technique to the payload, actually section 2 makes
the distinction saying:

 "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.

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

> 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.

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

> 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.

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).

> 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)

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. 

> 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.

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

> 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, 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.

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

> -----Original Message-----
> From: lisp [] On Behalf Of Joel M. Halpern
> Sent: Friday, May 09, 2014 11:54 AM
> To:
> 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:
> The last call will end in two weeks, close of business 23-May-2014.
> Thank you,
> Joel
> _______________________________________________
> lisp mailing list