[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