Re: [lisp] Restarting last call on LISP threats

Ronald Bonica <rbonica@juniper.net> Mon, 26 May 2014 15:57 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 DF8AA1A01A9 for <lisp@ietfa.amsl.com>; Mon, 26 May 2014 08:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.601
X-Spam-Level:
X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 jP7aqjJ3J4Ut for <lisp@ietfa.amsl.com>; Mon, 26 May 2014 08:57:44 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C691A01A0 for <lisp@ietf.org>; Mon, 26 May 2014 08:57:43 -0700 (PDT)
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.0.949.11; Mon, 26 May 2014 15:57:38 +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; Mon, 26 May 2014 15:57:37 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Damien Saucez <damien.saucez@gmail.com>
Thread-Topic: [lisp] Restarting last call on LISP threats
Thread-Index: AQHPa58LSm48HWl6Wky1MR3KNHiENZs9MyiAgAD04oCAAJ/u8IAAAtXQgADypICAAlhbEIABfmkAgAefyVCAAITngIABbBJggAETbwCABC0O0IAAtqUAgAABTnA=
Date: Mon, 26 May 2014 15:57:37 +0000
Message-ID: <029e0f8bc7ba433ba4d3ee70b8431f9f@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>
In-Reply-To: <538361DA.10808@joelhalpern.com>
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: 02234DBFF6
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(24454002)(479174003)(377454003)(51704005)(13464003)(54356999)(87936001)(50986999)(76176999)(83072002)(2656002)(85852003)(74502001)(99396002)(99286001)(74662001)(31966008)(4396001)(19580395003)(83322001)(19580405001)(15975445006)(21056001)(101416001)(92566001)(77982001)(46102001)(76482001)(86362001)(66066001)(64706001)(80022001)(20776003)(81342001)(33646001)(76576001)(81542001)(74316001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB441; 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/KIYmUW5Il0RorgUSx1MNocOQY6I
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 15:57:47 -0000

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