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

"Andrew G. Malis" <> Mon, 21 September 2015 16:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2F7401A9139; Mon, 21 Sep 2015 09:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lafuCjYbaRuA; Mon, 21 Sep 2015 09:29:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 247481A9127; Mon, 21 Sep 2015 09:29:49 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so119587622wic.0; Mon, 21 Sep 2015 09:29:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=MC4lsP9vFFJwW0UAc57DOFe9JLGKN3yA6hUXNkkoIsM=; b=uQbwFexMrd9ty5W5S72WCGqw/lBf7zASKBuiOOe6cPQ3Krs/rxiPBMI9ELV3+tnIWL dmruxIFuQ+VTfUSNbP30ipnLGJm2IeSHFE5kwaepSaRRFRga0WNIDrhp19DmNYSJZw9y zR/H91obZcHTkcvCAX4RWBTDmQx3Gely6Kk0JAsNz85/zjhkfs2NsK6/PdHK91nPF+Ih SaYSRK2scVV9S22Gh4PquAhZyqx2WMnADG+lTJvh6rfIa0FX4YmWJBW7lJ5edFgVpsAF FCw2yYrLmiw8EAJf8wKjSOlRil/31EP44l8lAJG17U65L6T7a+Pgp7lO1izRUP0zYWAO EXfA==
X-Received: by with SMTP id n7mr23196701wjf.112.1442852987728; Mon, 21 Sep 2015 09:29:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 21 Sep 2015 09:29:28 -0700 (PDT)
In-Reply-To: <>
References: <>
From: "Andrew G. Malis" <>
Date: Mon, 21 Sep 2015 12:29:28 -0400
Message-ID: <>
To: Sam Hartman <>
Content-Type: multipart/alternative; boundary=047d7b5d33eecbf960052044630c
Archived-At: <>
X-Mailman-Approved-At: Mon, 21 Sep 2015 09:42:33 -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 16:29:58 -0000


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:

> 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