IETF Logo Mail Archive

Re: [lisp] Restarting last call on LISP threats

Ronald Bonica <rbonica@juniper.net> Wed, 21 May 2014 17:41 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 A83B01A00E9 for <lisp@ietfa.amsl.com>; Wed, 21 May 2014 10:41:43 -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 df-Aw-egJUNk for <lisp@ietfa.amsl.com>; Wed, 21 May 2014 10:41:39 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11C11A0379 for <lisp@ietf.org>; Wed, 21 May 2014 10:41:38 -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; Wed, 21 May 2014 17:41:35 +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; Wed, 21 May 2014 17:41:35 +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/u8IAAAtXQgADypICAAlhbEIABfmkAgAAJsgCAAEpiAIAEFPjggABC9oCAAx/20A==
Date: Wed, 21 May 2014 17:41:34 +0000
Message-ID: <7053cf2c81534f84975013346c618ca8@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> <8891A030-B462-48D9-83B4-4E42525F38CE@steffann.nl> <F1FD0546-65C0-4288-B017-FDA55454A528@gmail.com> <df8bf1975fe04834bb7887ae38675983@CO1PR05MB442.namprd05.prod.outlook.com> <2D126379-BFF8-45FE-B6E1-B7E5E7FA5A6A@gmail.com>
In-Reply-To: <2D126379-BFF8-45FE-B6E1-B7E5E7FA5A6A@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.12]
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(199002)(189002)(24454002)(377454003)(51704005)(51444003)(46102001)(99396002)(99286001)(85852003)(83072002)(1411001)(15975445006)(33646001)(86362001)(76482001)(92566001)(54356999)(50986999)(76176999)(101416001)(66066001)(74316001)(64706001)(79102001)(74662001)(80022001)(19580405001)(19580395003)(2656002)(15202345003)(76576001)(15188155005)(87936001)(77982001)(74502001)(20776003)(81542001)(81342001)(31966008)(21056001)(4396001)(16799955002)(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/9Bznd_KEfg5g-t2_jN7O5Vk1YSU
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: Wed, 21 May 2014 17:41:43 -0000

Dino,

Aren't we talking about a scenario where the victim XTR has no information regarding the EID or LOC in its map-cache?

                                    Ron

> -----Original Message-----
> From: Dino Farinacci [mailto:farinacci@gmail.com]
> Sent: Monday, May 19, 2014 1:57 PM
> To: Ronald Bonica
> Cc: Sander Steffann; Roger Jorgensen; lisp@ietf.org
> Subject: Re: [lisp] Restarting last call on LISP threats
> 
> In those cases we do mapping database RPF lookups.
> 
> Dino
> 
> 
> 
> > On May 19, 2014, at 10:14 AM, Ronald Bonica <rbonica@juniper.net>
> wrote:
> >
> > Dino,
> >
> > The Spoofer Project (http://spoofer.cmand.org/summary.php) offers a
> longitudinal view of BCP 38 deployment. I think that the results that they
> report validate Sander's objection. Furthermore, they may suggest that
> Sander's objection will remain valid for years to come.
> >
> >
> > Ron
> >
> >
> >> -----Original Message-----
> >> From: Dino Farinacci [mailto:farinacci@gmail.com]
> >> Sent: Friday, May 16, 2014 7:37 PM
> >> To: Sander Steffann
> >> Cc: Ronald Bonica; Roger Jorgensen; lisp@ietf.org
> >> Subject: Re: [lisp] Restarting last call on LISP threats
> >>
> >>> Unfortunately this is not unlikely :(  I certainly wouldn't consider
> >>> it an
> >> amazing feat... BCP38 is not implemented as much as it should be.
> >>
> >> I know there are many cases where BCP38 is not practice but more and
> >> more access providers due uRPF.
> >>
> >> You only need one in the path. And the ones that don't do it are
> >> using resources to transit packets to possible black holes.
> >>
> >> Dino

v2.23.0 | Report a Bug | By Email