IETF Logo Mail Archive

Re: [lisp] Restarting last call on LISP threats

Dino Farinacci <farinacci@gmail.com> Fri, 16 May 2014 23:37 UTC

Return-Path: <farinacci@gmail.com>
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 BFC651A01AB for <lisp@ietfa.amsl.com>; Fri, 16 May 2014 16:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 N7oBmXm9kZxV for <lisp@ietfa.amsl.com>; Fri, 16 May 2014 16:37:35 -0700 (PDT)
Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E32A1A0195 for <lisp@ietf.org>; Fri, 16 May 2014 16:37:35 -0700 (PDT)
Received: by mail-yh0-f49.google.com with SMTP id c41so5003080yho.36 for <lisp@ietf.org>; Fri, 16 May 2014 16:37:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zyOaaRlGFqyBprtI66lC5OlZaFyEnqfZZClN3cY5qbE=; b=fmcIf/mAj0EhOOALq0aTRNAaLN5rD+RXr0zt2aFf5KVlRgbkStlZQefhjbtRXA68lQ Y5i/p7DooSRh4aFFWKNz80h/pa+IdykIkg7NwIkQBApzzLdcL3fg4eOpFE6K+OgYAsZl Rs2MUMgKHX85ZNrCezf9u+fqKx226jPc8ZdP/oJcMuTx1Rxo4YY7Q584LvOy4NVySNZI UWb2/1HZRnEjeOqMzSuqBAEJua+CNglo2g3nj2gN7mSjG8hIpqp3HQRl4hcDZx3h20E7 e6Ox8G0DHTa05UlEEZ6uA28/Bt19JzCBXqXxQsAsbfZb4Pkiae2hi5DUbMIyIL5g0J5c +OCQ==
X-Received: by 10.236.32.178 with SMTP id o38mr29934489yha.119.1400283447743; Fri, 16 May 2014 16:37:27 -0700 (PDT)
Received: from [192.168.2.122] ([72.252.14.172]) by mx.google.com with ESMTPSA id z2sm14077434yhm.30.2014.05.16.16.37.20 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 16:37:26 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Dino Farinacci <farinacci@gmail.com>
X-Mailer: iPhone Mail (11D167)
In-Reply-To: <8891A030-B462-48D9-83B4-4E42525F38CE@steffann.nl>
Date: Fri, 16 May 2014 19:37:14 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1FD0546-65C0-4288-B017-FDA55454A528@gmail.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>
To: Sander Steffann <sander@steffann.nl>
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/RqpzJldpHa25yE85yRvLlfqg2WE
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: Fri, 16 May 2014 23:37:36 -0000

> 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