[secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01
Sam Hartman <hartmans-ietf@mit.edu> Mon, 21 September 2015 15:55 UTC
Return-Path: <hartmans-ietf@mit.edu>
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 CB8AA1B33C8; Mon, 21 Sep 2015 08:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665] autolearn=no
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 aJoBs9aNv3Xj; Mon, 21 Sep 2015 08:55:50 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5963B1B33D1; Mon, 21 Sep 2015 08:55:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E601620801; Mon, 21 Sep 2015 11:55:16 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv33nv6_EIMb; Mon, 21 Sep 2015 11:55:16 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 21 Sep 2015 11:55:16 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4FB1A80D01; Mon, 21 Sep 2015 11:55:48 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: secdir@ietf.org, sec-ads@ietf.org, iesg@ietf.org
Date: Mon, 21 Sep 2015 11:55:48 -0400
Message-ID: <tsly4fzkbqz.fsf@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/MrBHilXKGUsXzS1lLXTMz2rBURA>
Cc: draft-ietf-teas-fast-lsps-requirements-01.all@ietf.org
Subject: [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 15:55:52 -0000
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
- [secdir] Secdir Review of draft-ietf-teas-fast-ls… Sam Hartman
- Re: [secdir] Secdir Review of draft-ietf-teas-fas… Andrew G. Malis
- Re: [secdir] Secdir Review of draft-ietf-teas-fas… BRUNGARD, DEBORAH A
- Re: [secdir] Secdir Review of draft-ietf-teas-fas… Lou Berger