Last Call Review of draft-ietf-teas-fast-lsps-requirements-01
review-ietf-teas-fast-lsps-requirements-01-secdir-lc-hartman-2015-09-24-00
| Request | Review of | draft-ietf-teas-fast-lsps-requirements |
|---|---|---|
| Requested revision | No specific revision (document currently at 02) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2015-09-30 | |
| Requested | 2015-09-17 | |
| Authors | Andrew G. Malis , Brian J. Wilson , George Clapp , Vishnu Shukla | |
| Draft last updated | 2015-09-24 | |
| Completed reviews |
Genart Last Call review of -01
by
Peter E. Yee
(diff)
Secdir Last Call review of -01 by Sam Hartman (diff) |
|
| Assignment | Reviewer | Sam Hartman |
| State | Completed | |
| Review |
review-ietf-teas-fast-lsps-requirements-01-secdir-lc-hartman-2015-09-24
|
|
| Reviewed revision | 01 (document currently at 02) | |
| Result | Has Issues | |
| Completed | 2015-09-24 |
review-ietf-teas-fast-lsps-requirements-01-secdir-lc-hartman-2015-09-24-00
Hi.
I am the assigned secdir reviewer for this draft on requirements for
very fast GMPLS path establishment.
This draft outlines scaling requirements for new applications of GMPLS.
I'd like to flag this draft for particular review from the security ADs
and recommend that the IESG consider a process question and get input
from the sponsoring AD.
So, for the security ADS:
The security considerations section reads in its entirety:
. Security Considerations
Being able to support very fast setup and a high churn rate of GMPLS
LSPs is not expected to adversely affect the underlying security
issues associated with existing GMPLS signaling.
however the draft talks about increasing the number of cases where GMPLS
paths cross administrative boundaries and significantly increasing the
scale of GMPLS applications.
I don't think we have good security solutions for cases where we're
trying to do PCE-like things across mutually suspicious or potentially
hostile administrative boundaries.
And yes it's reasonable to assume that there are business relationships
in place here, but we also understand from our experience with BGP and
other internet-scale services the limitations of that.
I think significantly more security work is consider.
On a general level, there's basically no justification for the
requirements given.
For example, the document talks about how cloud computing is an
application that will drive these requirements. The document neither
talks about nor cites any explanation of what it is about cloud
computing that creates that need nor gives the reader any ability to
evaluate whether the need is real.
The depth of analysis is similar for all the other cited applications.
We jump from very broad staments like "cloud computing, datacenters and
data visualization will need this," to specific requirements in terms of
requests per second.
I'd particularly like to call out section 2:
2. Background
The Defense Advanced Research Projects Agency (DARPA) Core Optical
Networks (CORONET) program [Chiu], is an example target environment
that includes IP and optical commercial and government networks, with
a focus on highly dynamic and resilient multi-terabit core networks.
It anticipates the need for rapid (sub-second) setup and SONET/SDH-
like restoration times for high-churn (up to tens of requests per
second network-wide and holding times as short as one second) on-
demand wavelength, sub-wavelength and packet services for a variety
of applications (e.g., grid computing, cloud computing, data
visualization, fast data transfer, etc.). This must be done while
meeting stringent call blocking requirements, and while minimizing
the use of resources such as time slots, switch ports, wavelength
conversion, etc.
I recommend that someone take a look at the material on that DARPA
project and see how well the DARPA requirements align with the
recommendations in this spec.
I'm somewhat concerned that DARPA put together a research project and
said "Hey we'd like these things," and now the IETF, without any
significant independent analysis is rubber stamping that as our
requirements in this space.
I don't know that's what happened here, thus I have not copied
ietf at ietf.org.
However, DARPA's request should not represent an informed consensus of
the IETF.
I'd like to see the IESG evaluate whether we actually have done our own
analysis here and whether there is an informed consensus behind this
document.
Thanks for your consideration,
--Sam