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

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

Return-Path: <agmalis@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7401A9139; Mon, 21 Sep 2015 09:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lafuCjYbaRuA; Mon, 21 Sep 2015 09:29:50 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=gmail.com; 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 10.194.23.167 with SMTP id n7mr23196701wjf.112.1442852987728; Mon, 21 Sep 2015 09:29:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.9.212 with HTTP; Mon, 21 Sep 2015 09:29:28 -0700 (PDT)
In-Reply-To: <tsly4fzkbqz.fsf@mit.edu>
References: <tsly4fzkbqz.fsf@mit.edu>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 21 Sep 2015 12:29:28 -0400
Message-ID: <CAA=duU0H9GqLoQe3KwDUwfbMiJmpU7pgSnqTsz2rkbGc-rUvvA@mail.gmail.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Content-Type: multipart/alternative; boundary=047d7b5d33eecbf960052044630c
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/vdauXy2PqW6oHRDut4lSt2zFUAQ>
X-Mailman-Approved-At: Mon, 21 Sep 2015 09:42:33 -0700
Cc: sec-ads@ietf.org, draft-ietf-teas-fast-lsps-requirements.all@ietf.org, IESG <iesg@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2015 16:29:58 -0000

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 <hartmans-ietf@mit.edu> 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
> ietf@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
>