Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Thu, 01 August 2019 08:15 UTC

Return-Path: <jaehoon.paul@gmail.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 CE16F12007C; Thu, 1 Aug 2019 01:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_MR_MRS=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 MAWLF9vsMKyI; Thu, 1 Aug 2019 01:15:17 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B6A12001B; Thu, 1 Aug 2019 01:15:16 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id y4so72553643wrm.2; Thu, 01 Aug 2019 01:15:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PXiN25QppzyjPh2mgBpX6eNUKSUCis/pzRiJyBG58uw=; b=Es+H3C0Q1DcwXnEVfXJuMKYjErsHiJ0q2WVd4LkRpp4Ujh0ATS5TgnJatditgDIKzo ZpVET5EOL32bhaJ72NpgwYCvlwhuryZicIxqo+QB549fkbvxLy7ssUjwjeKCSzmPMdxH Wy+3Wnv+u+w1RGNo2cfgjyY4RyM+4tG5LqRCDsn+xJSD5nECuRAs26eUfB0CIe4bxYci mtIW94117riNXlscXdh9/8GLhKBO4gcOuNxTuS/eqSolUhM45CZb1vGED2wPInLFekRi dyumTy0jTlclhHit+hfMXYctN2qh89bW4RAc1ftcysBW46khfKVJL7i2QthS1JA5OXgw E9Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PXiN25QppzyjPh2mgBpX6eNUKSUCis/pzRiJyBG58uw=; b=NDG35fVFzoAHO+u8L2ovmHQb19ObdoW5DfSZzz8gXO5KXYP0vjJNwVc6353CiIZtqL pxnCQgi7861z5Sc/+EG6nWAMaezKRKWEFcIMYANt6ggilwkaiFFNjCJ3ZXql8wMSakTL JByTveCFjDVyo2K4hNVW9SRF0v7OfjGlwFGeDzYlZE0JqZ3FbMqO4+SrdEi9lXNa59Qh +E6o1HVZte9hp+eyp1CI3BfvPXTMqzlPz5i2pwNtK4IOsP/hwxP5ZV94oBrIxvlnDhDi XT5Xzi5QxJjGrpSrmKl/nW1PB5j9+TpdrNz06FDEvG0RUkG7943gPLPymtQDMhzxUiQK KRBg==
X-Gm-Message-State: APjAAAVRAanbsCXm3ekwMwWN2co3McaZ6bXBs8M8EvSEMJyDwSuB6LMG QoLc8hWSimyHvZKqvq8/3p1JRWNA1s071Q7MGL0=
X-Google-Smtp-Source: APXvYqzp+xxs1Nq0kg6/2Hm9+VCfupGNqGCi6V9N50gzQ12EHmoswIQqwjCE0QMZ15A20y6xryebDHPQrXIX/jt5h5k=
X-Received: by 2002:a5d:4a46:: with SMTP id v6mr29673575wrs.105.1564647314356; Thu, 01 Aug 2019 01:15:14 -0700 (PDT)
MIME-Version: 1.0
References: <156156480691.19914.1926691912558233407@ietfa.amsl.com> <CAPK2DexupkRCkxETaqJOECL6wrtW19s239qQFo4fzkbJFWWT-Q@mail.gmail.com> <EEBF46C1-D425-4ABA-A0DB-7392799D0A05@tail-f.com> <CAPK2DexOx=s2HL3EAYsLvzw2ak0Rg1cW0WkUZNi3GWA1sont=g@mail.gmail.com> <D367CE60-3106-427F-92F0-5CE605D0F323@tail-f.com>
In-Reply-To: <D367CE60-3106-427F-92F0-5CE605D0F323@tail-f.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Date: Thu, 1 Aug 2019 17:14:38 +0900
Message-ID: <CAPK2Dewi54bqqx9C1SP80Kfih2a=b3dgpDs5yJ_pJm0r2JgxZA@mail.gmail.com>
To: Jan Lindblad <janl@tail-f.com>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, YANG Doctors <yang-doctors@ietf.org>, draft-ietf-i2nsf-consumer-facing-interface-dm.all@ietf.org, IETF Discussion <ietf@ietf.org>, skku_secu-brain_all@googlegroups.com, Brian Kim <kimshallom12@gmail.com>, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005efd8e058f09d786"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/eoPL9Gt0polKlT9oH3fdrLDinqQ>
Subject: Re: [I2nsf] Yangdoctors last call review of draft-ietf-i2nsf-consumer-facing-interface-dm-05
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: Thu, 01 Aug 2019 08:15:21 -0000

Hi Jan,
I will review your suggestion below and tell you our opinion later.

Thanks a lot.

Best Regards,
Paul

On Wed, Jul 31, 2019 at 5:21 PM Jan Lindblad <janl@tail-f.com>; wrote:

