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

"BRUNGARD, DEBORAH A" <> Mon, 21 September 2015 21:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E9661A904A; Mon, 21 Sep 2015 14:10:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AO7T1y2qnMW2; Mon, 21 Sep 2015 14:10:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 128A41A9034; Mon, 21 Sep 2015 14:10:17 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id t8LL9VEX048788; Mon, 21 Sep 2015 17:10:15 -0400
Received: from ( []) by with ESMTP id 1x2n4ck9m2-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Sep 2015 17:10:14 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id t8LLADjd017479; Mon, 21 Sep 2015 17:10:13 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t8LL9xCb017258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Sep 2015 17:10:09 -0400
Received: from ( []) by (RSA Interceptor); Mon, 21 Sep 2015 21:09:47 GMT
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 17:09:47 -0400
To: "Andrew G. Malis" <>, Sam Hartman <>
Thread-Topic: Secdir Review of draft-ietf-teas-fast-lsps-requirements-01
Thread-Index: AQHQ9IYJxnPjPhMq40utAuh70RK6mp5Hb2AA///9luA=
Date: Mon, 21 Sep 2015 21:09:46 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F64C10EAA68C8044B33656FA214632C85272FBC1MISOUT7MSGUSRDE_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-21_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1509210295
Archived-At: <>
X-Mailman-Approved-At: Mon, 21 Sep 2015 14:24:04 -0700
Cc: "" <>, "" <>, IESG <>, "" <>
Subject: Re: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Sep 2015 21:10:26 -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-

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


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


On Mon, Sep 21, 2015 at 11:55 AM, Sam Hartman <<>> wrote:

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<>.
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

Thanks for your consideration,