[I2nsf] I2NSF's use of NACM

Jan Lindblad <janl@tail-f.com> Mon, 11 November 2019 16:56 UTC

Return-Path: <janl@tail-f.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA0A120A08; Mon, 11 Nov 2019 08:56:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MRRReON83m69; Mon, 11 Nov 2019 08:56:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9D662120A0E; Mon, 11 Nov 2019 08:56:27 -0800 (PST)
Received: from [10.147.40.185] (unknown [173.38.220.39]) by mail.tail-f.com (Postfix) with ESMTPSA id 03F5F1AE018B; Mon, 11 Nov 2019 17:56:25 +0100 (CET)
From: Jan Lindblad <janl@tail-f.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <E97E9B42-B424-4DEE-8DD1-6080C0CC6DA2@tail-f.com>
Date: Mon, 11 Nov 2019 17:56:24 +0100
Cc: YANG Doctors <yang-doctors@ietf.org>, i2nsf@ietf.org, draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org
To: netmod@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/Exk4nOirdoN_RJvqHN8cw8Q7a_8>
Subject: [I2nsf] I2NSF's use of NACM
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 16:56:32 -0000

Dear NETMOD WG,

I have just completed my YD LC review of draft-ietf-i2nsf-consumer-facing-interface-dm-07. The module authors propose a management access control model that builds on NACM concepts, but adds functionality that may be controversial. I would therefore like to give this heads up to all interested in NACM related topics to participate in the LC discussion for this module.

Very briefly, this is what is proposed:

The module is about managing enterprise security equipment on a service model level, i.e. policies are configured and an orchestrator will have to figure out how to translate this into security device level changes. This service module has a list of policies, each of which contains a list of rules, that would be configured by different roles in the enterprise.

For this purpose, each rule has a leaf-list of owners (leafrefs to the NACM groups). The intent is that the orchestrator should translate any changes of these owner leafs into specific NACM rules, so that only the owners (members of the listed NACM groups) are able to update the rule.

Placing the ownership information inside the tree structure being controlled has certain usability advantages, and the simplicity of this leaf-list owners is stark in contrast with the collection of NACM rules it would correspond to. On the other hand, it may not make much sense for the orchestrator to allow controlling NACM rules over both the i2nsf owner leafs and NACM lists. What gives?

Best Regards,
/jan