[secdir] draft-shiomoto-ccamp-switch-programming-05

Rob Austein <sra@hactrn.net> Thu, 11 August 2011 05:40 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC921F8ABB; Wed, 10 Aug 2011 22:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.952
X-Spam-Level:
X-Spam-Status: No, score=-99.952 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoJWsNKqa+8B; Wed, 10 Aug 2011 22:40:11 -0700 (PDT)
Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id 4412721F877F; Wed, 10 Aug 2011 22:40:11 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-66-30-16-106.hsd1.ma.comcast.net [66.30.16.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 96E56BBDC; Thu, 11 Aug 2011 05:40:43 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id E18E03DA59E; Thu, 11 Aug 2011 01:40:42 -0400 (EDT)
Date: Thu, 11 Aug 2011 01:40:42 -0400
From: Rob Austein <sra@hactrn.net>
To: iesg@ietf.org, secdir@ietf.org, draft-shiomoto-ccamp-switch-programming.all@tools.ietf.org
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20110811054042.E18E03DA59E@minas-ithil.hactrn.net>
Subject: [secdir] draft-shiomoto-ccamp-switch-programming-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Thu, 11 Aug 2011 05:40:11 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This draft is a bit of Talmudic commentary on the RSVP-TE scripture.
The draft at hand defines no new protocol, nor does it define any new
operational procedure.  Rather, it attempts to summarize and clarify
guidance from the existing specifications on the subject of when it is
"safe" to assume that Label Switched Paths (LSPs) have been set up on
the data plane and may be used for sending traffic.

The kicker here is the definition of "safe".  As the subject is
traffic engineering, loss of money and data are of course issues, but
the more disturbing issue is that (according to the authors -- I have
no reason to disbelieve them but have not independently verified this)
there is a risk of bodily harm to "service personnel", because, for
some of the technologies that use this protocol, deciding to start
sending data equates to turning on lasers.

As this draft defines nothing new, it would be hard to claim that the
risk factor here is this draft's fault.  The Security Considerations
section does call out the human safety issue, albeit briefly.

The discussion of the ResvConf message in section 3.3 is a bit odd.
It seems to be saying that waiting for the ResvConf message would be
an excellent way of being sure it's "safe" to start transmitting, but
that implementations should nevertheless not use this mechanism,
because it would be wasteful (ie, this is traffic engineering) and
unreliable (because many GMPLS implementations don't bother with this
message).  Given the human safety concerns raised in this draft I was
a bit surprised by this approach, I would have expected instead a
discussion of the merits of requiring implementations to support this
behavior so that it could be made mandatory.   But I could easily be
missing something here, as I'm not an MPLS expert.