> Paul, I2NSF team,
>
> Thanks for your volunteering to improve our Consumer-Facing Interface YANG
> Module.
> Could you propose a way to redesign ietf-i2nsf-cfi-policy.yang to befit
> NACM?
>
>
> Certainly. Find my proposed sketch for the module structure attached.
>
> I think it is important for the adoption of this module that it is
> reasonably easy to implement it on top of existing NETCONF/RESTCONF/YANG
> servers. They all implement the NACM management access control mechanism
> today, so the ietf-i2nsf-cfi-policy module should build on that. It's
> therefore important to leverage the existing NACM mechanisms and concepts
> for groups, users, permissions.
>
> It would be technically possible to set up all the management access
> control rules needed to implement the I2NSF ideas by only creating rules in
> NACM. The NACM rules are massively more complex than the simple owner leaf
> proposed in your YANG module, however. From a usability perspective I think
> it makes good sense to keep the abstraction in ietf-i2nsf-cfi-policy and
> let the module implementor make sure this high level authorization view is
> translated into NACM specifics.
>
> In order to make this feasible, I changed the owner string leaf into a
> leafref pointer to NACM groups, and removed the module's separate
> identities for permissions. Let's adopt the NACM counterparts instead. The
> structure of the rules was very flat, i.e. the domains, tenants, policies
> and rules were mostly side by side, not reflecting their logical hierarchy
> in the YANG. This would make the number of NACM rules to control access to
> each individual item very high. By arranging them in a tree structure, I
> believe the number of NACM rules can be kept to a minimum. NACM rules may
> have a high impact on server performance, so it's important to not have
> excessive amounts of them.
>
> I created a hierarchy with domains on top, each domain containing zero or
> more tenants, each with zero or more policies that in turn consist of zero
> or more rules. At each level it is possible to list owners in the form of
> NACM groups. The module implementor would then have to translate these
> owner references to actual NACM rules.
>
> Here is an example sketch configuration and the resulting NACM rules (in
> CLI style syntax for readability):
>
> i2nsf-cfi domains domain example.com
>  owners [ example.com--eng-it ]
>  tenants tenant dev
>   policies policy team-black
>    owners [ example.com--dev ]
>    rules rule 2
>    !
>    rules rule allow-malware-sites
>     owners [ example.com--dev ]
>
> This is supposed to mean that members of the example.com--eng-it group
> have full ownership of everything in the example.com domain. Within this
> domain, there is a tenant called dev, with a policy called team-black. That
> policy is owned by example.com--dev. This means this policy may be
> updated by members in example.com--dev and example.com--eng-it. Within
> the policy there are two rules ("2" and "allow-malware-sites"). The
> "allow-malware-sites" rule has the example.com--dev group listed as
> owner; this is superfluous. In this example, the rules are otherwise empty.
>
> In order for existing NC/RC/YANG servers to enforce the above, the
> ietf-i2nsf-cfi-policy module implementation would need to translate the
> intent above to NACM rules like the ones below. In this example, the
> implementation created a rule to allow members of the dev and eng-it groups
> within the example.com org to see the example.com domain and everything
> within it. Next there is a rule to allow members of the example.com dev
> group to update the policy named team-black within the dev tenant. Finally,
> there is a rule to allow the eng-it group members to update anything within
> the example.com domain. The default nacm policy per statement in the YANG
> is to deny anyone else to see anything within the i2nsf domain.
>
> nacm rule-list example.com
>  group [ example.com--dev example.com--eng-it ]
>  rule read-all
>   path              /i2nsf-cfi/domains/domain[name='example.com']
>   access-operations read
>   action            permit
>  !
> !
> nacm rule-list example.com--dev
>  group [ example.com--dev ]
>  rule 1
>   path   /i2nsf-cfi/domains/domain[name='example.com
> ']/tenants/tenant[name='dev']/policies/policy[name='team-black']
>   action permit
>  !
> !
> nacm rule-list example.com--eng-it
>  group [ example.com--eng-it ]
>  rule 1
>   path   /i2nsf-cfi/domains/domain[name='example.com']
>   action permit
>  !
> !
>
> NACM also contains a mapping from user names to groups. Is this in line
> with your expectations? Do we need additional infrastructure to control
> this mapping?
>
> nacm groups group example.com--dev
>  user-name [ jan vasilij ]
> !
> nacm groups group example.com--eng-it
>  user-name [ chris victor ]
> !
> nacm groups group example.com--finance
>  user-name [ clara sakura ]
> !
>
> What do you think about this approach to the management access control?
> I'm not sure I got the relations between domains, tenants, policies and
> rules as you want them. Are all these levels needed? Do you believe this is
> this is a workable approach to your vision?
>
> Please let me know if you would like me to take any further steps with
> this sketch. I should mention that I also have plenty of other comments on
> your updated module, but I want to get the access control approach resolved
> before looking at anything else.
>
> I am not aware of any particular party interested to implement our data
> model.
>
>
> Then it is all the more important that the solution can be implemented on
> top of the existing servers out there without modifying them.
>
> Best Regards,
> /jan
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>