Re: [lisp] Restarting last call on LISP threats

Ronald Bonica <rbonica@juniper.net> Tue, 27 May 2014 22:55 UTC

Return-Path: <rbonica@juniper.net>
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 A2A191A02B0 for <lisp@ietfa.amsl.com>; Tue, 27 May 2014 15:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.602
X-Spam-Level:
X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 V_JEKy51mqeA for <lisp@ietfa.amsl.com>; Tue, 27 May 2014 15:54:58 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685791A029F for <lisp@ietf.org>; Tue, 27 May 2014 15:54:58 -0700 (PDT)
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB444.namprd05.prod.outlook.com (10.141.73.140) with Microsoft SMTP Server (TLS) id 15.0.949.11; Tue, 27 May 2014 22:54:47 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.68]) with mapi id 15.00.0949.001; Tue, 27 May 2014 22:54:47 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: Marc Binderberger <marc@sniff.de>, "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [lisp] Restarting last call on LISP threats
Thread-Index: AQHPa58LSm48HWl6Wky1MR3KNHiENZs9MyiAgAD04oCAAJ/u8IAAAtXQgADypICAAlhbEIABfmkAgAefyVCAAITngIABbBJggAETbwCABC0O0IAAtqUAgAABTnCAADykgIAAAb6AgADP7YCAAPi2YA==
Date: Tue, 27 May 2014 22:54:46 +0000
Message-ID: <ffdb31ed7ff74fd4b4a27c646b842f39@CO1PR05MB442.namprd05.prod.outlook.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> <53839747.1080806@joelhalpern.com> <20140527005843634679.23839638@sniff.de>
In-Reply-To: <20140527005843634679.23839638@sniff.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.14]
x-forefront-prvs: 02243C58C6
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(479174003)(377454003)(24454002)(51704005)(52604005)(199002)(189002)(2656002)(77982001)(87936001)(74502001)(31966008)(50986999)(92566001)(99286001)(76576001)(76176999)(85852003)(74662001)(83072002)(81342001)(81542001)(54356999)(33646001)(79102001)(66066001)(101416001)(21056001)(86362001)(20776003)(64706001)(76482001)(19580405001)(83322001)(15975445006)(19580395003)(99396002)(74316001)(80022001)(46102001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB444; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/qETFufVVotml4IKh_puwSGr5XZU
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: Tue, 27 May 2014 22:55:01 -0000

> 
> The discussion was IMHO too much focused on gleaning. LISP is made for a
> large number of EID networks. If e.g. someone scans the address ranges of
> an ISP and the PiTR(s) of the ISP have no forwarding entry then they need to
> send a map-request - a task typically done in control plane. Punting packets
> from data to control plane may saturate the punt channel for a time T, during
> which a legitimate request may not be processed.
[RPB] 
Agreed. The attack scenario that I describe in my previous message relies neither on gleening nor source address spoofing.

> 
> To be fair, even for a large number of EID networks (e.g. lots of /29) the
> period T should not be more than several minutes (my guess, assuming 1k
> lookup per second) and it would not affect already established flows, only
> the establishment of new flows during the time T, assuming the (P)iTR can
> hold all the map-cache entries.
> 
[RPB] 
Also agreed. We should say something in a threats document about the relationship between period T and the size of memory available for the map-cache.

> 
> Regards, Marc
> 
> 
> 
> On Mon, 26 May 2014 15:34:31 -0400, Joel M. Halpern wrote:
> > 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
> >>
> >
> > _______________________________________________
> > lisp mailing list
> > lisp@ietf.org
> > https://www.ietf.org/mailman/listinfo/lisp
> >