Re: [secdir] SecDir Review of draft-ietf-lisp-deployment

Albert Cabellos <albert.cabellos@gmail.com> Thu, 10 October 2013 15:40 UTC

Return-Path: <albert.cabellos@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD7B11E81E0 for <secdir@ietfa.amsl.com>; Thu, 10 Oct 2013 08:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOlefM09pNXb for <secdir@ietfa.amsl.com>; Thu, 10 Oct 2013 08:40:08 -0700 (PDT)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id E7E2111E81DF for <secdir@ietf.org>; Thu, 10 Oct 2013 08:40:06 -0700 (PDT)
Received: by mail-lb0-f180.google.com with SMTP id q8so2207203lbi.25 for <secdir@ietf.org>; Thu, 10 Oct 2013 08:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OkXdsYXhQ83mkyb2qsc0k8qW7ylnCOdmAdDTu6If0I0=; b=c8Oj86t9y1enTY11Nfeih1CeWGN+bq0kyAq2h1EeCPdVg7VwQKz9tJB3cMtWBCPc5C DTUJah8QwUoyNdIXmMrv0t8l5DuxCUUjIY/ov7/YELr+McnjHitrPkedOUqDhKZj1ZKV 8XWhhMupDR0mufjwAEphN9TtUMm9OtyTWcXBT8qCpmrhwb0MkuiBfbSzmwe9o5ZIqUN2 1bWLUSNewqOmuXu2ZGtEGTrB1Bn7fph7PZfy762Sd0IsdDn+ohBDRyq2MG+DVJFHLfPi /Li4f3ZdSmCP3uA1BD2t96VFe3Xjp+273V8FRvrw1SqqUiQp7IM+i9FFc2A9I4lSdFw4 xP8A==
MIME-Version: 1.0
X-Received: by 10.152.243.42 with SMTP id wv10mr2104790lac.39.1381419605751; Thu, 10 Oct 2013 08:40:05 -0700 (PDT)
Received: by 10.112.163.68 with HTTP; Thu, 10 Oct 2013 08:40:05 -0700 (PDT)
In-Reply-To: <01D946E4-348D-4A3D-ABF8-B7DBD6F74F6E@kumari.net>
References: <01D946E4-348D-4A3D-ABF8-B7DBD6F74F6E@kumari.net>
Date: Thu, 10 Oct 2013 17:40:05 +0200
Message-ID: <CAGE_QezGvcnhHbjEMvG5_gi735yK8BWyPDYTKofc-w+AfTyBPw@mail.gmail.com>
From: Albert Cabellos <albert.cabellos@gmail.com>
To: Warren Kumari <warren@kumari.net>
Content-Type: multipart/alternative; boundary=001a1134290ce2fad004e864d07f
X-Mailman-Approved-At: Thu, 10 Oct 2013 08:47:15 -0700
Cc: draft-ietf-lisp-deployment.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SecDir Review of draft-ietf-lisp-deployment
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: acabello@ac.upc.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Oct 2013 15:44:26 -0000

Dear Warren,

See my replies inline, please let me know if the suggested changes address
your comments,


On Sat, Aug 24, 2013 at 1:19 AM, Warren Kumari <warren@kumari.net>; wrote:

> 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.
>
> This draft describes LISP deployment scenarios. It represents current
> thinking and is expected to change (I guess be obsoleted / replaced?) as
> more experience is gained with deployment.
>
> Summary: I'm not sure what to do here.
>
> The document is very well written, and the authors seem to have taken care
> to consider the implications of various deployment scenarios.
> In spite of knowing very little about LISP I found the document to be
> accessible and easily understood. It clearly lays out the considerations
> for different deployments, and provides some guidance as to how to select.
>

Thanks!


>
>
> However, the security considerations section simply says:
> "Security implications of LISP deployments are to be discussed in
>    separate documents.  [I-D.ietf-lisp-threats ] gives an overview of
>    LISP threat models, while securing mapping lookups is discussed in
>    [I-D.ietf-lisp-sec]."
>
> This is a deployment document, and so this may be perfectly acceptable;
> the "separate documents" may completely cover everything. Or not.
> I am unclear if the authors mean that I-D.ietf-lisp-threats and
> I-D.ietf-lisp-sec cover all security considerations, or if the implication
> is that there will be other documents that cover the security implications.
> http://i.imgur.com/5rTHfRs.jpg
>
>
>
What we try to explain is that both [I-D.ietf-lisp-threats] and
[I-D.ietf-lisp-sec] cover all security considerations. As far as I know
there are no plans to detail LISP security considerations in other
documents. We suggest to rephrase this sentence to:

"*All* security implications of LISP deployments are to be discussed in
   separate documents.  [I-D.ietf-lisp-threats ] gives an overview of
   LISP threat models, while securing mapping lookups is discussed in
   [I-D.ietf-lisp-sec]"



>
> Section 2.4.  "Inter-Service Provider Traffic Engineering" says:
> "Failure to follow these recommendations may lead to operational and
> security issues when deploying this scenario."
> I think that a (short) explanation of what the security issues are if you
> don't follow the recommendations would be nice.
>
>
>
Not following such recommendations means requiring participating ISPs to
register prefixes they do not own, this in turn requires complex
authentication mechanisms or facing traffic redirection attacks. We suggest
to rephrase the paragraph from:

"Second, the scenario is only recommended for ISPs providing

   connectivity to LISP sites, such that source RLOCs of packets to be
   recursively encapsulated belong to said ISP.  Otherwise the


   participating ISPs must register prefixes they do not own in the
   above mentioned private mapping system.  Failure to follow these
   recommendations may lead to operational and security issues when
   deploying this scenario."


to

"Second, the scenario is only recommended for ISPs providing connectivity
to LISP sites, such that source RLOCs of packets to be recursively
encapsulated belong to said ISP. Otherwise the participating ISPs must
register prefixes they do not own in the above mentioned private mapping
system. *This results in either requiring complex authentication mechanisms
or enabling simple traffic redirection attacks.* Failure to follow these
recommendations may lead to operational security issues when deploying this
scenario"


> Nits:
> Section 4.2:
> "For more details on P-ETRs see the [RFC6832] draft." -- I think that this
> could be better worded as "For more details on P-ETRs see [RFC6832]" (think
> this was written while RFC6832 was still a draft).
>
>
Right, thanks!


> ID NITs complains about use of RFC2119 language ("It is NOT RECOMMENDED
> for deployment"), but no RFC2119 reference / boilerplate.
> I'm scraping the bottom of the barrel here, 'tis well written..
>

Thanks for catching this, we┬┤ll add a reference to RFC2119.


> --
> It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
> to try to do it with ten blunt axes instead.
>     --  E.W Dijkstra, 1930-2002
>
>
>
>