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 rev. 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 Malis, Brian Wilson, George Clapp, Vishnu Shukla
Draft last updated 2015-09-24
Completed reviews Genart Last Call review of -01 by Peter 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 rev. 01 (document currently at 02)
Review result Has Issues
Review completed: 2015-09-24

Review
review-ietf-teas-fast-lsps-requirements-01-secdir-lc-hartman-2015-09-24

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