Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07

Adrian Farrel <Adrian.Farrel@huawei.com> Sun, 20 September 2009 09:59 UTC

Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE05B3A682C; Sun, 20 Sep 2009 02:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.855
X-Spam-Level:
X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyztmR3J2sth; Sun, 20 Sep 2009 02:59:45 -0700 (PDT)
Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id F08D53A6939; Sun, 20 Sep 2009 02:59:44 -0700 (PDT)
Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ900L40L4VDJ@lhrga01-in.huawei.com>; Sun, 20 Sep 2009 11:00:32 +0100 (BST)
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ900H10L4MMN@lhrga01-in.huawei.com>; Sun, 20 Sep 2009 11:00:26 +0100 (BST)
Date: Sun, 20 Sep 2009 11:00:08 +0100
From: Adrian Farrel <Adrian.Farrel@huawei.com>
To: Derek Atkins <derek@ihtfp.com>, iesg@ietf.org, secdir@ietf.org
Message-id: <9C47E4DAD6D4409488F2107ADD4C964A@your029b8cecfe>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <sjmtyyyldkj.fsf@pgpdev.ihtfp.org>
Cc: nicolas.riou@fr.schneider-electric.com, jerald.p.martocci@jci.com, pieter.demil@intec.ugent.be, wouter@vooruit.be, roll-chairs@tools.ietf.org
Subject: Re: [secdir] sec-dir review of draft-ietf-roll-building-routing-reqs-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <Adrian.Farrel@huawei.com>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 20 Sep 2009 09:59:46 -0000

Hi Derek,

I very much appreciate your review.

It is important to understand that this document specifies requirements that 
must/should/etc be satisfied by a protocol designed by the working group. 
Thus, there is no question of what should be deployed or what should be 
implemented.

That is, the document specifies what must be in the protocol spec. We can 
expect the protocol spec to discuss what must be implemented. And either the 
protocol spec or an applicability statement would describe what must be 
deployed.

So, the concerns you raise would be very important in the final protocol 
spec (and I hope the chairs and authors are paying attention), but do not 
seem to me to fit in this document.

Thanks,
Adrian

>> The Security Considerations appear to take into account various
>> requirements for different systems.  What seems to be lacking is
>> direction about how or when to apply various requirements and what
>> it means to the deployment.
>>
>> For example, what would it mean to a deployment if it has
>> authentication versus not having authentication?  Also, it's unclear
>> how these requirements would apply to an implementor.
>>
>> Variable security policies is a good idea, but it requires more
>> guidance because the end user will never understand the ramifications
>> of choosing one policy over another.