Re: [secdir] review of draft-saucez-lisp-impact-04.txt

Luigi Iannone <> Sat, 17 October 2015 19:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 816DA1ACD33; Sat, 17 Oct 2015 12:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OM85YpfFQhvI; Sat, 17 Oct 2015 12:49:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0CD3A1ACD31; Sat, 17 Oct 2015 12:49:28 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E90E7FFB62; Sat, 17 Oct 2015 21:49:25 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10032) with ESMTP id S1k5maBqW0Dz; Sat, 17 Oct 2015 21:49:25 +0200 (CEST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41E7E1001DB; Sat, 17 Oct 2015 21:49:25 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.0 41E7E1001DB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=A6AEC2EE-1106-11E5-B10E-D103FDDA8F2E; t=1445111365; bh=treUJkF87wpyKyDgI/oVPtNJ3hGVYFMIe6yu83GceMI=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=YIy2LRPsquUF5AunwrkE0YZWaxOLFJC7q9kCk20Qy7bvWuw3nXTouHlIwzRhbyHt6 0ay9LNgINZOnz5lZ0SRYeRj9nMHdQau2SCpj0IY4lSFyp+kV7SLf2DYknSqSIgMOdq JaKRP83wsog4PEmXI3ySkMUNu5IY3gPukm83cWss=
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id qkSR0zG5D0DQ; Sat, 17 Oct 2015 21:49:25 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id DEA9A1001D7; Sat, 17 Oct 2015 21:49:24 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Luigi Iannone <>
In-Reply-To: <>
Date: Sat, 17 Oct 2015 21:49:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
X-Mailer: Apple Mail (2.3094)
Archived-At: <>
X-Mailman-Approved-At: Thu, 22 Oct 2015 07:18:02 -0700
Cc: Damien Saucez <>,, The IESG <>,
Subject: Re: [secdir] review of draft-saucez-lisp-impact-04.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Oct 2015 19:49:30 -0000

Hi Hilarie,

In the current format the security section just states that actually 
security is out of the scope of the document.
This was actually an outcome of the WG discussion, were it was
decided to clearly separate security and impact.

Yet, it is true that the security section is poor, while 
security analysis is out of the scope of the document, it does not 
mean that we cannot mention the major security points 
thoroughly analysed in the threats document.

Hence we propose to modify the security section as follows:

Old Version:

	Security and threats analysis of the LISP protocol is out of the
	scope of the present document.  A thorough analysis of LISP security
	threats is detailed in [I-D.ietf-lisp-threats].

NEW Version:

	A thorough security and threats analysis of the LISP protocol
	is carried out in details in [I-D.ietf-lisp-threats]. 
	Like for other Internet technologies, also for LISP most of 
	threats can be mitigated using Best Current Practice, meaning 
	with careful deployment an configuration (e.g., filter) and also 
	by activating only features that are really necessary in the 
      deployment and verifying all the information obtained from third 
	parties. Unless gleaning features (actually deprecated in
	RFC 6830 [RFC6830]) are used, the  LISP data-plane shows the 
	same level of security as other IP-over-IP technologies.
	From a security perspective, the control-plane remains the 
	critical part of the LISP architecture.
	To maximally mitigate the threats on the mapping
 	system, authentication must be used, whenever possible, for all 
	control plane messages.
	Current specification already offer security mechanisms 
	([RFC6833],  [I-D.ietf-lisp-sec]) able to strongly reduce threats 
	in non-trustable environments such as the Internet.  
	Actually, LISP specifications define a generic authentication data field 
	control plane messages [RFC6830] allowing to propose a general
 	authentication mechanisms for the LISP control-plane while staying
 	backward compatible. 

We hope this delivers the information you were looking for.



> On 13 Oct 2015, at 19:28, Hilarie Orman <> wrote:
> Thanks for pointing out my mistake.  I have now reviewed
> draft-ietf-lisp-impact-04 and the same comments about security apply.
> Hilarie
>> From: Damien Saucez <>
>> Date: Tue, 13 Oct 2015 08:13:08 +0200
>> Thank you for the review. I would have a question regarding the document you reviewed. Did you review th
>> draft-sauces-lisp-impact-04
>> or 
>> draft-ietf-lisp-impact-04
>> Thank you,
>> Damien Saucez 
>> On 13 Oct 2015, at 05:01, Hilarie Orman <> wrote:
>>> Secdir review of LISP Impact
>>> draft-saucez-lisp-impact-04.txt
>>> Do not be alarmed.  I have reviewed this document as part of the
>>> security directorate's ongoing effort to review all IETF documents
>>> being processed by the IESG.  These comments were written primarily
>>> for the benefit of the security area directors.  Document editors and
>>> WG chairs should treat these comments just like any other last call
>>> comments.
>>> A new way of handling routing information has been defined in IETF
>>> documents about the Locator/Identifier Separation Protocol (LISP).
>>> The draft under discussion here elaborates on the possible
>>> consequences of widespread use of LISP.
>>> The draft punts on security considerations and refers to previous
>>> documents describing threats to LISP and how LISP uses cryptography
>>> for protecting the integrity of its messages.
>>> It seems to me that if the purported impact of LISP is to "scale the
>>> Internet", then its impact on security should be a major part of the
>>> equation.  Will it make routing information more or less vulnerable
>>> malicious manipulation?  How will it affect the stability of a network
>>> that is under constant threat of attack?
>>> I don't feel that the draft can achieve its purpose without addressing
>>> security.
>>> Hilarie
>>> PS. I was very disappointed to realize that this was not a draft
>>> about my favorite programming language.