Re: [lisp] Restarting last call on LISP threats

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 26 May 2014 19:34 UTC

Return-Path: <jmh@joelhalpern.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 2A5321A0240 for <lisp@ietfa.amsl.com>; Mon, 26 May 2014 12:34:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 BmU6w6h0gla1 for <lisp@ietfa.amsl.com>; Mon, 26 May 2014 12:34:43 -0700 (PDT)
Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF7B1A023D for <lisp@ietf.org>; Mon, 26 May 2014 12:34:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 798531C9CE15; Mon, 26 May 2014 12:34:40 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-135-10.clppva.east.verizon.net [70.106.135.10]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 379901C9CE13; Mon, 26 May 2014 12:34:35 -0700 (PDT)
Message-ID: <53839747.1080806@joelhalpern.com>
Date: Mon, 26 May 2014 15:34:31 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Paul Vinciguerra <pvinci@VinciConsulting.com>, Ronald Bonica <rbonica@juniper.net>, "Joel M. Halpern" <jmh@joelhalpern.com>, Damien Saucez <damien.saucez@gmail.com>
References: <536CFA13.4010102@joelhalpern.com> <4e6c0aaac8fb4aba87ab137cc49b51dc@CO2PR05MB636.namprd05.prod.outlook.com> <CAKFn1SH_gu1+e6EsWESBsRw9EGiSQ+Z5r9E7GEhMO1FdNuM9nQ@mail.gmail.com> <1a200c5f5de041fbaf88edd1a5c3159c@CO1PR05MB442.namprd05.prod.outlook.com> <CAKFn1SEAZyydpQ4cx77mthsUx1HZqMwsM6xNuL4LJjG=oL1mjw@mail.gmail.com> <860b7987207345afb282a82862ff42c0@CO1PR05MB442.namprd05.prod.outlook.com> <F4799A7A-BAEF-458A-8C43-9DF16C9B7828@gmail.com> <e3be912f6afd4f0aa6c8414fede37c74@CO1PR05MB442.namprd05.prod.outlook.com> <2CF699DA-2BAA-4A76-BFF1-64625E001184@gmail.com> <09d3b0d276004c88b6de1a59cf863062@CO1PR05MB442.namprd05.prod.outlook.com> <3269BEE4-C3E5-4D76-A1C0-0B70B6928A12@gmail.com> <dd849ce0cca749c885c5b8a1e989f758@CO1PR05MB442.namprd05.prod.outlook.com> <538361DA.10808@joelhalpern.com>, <029e0f8bc7ba433ba4d3ee70b8431f9f@CO1PR05MB442.namprd05.prod.outlook.com> <3519A6AD5B18C44EB0291EC6C880A906012FD3@NYDC-EXCH01.vinci-consulting-corp.local>
In-Reply-To: <3519A6AD5B18C44EB0291EC6C880A906012FD3@NYDC-EXCH01.vinci-consulting-corp.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/9ea7UfVSPSKYnvRw4pY3YhdfRp0
Cc: Roger Jorgensen <rogerj@gmail.com>, 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, 26 May 2014 19:34:45 -0000

It sounds like the PxTRs you are using are already implementing sensible 
mitigations.  But the base document does not actually call this out.

On the base document, the ETR can do gleaning (and by some readings 
mgiht be being encouraged to do so).  Because of the security threat 
from gleaning, and because the Etr wants to avoid the delay on returning 
traffic, nor use a false glean to direct returning traffic, there is 
text suggesting that the ETR would, immediately upon gleaning, check the 
information with the mapping system.

That would mean that a packet flow to an ETR (which all nodes are, as 
you say, subject to) could become a significant load on the mapping system.

Making different choices about when to learn or verify entries changes 
that dramatically.  But since the document does currently include the 
problematic behavior as legitimate, we need to document that it can 
cause problems.

I am glad to hear that sensible implementations are already dealing with 
this well.

Yours,
Joel

