Re: [lisp] Restarting last call on LISP threats

Ronald Bonica <rbonica@juniper.net> Wed, 28 May 2014 00:18 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 6075E1A07DD for <lisp@ietfa.amsl.com>; Tue, 27 May 2014 17:18:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.602
X-Spam-Level:
X-Spam-Status: No, score=-99.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_WRLDWD=2.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
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 VgsSRbYdhVoh for <lisp@ietfa.amsl.com>; Tue, 27 May 2014 17:18:36 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415471A02E4 for <lisp@ietf.org>; Tue, 27 May 2014 17:18:36 -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.949.11; Wed, 28 May 2014 00:18:29 +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; Wed, 28 May 2014 00:18:29 +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/u8IAAAtXQgADypICAAlhbEIABfmkAgAefyVCAAITngIABbBJggAETbwCABC0O0IAAtqUAgAABTnCAADykgIABvzTggAATfICAAA/EoA==
Date: Wed, 28 May 2014 00:18:29 +0000
Message-ID: <9091dab3083e460abb2080f1e9315aba@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> <936e209eb2fb49288f3a776aaa4b71cb@CO1PR05MB442.namprd05.prod.outlook.com> <7E76C55E-CCD0-4A52-A481-5BA9BF6A6689@gmail.com>
In-Reply-To: <7E76C55E-CCD0-4A52-A481-5BA9BF6A6689@gmail.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: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(377454003)(13464003)(51704005)(199002)(189002)(1411001)(21056001)(76482001)(81342001)(74502001)(74662001)(81542001)(74316001)(76576001)(79102001)(2656002)(76176999)(86362001)(87936001)(101416001)(31966008)(33646001)(83072002)(4396001)(99396002)(77982001)(19580405001)(19580395003)(83322001)(99286001)(46102001)(92566001)(50986999)(80022001)(64706001)(20776003)(54356999)(66066001)(85852003)(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/VPuIynrHIRoLHv0yEqSCPnPr0EE
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: Wed, 28 May 2014 00:18:38 -0000

Inline....

> -----Original Message-----
> From: Dino Farinacci [mailto:farinacci@gmail.com]
> Sent: Tuesday, May 27, 2014 7:19 PM
> To: Ronald Bonica
> Cc: Paul Vinciguerra; Joel M. Halpern; Damien Saucez; Roger Jorgensen; LISP
> mailing list list
> Subject: Re: [lisp] Restarting last call on LISP threats
> 
> 
> > Hi Paul,
> >
> > The attack scenario that I envision is slightly different from the on that you
> describe below:
> >
> > - LISP is widely deployed. Tens of thousands of XTRs are deployed world-
> wide. The mapping system data base contains hundreds of thousands of EID
> prefixes.
> > - The attack stream is large
> > - Each packet in the attack stream has a unique source LOC
> > - All packets in the attack stream have the same destination LOC. This LOC
> represents the XTR under attack.
> > - Each packet in the attack stream has a destination EID that will cause it to
> reach a valid destination (i.e., a destination that will respond). However, all
> packets in the attack stream don't have the same destination. The attack
> stream is spread out across multiple valid EID destinations to make it less
> detectable.
> > - Each packet in the attack stream has a carefully chosen source EID. It is
> chosen to maximize the ratio of attack packets to map-requests.
> >
> > One attack stream attacks an XTR. Multiple simultaneous attacks against
> multiple XTRs can DoS the mapping system, itself.
> >
> > A PxTR probably won't generate this attack stream. However, an attack tool
> might.
> 
> Ignoring the unique source RLOC (which makes no difference in this attack
> because we are not doing a RPF check on the ETR), it is the same as if a PITR
> was encapsulating from the same set of source-EIDs to the same set of
> destination-EIDs you describe above.
> 
> That was his point.
> 
> So some clarifications:
> 
> (1) What does unique source LOC mean? I assume you mean each packet as
> a different source RLOC and that the address is not duplicated from multiple
> sites (i.e. is it not a private address like 192.168.1.1), or do you meawn
> something else?
[RPB] 
No two packets in the attack stream have the same Source RLOC.

> 
> (2) And what is carefully chosen mean? You might mean a scan of differnet
> source EIDs in each packet so the xTR that returns packets will get more map-
> cache misses?
[RPB] 
Exactly. Source EIDs are chosen to maximize the ratio of attack packets to map-requests sent by the victim XTR.

This is what make the attack stream so different from a stream that a PiTR is likely to send during normal operation.

                                                                                                 Ron

> 
> Dino