Re: [lisp] Restarting last call on LISP threats

Ronald Bonica <rbonica@juniper.net> Thu, 22 May 2014 20: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 B6D491A0305 for <lisp@ietfa.amsl.com>; Thu, 22 May 2014 13:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level:
X-Spam-Status: No, score=-101.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, 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 r4cF_mHFgMAj for <lisp@ietfa.amsl.com>; Thu, 22 May 2014 13:57:20 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385CE1A02A9 for <lisp@ietf.org>; Thu, 22 May 2014 13:57:20 -0700 (PDT)
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 20:57:16 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.206]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.206]) with mapi id 15.00.0944.000; Thu, 22 May 2014 20:57:15 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: Dino Farinacci <farinacci@gmail.com>
Thread-Topic: [lisp] Restarting last call on LISP threats
Thread-Index: AQHPa58LSm48HWl6Wky1MR3KNHiENZs9MyiAgAD04oCAAJ/u8IAAAtXQgADypICAAlhbEIABfmkAgAefyVCAAITngIABbBJg
Date: Thu, 22 May 2014 20:57:15 +0000
Message-ID: <09d3b0d276004c88b6de1a59cf863062@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>
In-Reply-To: <2CF699DA-2BAA-4A76-BFF1-64625E001184@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.16]
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(13464003)(199002)(189002)(377454003)(76576001)(87936001)(74502001)(77982001)(21056001)(19580395003)(19580405001)(83322001)(2656002)(4396001)(31966008)(81342001)(20776003)(81542001)(74662001)(80022001)(86362001)(92566001)(76482001)(85852003)(1411001)(83072002)(46102001)(33646001)(99396002)(101416001)(79102001)(64706001)(66066001)(74316001)(54356999)(50986999)(76176999)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; 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/iFvMDZ_qtzNeAmyzxLwOrD5MJIQ
Cc: Roger Jorgensen <rogerj@gmail.com>, "lisp@ietf.org" <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: Thu, 22 May 2014 20:57:22 -0000

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.

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.

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