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

Lou Berger <> Tue, 22 September 2015 00:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3A1E31ACDE5 for <>; Mon, 21 Sep 2015 17:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RUF0ZmwRrmuM for <>; Mon, 21 Sep 2015 17:34:51 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id DD57D1ACDC3 for <>; Mon, 21 Sep 2015 17:34:50 -0700 (PDT)
Received: (qmail 7463 invoked by uid 0); 22 Sep 2015 00:34:49 -0000
Received: from unknown (HELO cmgw2) ( by with SMTP; 22 Sep 2015 00:34:49 -0000
Received: from ([]) by cmgw2 with id L0ai1r00U2SSUrH010alu0; Mon, 21 Sep 2015 18:34:47 -0600
X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=0RAR5D2yBdQrwp53PsoA:9 a=bCDC00nOpVNyUGZ6:21 a=BcFdZkG3eSuyAsUL:21 a=QEXdDO2ut3YA:10 a=XIqpo32RAAAA:8 a=WwByOlHt4hu4xHjUyu4A:9 a=D5SfZVLvXdNvwCW6:21 a=zMY0fasZuyrZ7ieZ:21 a=SpSLK2-eWlx-8gb-:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=EetcH9YsOCJOq+a9icPv48lgXRYpYGlUj6PBfHqWkXk=; b=jnRHjZc05EY8lpG2+WjpAHSoytN3JlB28pfENRSCtSDx+K7nDValVm0wo5phwNPwwTB63g6oeNSNyMhRxLC8wkVkltl2yppnPPl/vflPPG6y2b8ke4zrUJPHEK9ALxaU;
Received: from ([]:33356 helo=[]) by with esmtpa (Exim 4.84) (envelope-from <>) id 1ZeBXf-0008Nt-FN; Mon, 21 Sep 2015 18:34:44 -0600
To: "BRUNGARD, DEBORAH A" <>, "Andrew G. Malis" <>, Sam Hartman <>
References: <> <> <>
From: Lou Berger <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Mon, 21 Sep 2015 20:34:22 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070209020303010003080806"
X-Identified-User: {} {sentby:smtp auth authed with}
Archived-At: <>
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: Tue, 22 Sep 2015 00:34:54 -0000

    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.


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?
> 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 []
> *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
> 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 <
> <>> wrote:
> 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
> <>.
> 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