Subject: [lisp] Security Considerations

From: Eliot Lear <[email-masked]>
Date: Fri, 20 May 2011 16:49:48 +0200

Everyone,

After a discussion with some of the folks who support the security
considerations text, I would like to propose two changes to
draft-ietf-lisp-12, as follows:

In section 2, remove an ambiguity about what the last phrase of the
first sentence is modifying.  AKM may not be required for all of LISP. 
However, AKM should be addressed.  So...

OLD:

   This experimental specification does not address automated key
   management which would be required for an Internet standard
   equivalent.  See Section 12.1 for further security details.

NEW:

   This experimental specification does not address automated key
   management.  Addressing automated key management is necessary for
   Internet standards.  See Section 12 for further security details.

In Section 12.1, the text seems to make normative demands in an
experimental document.  To me that's what a charter is for, and
certainly not what an experimental document should have in it.  In
addition, mentioning "areas" in a document serves only to confuse the
reader. That shifts focus again from the experiment to some sort of
process.  Finally, the text does not mention ongoing related work.  That
should get fixed.  And so I propose the following:

OLD:

12.1.  IETF Security Area Statement

   This document represents the thinking of the LISP working group.  The
   Security Area of the IETF believes there is an open security issue
   how LISP interacts with BCP 107's guidance on automated key
   management.  This and other issues would need to be resolved before
   standardization of LISP.  Accounting for these concerns may change
   the underlying design of LISP.  It is important that deferring these
   discussions in order to publish an experimental protocol sooner not
   restrict a standardized solution that balances concerns of all areas
   of the IETF.

NEW:

[remove paragraph heading]

   This experimental specification does not address automated key management
   (AKM). BCP 107 provides guidance in this area.  In addition, at the time
   of this writing, substantial work is being undertaken to improve
   security of the routing system [KARP, RPKI, BGPSEC, LISP-SEC].
   Future work on LISP should address BCP-107 as well as other open security
   considerations, which may require changes to this specification.

This solves the following problems:

    * It states very clearly that there is an open issue.
    * It removes an ambiguity that would lead one to believe that
      analysis of the problem is not the first step.
    * Existing relevant work is stated.
    * Concerns of the directorate are addressed (I hope).
    * It does not make normative statements in an experimental document.

Comments?

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 20 May 2011 15:30:29 -0400

Just to add some context to Eliot's note, let me provide some explanation.

The underlying issues that Eliot raises here were raised with me.
I did not want to go back and forth ahving the working group reach an 
agreement, then go to the security folks to see if they would agree, and 
back, and forth, and ...

So we arranged to have some discussion, resulting in a call, at which 
those of us on the call agreed to the text Eliot sent to the list.  (A 
rough consensus of the call.)  However, as it was a private call, Eliot 
said (and I agreed) that he would send the text to the list for others 
to see before the authors incorporated the revisions in going from -12 
to -13.

So Eliot's note serves to allow the WG to discuss it, and allow anyone 
else with concerns to raise them.

Yours,
Joel

On 5/20/2011 10:49 AM, Eliot Lear wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp