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

From: Albert Cabellos <[email-masked]>
Date: Thu, 10 Oct 2013 17:40:05 +0200

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 <[email-masked]> 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
>
>
>
>