Re: [lisp] Restarting last call on LISP threats

Ross Callon <> Wed, 28 May 2014 17:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EAEAF1A01C1 for <>; Wed, 28 May 2014 10:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XsQbCHL_2bXV for <>; Wed, 28 May 2014 10:53:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D1F51A01B6 for <>; Wed, 28 May 2014 10:53:01 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 28 May 2014 17:52:56 +0000
Received: from ([]) by ([]) with mapi id 15.00.0944.000; Wed, 28 May 2014 17:52:56 +0000
From: Ross Callon <>
To: Damien Saucez <>
Thread-Topic: [lisp] Restarting last call on LISP threats
Date: Wed, 28 May 2014 17:52:55 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0225B0D5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(164054003)(24454002)(52604005)(199002)(189002)(51704005)(377454003)(479174003)(99396002)(74662001)(64706001)(79102001)(19580405001)(20776003)(80022001)(561944003)(99286001)(74502001)(76482001)(33646001)(83072002)(81542001)(31966008)(15975445006)(19580395003)(77982001)(87936001)(2656002)(83322001)(46102001)(54356999)(50986999)(101416001)(77096999)(74316001)(21056001)(76176999)(66066001)(92566001)(4396001)(81342001)(76576001)(86362001)(85852003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634;; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: LISP mailing list list <>
Subject: Re: [lisp] Restarting last call on LISP threats
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 May 2014 17:53:05 -0000

Thanks for agreeing to update the document. I would be happy to contribute to discussions related to the update. Please include me on the appropriate point to point exchanges. 

Thanks, Ross

-----Original Message-----
From: lisp [] On Behalf Of Damien Saucez
Sent: Tuesday, May 27, 2014 12:06 PM
To: LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats

Dear all,

Thank you all for the passion you put in discussing the threats
document.  We have read all the arguments and arrived to the
conclusion that the threat document needs to be reshaped so to clear
all misunderstandings.  We will provide a new version for early July
that does not exclude any scenarios.  Actually most of problems
pinpointed are already covered somehow in the document but
precisions/rephrasing have to be done to make things clear.

For the sake of efficiency, while writing the new proposal in the
coming weeks, we will make point-to-point exchanges with the different
people that contributed to the discussion so to be sure that we
address all their comments.


Damien Saucez

On 27 May 2014, at 17:12, Joel M. Halpern <> wrote:

> Can we please not get into a debate about how well BCP38 is or is not deployed, whether violations are remotely detectable, ...This is NOT the working group for that.
> For our purposes, given that source address forging is known to occur, we have to allow it in the threat analysis.
> Yours,
> Joel
> On 5/27/14, 11:04 AM, Dino Farinacci wrote:
>>> Also, recall that large BCP38 holes exist in today's internet.
>> And I am going to repeat again, this is not a binary statement. That is, if a BCP38 hole exists in one part of the network, source spoofing can still be detected in other parts of the network.
>> Dino

lisp mailing list