[secdir] Secdir review of draft-ietf-netmod-opstate-reqs-04
Tero Kivinen <kivinen@iki.fi> Thu, 11 February 2016 10:18 UTC
Return-Path: <kivinen@iki.fi>
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 CC2EE1ACE7A; Thu, 11 Feb 2016 02:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] 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 SR-Uml58vHO8; Thu, 11 Feb 2016 02:18:00 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880701ACE73; Thu, 11 Feb 2016 02:17:58 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1BAHrvc029693 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Feb 2016 12:17:53 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1BAHqF3020097; Thu, 11 Feb 2016 12:17:52 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22204.24528.791620.642938@fireball.acr.fi>
Date: Thu, 11 Feb 2016 12:17:52 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netmod-opstate-reqs.all@tools.ietf.org
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 14 min
X-Total-Time: 16 min
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/JL4_QwVmxDu7qpa01cC6eEjtnWs>
Subject: [secdir] Secdir review of draft-ietf-netmod-opstate-reqs-04
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: Thu, 11 Feb 2016 10:18:03 -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 is terminology and requirements document for handling operational state. As such the security considerations section cannot have very detailed problems, but it does properly point out that while configuration is being applied the device might be in inconsistent state, and that might cause security issues. It does not say anything about how the configuration requests needs to be secured, but I assume that is more in to the actual protocol RFC issue, than this document. It does not also comment anything about whether the different states (intended configuration, applied configuration and derivative state) should have different security policies to applied to them, i.e. it does say that it should be possible to retrieve only applied configuration or only derived state, but does not mention should there also be different security policies to do those operations. In some cases the derivative state might contain things like traffic keys negotiated during the protocol runs, or traffic information aabout flows passing the devices (privacy issues), so derivative state might be more sensitive than the actual applied configuration. Outside the security considerations section the requirement which says: A. A server MUST support only synchronous configuration operations, or only asynchronous configuration operations, or both synchronous and asynchronous configuration operations on a client-specified per-operation basis. is bit funny, as it effectively says that either syncronous or asyncronous MUST be supported and both may be supported, but I do not understand what the "client-specified per-operation basis" is meaning for the requirement for server. Client cannot really require server to change its IMPLEMENTATION on per-operation basis (i.e., client 1 requesting that server MUST support only asyncronous operations, and client 2 requesting that server MUST support only syncronous operations). Client can use either syncronous or asyncronous if both are supported by the server, and I assume this is trying to say that client can select syncronous/asyncronous operation per-operation basis, but when you are talking about that "A server MUST support ..." I do not think it is ok to requiring that on a client-specified way. I.e. proper way would be to say that if server supports both, it MUST allow client to select which method is used on per-operation basis. -- kivinen@iki.fi
- [secdir] Secdir review of draft-ietf-netmod-opsta… Tero Kivinen
- Re: [secdir] Secdir review of draft-ietf-netmod-o… Benoit Claise