On 5/26/14, 3:28 PM, Paul Vinciguerra wrote:
> Every host on the Internet is subject to a DoS attack.  An xTR is no
> more so.  I am also not clear on how a DoS attack on an xTR would
> create any more risk than an attack directly against the mapping
> system.
>
> Joel describes Ronald's scenario of an attack where a large stream of
> packets with different inner source addresses to an ETR.  I don't
> call this an attack.  I call this our steady-state.  These would be
> the PxTR's we operate across the US.  The PxTR's on the beta-network
> are no different.  We take in packets from anywhere.  This is a
> "Free" attacker if you will.  All that really means is that you do
> not have to incur the computational cost of encapsulating the
> packet.
>
> I would defer to Dino and others on the list, but I do not believe
> that the ETR does a reverse lookup on every packet.  At least that is
> not the behavior we observe.  What we see happen is that the packet
> is decapsulated and sent to the destination.  If a valid destination
> host responds, then the ITR does a map-request for the reply packet.
> There is not a 1:1 relationship between the number of packets and the
> number of map-requests.
>
> Map-replies for IP addresses return prefixes. These prefixes can
> cover larger address spaces than the map-request and limit the number
> of future map-requests needed.
>
> Can you provide more specific details on how you see the xTR
> rendering the mapping system unusable?
>
> For what its worth, I still support the decision for last call and
> not to place mitigations within the document.  Without knowing the
> specifics of a configuration and implementation, that just leads to a
> false sense of security.
>
>
> ________________________________________ From: lisp
> [lisp-bounces@ietf.org] on behalf of Ronald Bonica
> [rbonica@juniper.net] Sent: Monday, May 26, 2014 11:57 AM To: Joel M.
> Halpern; Damien Saucez Cc: Roger Jorgensen; LISP mailing list list
> Subject: Re: [lisp] Restarting last call on LISP threats
>
> Inline.....
>
>> -----Original Message----- From: Joel M. Halpern
>> [mailto:jmh@joelhalpern.com] Sent: Monday, May 26, 2014 11:47 AM
>> To: Ronald Bonica; Damien Saucez Cc: Roger Jorgensen; LISP mailing
>> list list Subject: Re: [lisp] Restarting last call on LISP threats
>>
>> Top posting to make sure I am understanding:
>>
>> You asssert that any xTR is subject to a DoS attack.  And that such
>> a DoS attack can render the mapping system unusable.
> [RPB] Exactly!
>
>>
>> It targeting an ITR, this would need to be from within ths cope the
>> ITR serves.
> [RPB] I don't understand this sentence. Please try again.
>
>> I believe that is discussed.
> [RPB] Given that I don't understand the sentence above, I have no
> idea if this sentence is true.
>
>>
>> If I have connected the dots correctly, the attack you are
>> contemplating is sending a large stream of packets with different
>> inner source addresses to an ETR.  This would prompt the ETR to
>> check with the mapping system about each and every address.
> [RPB] Exactly!
>
>>
>> If I have understood this properly, while there are several very
>> effective mitigations, that does not change the basic message that
>> this is an attack, and as such ought to be described in the threats
>> document.
> [RPB] Even if there are effective mitigations, the attack should be
> described.
>
> However, I am not convinced that an effective mitigation exists.
>
>> There are clealry a number of variations on this attack.
> [RPB] True!
>
> For example, using
>> the same outer source address makes mitigation easier, while using
>> different outer source addresses either requires a bot-net or a
>> large unchecked BCP38 hole (and those can be used for MANY attacks
>> on many systems.)  Both presumably should be described.
> [RPB] Yes, both should be described.
>
> Also, recall that large BCP38 holes exist in today's internet.
>
>>
>> Have I captured your request accurately?
> [RPB] Pretty much.
>
> Thanks for taking the effort.
>
> Ron
>
>>
>> Yours, Joel
>>
>> On 5/26/14, 1:06 AM, Ronald Bonica wrote:
>>> *From:*Damien Saucez [mailto:damien.saucez@gmail.com] *Sent:*
>>> Friday, May 23, 2014 9:07 AM *To:* Ronald Bonica *Cc:* Dino
>>> Farinacci; Roger Jorgensen; LISP mailing list list *Subject:* Re:
>>> [lisp] Restarting last call on LISP threats
>>>
>>> Hello Ronald,
>>>
>>> On 22 May 2014, at 22:57, Ronald Bonica <rbonica@juniper.net
>>> <mailto:rbonica@juniper.net>> wrote:
>>>
>>>
>>>
>>> Dino,
>>>
>>> Today's Internet is not as fragile as you think. This mail
>>> traversed many routers between my house and yours. If those
>>> routers are well-managed, there is nothing that I can do from my
>>> house that will cause any of those routers to consume control
>>> plane resources. Therefore, there is nothing that I can do from
>>> my house that will cause a DoS attack against those routers'
>>> control planes.
>>>
>>> We tend to disagree with that, for example you have ICMP
>>> today...
>>>
>>> */[RPB] Because ICMP is susceptible to DoS attacks, it wouldn't
>>> make a very good routing protocol. That's why we don't use it for
>>> routing. By contrast, LISP map-request messages are susceptible
>>> to DoS attacks and they do carry routing information./*
>>>
>>>
>>>
>>> In LISP, separation between the forwarding and control plane is
>>> lost. As a matter of course, forwarding plane activity causes
>>> control plane activity. Since forwarding plane bandwidth exceeds
>>> control plane bandwidth, DoS attacks against the control plane
>>> are possible.
>>>
>>> In order to be complete, the threats document must describe the
>>> DoS threat. It should also describe mitigations, if any exist.
>>>
>>> DoS is already explained and the definition given:
>>>
>>> " A Denial of Service (DoS) attack aims at disrupting a specific
>>>
>>> targeted service either by exhausting the resources of the
>>> victim up
>>>
>>> to the point that it is not able to provide a reliable service
>>> to
>>>
>>> legit traffic and/or systems or by exploiting vulnerabilities to
>>> make
>>>
>>> the targeted service unable to operate properly.
>>>
>>> "
>>>
>>> is covering the case you mention.
>>>
>>> */[RPB] /*
>>>
>>> */You might want to add the following details to section 5.2:/*
>>>
>>> *//*
>>>
>>> -A DoS attack can be launched by anybody who can send a packet to
>>> the XTR's LOC
>>>
>>> -DoS attacks can render an XTR inoperable
>>>
>>> -DDoS attacks can render the mapping system inoperable.
>>>
>>> This is what differentiates LISP from today's routing system.
>>>
>>> Ron
>>>
>>> Damien Saucez
>>>
>>>
>>>
>>>
>>> Ron
>>>
>>>
>>>
>>> -----Original Message----- From: Dino Farinacci
>>> [mailto:farinacci@gmail.com] Sent: Wednesday, May 21, 2014 6:58
>>> PM To: Ronald Bonica Cc: Roger Jorgensen; lisp@ietf.org
>>> <mailto:lisp@ietf.org> Subject: Re: [lisp] Restarting last call
>>> on LISP threats
>>>
>>>
>>> The attacker sends a flow of crafted packets to the victim XTR.
>>> Each packet
>>>
>>> is a well-formed LISP data packet. It contains:
>>>
>>>
>>> - an outer IP header (LOC->LOC) - a UDP header - a LISP Header -
>>> an IP header (EID->EID) - payload
>>>
>>>
>>> Just like a regular packet I can send to your home router today.
>>> So yes okay. So let's continue. See comments below.
>>>
>>>
>>> Each packet contains control plane information that is new to the
>>> victim
>>>
>>>
>>> Be more specific about what control information are in these
>>> encapsulated packets.
>>>
>>>
>>> XTR. For example, the victim XTR has no mapping information
>>> regarding
>>>
>>> either the source LOC or source EID prefix. Rather than gleaning
>>> this mapping information from the crafted packet, the victim XTR
>>> sends a verifying MAP- REQUEST to the mapping system.
>>>
>>>
>>> Assume that the attack flow is large (N packets per second).
>>> Assume also
>>>
>>> that the XTRs rate limit for MAP-REQUEST messages is less than N
>>> packets per second. Has the attack not effectively DoS'd the
>>> victim XTR?
>>>
>>> It caches the rate the rate the packets are coming in and
>>> eventually stops sending Map-Requests completely.
>>>
>>> It cannot stop the incoming rate of packets today just like a
>>> roque BGP attacker can send millions of packets per second to a
>>> peer regardless if it does or does not have the peer
>>> authentication key.
>>>
>>>
>>> To make this attack work, every packet in the attack flow may
>>> need to have
>>>
>>> a unique, spoofed, source LOC.
>>>
>>> An implementation can detect that after rate limiting 1000s of
>>> such requests are happening that it just stops operation.
>>>
>>> What if I sent a Juniper 20 million routes today?
>>>
>>> The Internet is very fragile and LISP IS NOT making it worse. And
>>> in some cases it is making it better with integrated techniques.
>>>
>>> Dino
>>>
>>>
>>> _______________________________________________ lisp mailing
>>> list lisp@ietf.org <mailto:lisp@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/lisp
>>>
>>>
>>>
>>> _______________________________________________ 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
>