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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
