Subject: [lisp] Proposed caveat text for draft-ietf-lisp

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 8 Jan 2012 20:48:44 -0000

All (including the LISP list who have a right to be involved in this sort of
discussion),

During IESG review of draft-ietf-lisp-16 I undertook to suggest modifications
that would address a major part of my Discuss and would help me to be able to
clear my Discusses on a couple of other LISP documents by insertion of direct
references to this document.

Sorry that it has taken me so long (I plead ITU-T and Judaeo-Christian culture).

Here are my suggestions based on draft-ietf-lisp-19. The point of the changes is
to provide suitable caveats about the known (and unknown) qualities of LISP and
its suitability for deployment. This helps address the requirements of the LISP
WG Charter to make such clear statements in *all* LISP I-Ds. What I am
suggesting is that this I-D contains the strong statements below, and all other
documents are able to include a very simple (one line?) caveat that points to
this document. If/when LISP is upgraded as a result of experimentation, it will
be easier to perform the updates since only this one document has to be modified
to change the caveat.

Cheers,
Adrian

===

Abstract second paragraph (text taken largely from Charter)

OLD
   Design and development of LISP was largely motivated by the problem
   statement produced by the October 2006 IAB Routing and Addressing
   Workshop.
NEW
   Design and development of LISP was largely motivated by the problem
   statement produced by the October 2006 IAB Routing and Addressing
   Workshop.  LISP remains an early-stage, experimental proposal with
   unevaluated and potentially harmful side-effects to Internet traffic
   carried by the involved routers, have parts where deployment 
   incentives are unclear, and is not recommended for deployment beyond
   experimental situations
END

---

Section 2 - Final paragraph (text taken largely from Charter)

OLD
   This experimental specification has areas that require additional
   experience and measurement.  Results of such work may lead to
   modifications and enhancements of protocol mechanisms defined in this
   document.  See Section 15 for specific, known issues that are in need
   of further work during development, implementation, and prototype
   deployment.
NEW
   LISP is an early-stage, experimental proposal with unevaluated and 
   potentially harmful side-effects to Internet traffic carried by the
   involved routers, has parts where deployment incentives are unclear,
   and is NOT RECOMMENDED for deployment beyond experimental situations.
   Furthermore, some components of the LISP solution (such as the
   identifier to locator mapping system) need to be evaluated against
   other experimental proposals to determine which of many design
   alternative is the best.

   This experimental specification has areas that require additional
   experience and measurement.  Results of such work may lead to
   modifications and enhancements of protocol mechanisms defined in this
   document.  See Section 2.1 for specific, known issues that are in need
   of further work during development, implementation, and 
   experimentation.

   An examination of the implications of LISP on Internet traffic, 
   applications, routers, and security is for future study. This 
   analysis will explain what role LISP can play in scalable routing and
   will also look at scalability and levels of state required for
   encapsulation, decapsulation, liveness, and so on.
END

---

New Section 2.1 (Text taken from Section 15 with deltas [punctuation, final
bullet, and final para])

NEW
2.1.  Known Open Issues and Areas of Future Work

   As an experimental specification, this work is, by definition,
   incomplete.  Specific areas where additional experience and work are
   needed include:

   o  At present, only [ALT] is defined for implementing a database of
      EID-to-RLOC mapping information.  Additional research on other
      mapping database systems is strongly encouraged.

   o  Failure and recovery of LISP site partitioning (see Section 6.4),
      in the presence of redundant configuration (see Section 8.5) needs
      further research and experimentation.

   o  The characteristics of map-cache management under exceptional
      conditions, such as denial-of-service attacks are not fully
      understood.  Further experience is needed to determine whether
      current caching methods are practical or in need of further
      development.  In particular, the performance, scaling and security
      characteristics of the map-cache will be discovered as part of
      this experiment.  Performance metrics to be observed are packet
      reordering associated with the LISP data probe and loss of the
      first packet in a flow associated with map-caching.  The impact of
      these upon TCP will be observed.  See Section 12 for additional
      thoughts and considerations.

   o  Preliminary work has been done to ensure that sites employing LISP
      can interconnect with the rest of the Internet.  This work is
      documented in [INTERWORK], but further experimentation and
      experience is needed.

   o  At present, no mechanism for automated key management for message
      authentication is defined.  Addressing automated key management is
      necessary before this specification could be developed into a
      standards track RFC.  See Section 12 for further details regarding
      security considerations.

   o  In order to maintain security and stability, Internet Protocols
      typically isolate the control and data planes.  Therefore, user
      activity cannot cause control plane state to be created or
      destroyed.  LISP does not maintain this separation.  The degree to
      which the loss of separation impacts security and stability is a
      topic for experimental observation.

   o  LISP allows for different mapping database systems to be used.
      While only one [ALT] is currently well-defined, each mapping
      database will likely have some impact on the security of the EID-
      to-RLOC mappings.  How each mapping database system's security
      properties impact on LISP overall is for further study.

   o  An examination of the implications of LISP on Internet traffic, 
      applications, routers, and security is needed. This will help to
      understand the consequences for network stability, routing 
      protocol function, routing scalability, migration and backward
      compatibility, and implementation scalability (as influenced by
      additional protocol components, additional state, and additional
      processing for encapsulation, decapsulation, liveness).

   Other LISP documents may also include open issues and areas for
   future work.
END

---
 
Remove Section 15 (Moved to 2.1)

DELETE
2.1.  Known Open Issues and Areas of Future Work

   As an experimental specification, this work is, by definition,
   incomplete.  Specific areas where additional experience and work are
   needed include:

   o  At present, only [ALT] is defined for implementing a database of
      EID-to-RLOC mapping information.  Additional research on other
      mapping database systems is strongly encouraged.

   o  Failure and recovery of LISP site partitioning (see Section 6.4),
      in the presence of redundant configuration (see Section 8.5) needs
      further research and experimentation.

   o  The characteristics of map-cache management under exceptional
      conditions, such as denial-of-service attacks are not fully
      understood.  Further experience is needed to determine whether
      current caching methods are practical or in need of further
      development.  In particular, the performance, scaling and security
      characteristics of the map-cache will be discovered as part of
      this experiment.  Performance metrics to be observed are packet
      reordering associated with the LISP data probe and loss of the
      first packet in a flow associated with map-caching.  The impact of
      these upon TCP will be observed.  See Section 12 for additional
      thoughts and considerations.

   o  Preliminary work has been done to ensure that sites employing LISP
      can interconnect with the rest of the Internet.  This work is
      documented in [INTERWORK] but further experimentation and
      experience is needed.

   o  At present, no mechanism for automated key management for message
      authentication is defined.  Addressing automated key management is
      necessary before this specification could be developed into a
      standards track RFC.  See Section 12 for further details regarding
      security considerations.

   o  In order to maintain security and stability, Internet Protocols
      typically isolate the control and data planes.  Therefore, user
      activity cannot cause control plane state to be created or
      destroyed.  LISP does not maintain this separation.  The degree to
      which the loss of separation impacts security and stability is a
      topic for experimental observation.

   o  LISP allows for different mapping database systems to be used.
      While only one [ALT] is currently well-defined, each mapping
      database will likely have some impact on the security of the EID-
      to-RLOC mappings.  How each mapping database system's security
      properties impact on LISP overall is for further study.
END