Re: [secdir] secdir review of draft-ietf-pce-wson-routing-wavelength-14

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 28 October 2014 14:17 UTC

Return-Path: <adrian@olddog.co.uk>
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 721A31A890C; Tue, 28 Oct 2014 07:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 AN18cbaabr0j; Tue, 28 Oct 2014 07:17:39 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8EE1A890A; Tue, 28 Oct 2014 07:17:38 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9SEEe4x029324; Tue, 28 Oct 2014 14:14:40 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s9SEEcea029282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Oct 2014 14:14:39 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Dan Harkins' <dharkins@lounge.org>
References: <28335d401a6c792d0259a03c5767c1dc.squirrel@www.trepanning.net>
In-Reply-To: <28335d401a6c792d0259a03c5767c1dc.squirrel@www.trepanning.net>
Date: Tue, 28 Oct 2014 14:17:30 -0000
Message-ID: <01ef01cff2b9$e9bbbc20$bd333460$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJCQpGZ4tuqLs2ag90k+IsjrSH9t5tg6Qhg
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21058.007
X-TM-AS-Result: No--16.820-10.0-31-10
X-imss-scan-details: No--16.820-10.0-31-10
X-TMASE-MatchedRID: QfHZjzml1E/D66A+AisN3eYAh37ZsBDCC/ExpXrHizwfXPl3V+d6vt+X Q++q8wX3leq4KPTW4v/21SimJ9AOh5kiR/yCW3xP1yMJs9mBCcUXRHoL/W4Y6lpbYq2f4jz+sT6 GSFHInVUgbI7ygWn76YQXLYN5+rsPfUZxHkB4Szt1fPeXvwXdiS1sTReN4bEUdE0auG3MZh/Pv2 tEtLx7eCYUfEtNd2yEI+hdWX4lCBHDBNgbKIiiTEKcYi5Qw/RVo4jW7zSDg9lAzN12EZ9S+JMBN mFHEDBE4vM1YF6AJbZcLc3sLtjOt+TCMddcL/gjkGUtrowrXLg=
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dLtZehZiTJ7a0D5V5C7TtB3btP4
Cc: draft-ietf-pce-wson-routing-wavelength.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-pce-wson-routing-wavelength-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Tue, 28 Oct 2014 14:17:46 -0000

Hi Dan,

Thanks for taking the time.

> This is a requirements document for additions to the PCEP protocol
> to support path computation in a wavelength-switched optical
> network. It describes what needs to be added to requests/responses
> to support routing and wavelength assignment to a path computation
> element (that supports both functions) for a path computation client.
> 
> The security considerations are basically a punt. There's information
> that an operator may not want to disclose and "[c]onsideration should
> be given to securing this information." That seems a little thin. At the
> very least some explanation of how this should be done. Do only the
> TLVs that represent these required additions require confidentiality?
> Is KARP a potential solution to this problem? If so it might be nice to
> explain that; if not, then why and what else would be required?

As you say, it's a requirements document, so it may be a bit harsh to ask the
authors to describe how security should be provided.

We could possibly add a little text to the Security Considerations section to
explain who is supposed to catch the ball when we punt it.

I'll talk to the authors,

Cheers,
Adrian