Subject: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Sep 2015 11:55:48 -0400

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
[email-masked].
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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 21 Sep 2015 12:29:28 -0400

Sam,

Thanks for your comments. We (the authors) will await further review from
the IESG before taking any particular action.

Cheers,
Andy

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Mon, 21 Sep 2015 21:09:46 +0000

Hi Sam,

Thanks for your review.

I see basically two concerns, one questioning the security aspects, the other on the general level questioning the document itself.

As the general level concern is much more serious, let’s address it first. Maybe some background would help. I was chair of CCAMP and then TEAS when the document transitioned to TEAS. At first the document was written in the style of being quite negative on GMPLS as the identified problems were based on incorrect interpretation of the RFCs (broken implementations). So the WG asked the authors to first be precise on their requirements before assuming new solutions were needed. After several spins, the WG was comfortable with the requirements. Folks didn’t question the requirements themselves as GMPLS is targeted at applications for improving connection set up times for large mesh networks vs. using a PCE/management system. And when asked, the authors said this was not targeted for wavelengths (where the physical connectivity is more constraining than the control plane signaling) but OTN (Optical Transport Network is a digital frame) e.g. from March 2014 CCAMP Meeting Notes:
“Lou Berger: [poll] how many have read the document [] how many think this is an interesting problem to discuss? [a good number for each]
George Swallow: What is achievable for OTN is much closer to your requirements than what is achievable for optical. I was wondering if requirements apply to both.
Andy Malis: They apply to both, we have possible solutions for both but before coming with solutions we want an agreement on requirements.
Rajan Rao: If we have separate data plane and control plane requirements, if the traffic doesn’t come out, what does it really mean?
Lou Berger: question for the list.
Adrian Farrel: I like this set of requirements, I hate you say you can't solve them with existing stuff. Push requirements and then we can work on an applicability to see if existing solutions can meet them.”

The Shepherd writeup provides more detail. And this is not the first document discussing optimizing set up times. RFC6383 was on optimizations and recently the MPLS WG has just completed draft-ietf-mpls-self-ping.

If you still are uncomfortable with these requirements, it would be best if you express your concerns with the TEAS WG. I noted you did not include them on your review.

On your second concern, the security implications. This is an informational document. As the shepherd writeup notes “The requirements put forth in this document may be the basis for future documents, some of which may be simply informational, while others may describe specific GMPLS protocol extensions. While some of these requirements may be have implications on implementations, the intent
is for the requirements to apply to GMPLS protocols and their standardized mechanisms.”

So it is unclear at this time if only an applicability statement is needed (informational on the “correct” use of GMPLS protocols/mechanisms and an understanding of the signaling aspects vs. the processing/implementation dependent aspects) or if new extensions/mechanisms are needed. For the security section, it was written based on the assumption that either this will only need an applicability document and, if it needs more, than one has something to base a security considerations. With this background, do you have suggestions to help the authors improve this section?

Again, thanks for your review-
Deborah

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Monday, September 21, 2015 12:29 PM
To: Sam Hartman
Cc: [email-masked]; [email-masked]; IESG; [email-masked]
Subject: Re: Secdir Review of draft-ietf-teas-fast-lsps-requirements-01

Sam,

Thanks for your comments. We (the authors) will await further review from the IESG before taking any particular action.

Cheers,
Andy

On Mon, Sep 21, 2015 at 11:55 AM, Sam Hartman <[email-masked]<mailto:[email-masked]>> wrote:

Hi.

[email-masked]<mailto:[email-masked]>.

--Sam

---

From: Lou Berger <[email-masked]>
Date: Mon, 21 Sep 2015 20:34:22 -0400

Sam,
    To add to Deborah's point re requirements. A lot of time was spent
discussing the requirements to ensure they were phrased in terms that
were generally applicable.  Since these were published we have seen a
number of documents and other new work which are all focused on scaling
and some of the other related requirements.  If your concern is that the
requirements represent just one organization's viewpoint that have been
rubber stamped, rest assured that this was/is not the case.

Lou

PS Disclaimer: I contributed to getting this document revised from it's
original form to what you see now.

On 9/21/2015 5:09 PM, BRUNGARD, DEBORAH A wrote:
>
> Hi Sam,
>
>  
>
> Thanks for your review.
>
>  
>
> I see basically two concerns, one questioning the security aspects,
> the other on the general level questioning the document itself.
>
>  
>
> As the general level concern is much more serious, let’s address it
> first. Maybe some background would help. I was chair of CCAMP and then
> TEAS when the document transitioned to TEAS. At first the document was
> written in the style of being quite negative on GMPLS as the
> identified problems were based on incorrect interpretation of the RFCs
> (broken implementations). So the WG asked the authors to first be
> precise on their requirements before assuming new solutions were
> needed. After several spins, the WG was comfortable with the
> requirements. Folks didn’t question the requirements themselves as
> GMPLS is targeted at applications for improving connection set up
> times for large mesh networks vs. using a PCE/management system. And
> when asked, the authors said this was not targeted for wavelengths
> (where the physical connectivity is more constraining than the control
> plane signaling) but OTN (Optical Transport Network is a digital
> frame) e.g. from March 2014 CCAMP Meeting Notes:
>
> “Lou Berger: [poll] how many have read the document [] how many think
> this is an interesting problem to discuss? [a good number for each]
>
> George Swallow: What is achievable for OTN is much closer to your
> requirements than what is achievable for optical. I was wondering if
> requirements apply to both.
>
> Andy Malis: They apply to both, we have possible solutions for both
> but before coming with solutions we want an agreement on requirements.
>
> Rajan Rao: If we have separate data plane and control plane
> requirements, if the traffic doesn’t come out, what does it really mean?
>
> Adrian Farrel: I like this set of requirements, I hate you say you
> can't solve them with existing stuff. Push requirements and then we
> can work on an applicability to see if existing solutions can meet them.”
>
>  
>
> The Shepherd writeup provides more detail. And this is not the first
> document discussing optimizing set up times. RFC6383 was on
> optimizations and recently the MPLS WG has just completed
> draft-ietf-mpls-self-ping.
>
>  
>
> If you still are uncomfortable with these requirements, it would be
> best if you express your concerns with the TEAS WG. I noted you did
> not include them on your review.
>
>  
>
> On your second concern, the security implications. This is an
> informational document. As the shepherd writeup notes “The
> requirements put forth in this document may be the basis for future
> documents, some of which may be simply informational, while others may
> describe specific GMPLS protocol extensions. While some of these
> requirements may be have implications on implementations, the intent
>
> So it is unclear at this time if only an applicability statement is
> needed (informational on the “correct” use of GMPLS
> protocols/mechanisms and an understanding of the signaling aspects vs.
> the processing/implementation dependent aspects) or if new
> extensions/mechanisms are needed. For the security section, it was
> written based on the assumption that either this will only need an
> applicability document and, if it needs more, than one has something
> to base a security considerations. With this background, do you have
> suggestions to help the authors improve this section?
>
>  
>
> *From:*Andrew G. Malis [mailto:[email-masked]]
> *Sent:* Monday, September 21, 2015 12:29 PM
> *To:* Sam Hartman
> *Cc:* [email-masked]; [email-masked]; IESG;
> [email-masked]
> *Subject:* Re: Secdir Review of draft-ietf-teas-fast-lsps-requirements-01
>
>  
>
> Sam,
>
>  
>
> Thanks for your comments. We (the authors) will await further review
> from the IESG before taking any particular action.
>
>  
>
> Cheers,
>
> Andy
>
>  
>
>  
>
> [email-masked] <mailto:[email-masked]>.