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

"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Wed, 07 August 2019 13: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 A101512004C; Wed, 7 Aug 2019 06:15:13 -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 1PTEP7ibV-lq; Wed, 7 Aug 2019 06:15:10 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 1C1AB1200F8; Wed, 7 Aug 2019 06:15:10 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id s3so10980wms.2; Wed, 07 Aug 2019 06:15:09 -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=KverjGxF+4z4eUpWlzasHCCsjFFwQRQTO8l2BgrqbsY=; b=HwfwxcGAxA5AxPVKeMlqkSBuXwT9k8MoI5s+2RddGCAgVchbLgDblP7T/oVwAq70Id TA7yw8J1vpv+jzr2DL6wSi3WrK7USksY+TNSOBd8xdXReyh2B3Qt1E71phCQKeX+oOlo qeyfMbdjGJNgkljLmBw2Y/bVBvwRSgyhHTo6rqJUOGbPCL83LxtAYr9KTVcjIxN8ix7H /X5WJq9blkkIwVKxcZ52qt5qjWYth/ZfrJuCgkw0QCfu1WosYZOAy/hWAK7eawTB93SQ LJoeDu8wwBMUrl6fu38MvjtiB34Mp5dn213oTo0WzRA54AfHAu+WM1W+GzXcBubUrVhz xs/w==
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=KverjGxF+4z4eUpWlzasHCCsjFFwQRQTO8l2BgrqbsY=; b=aoHLYNAyY64gjrj6D8sLdOOEXEKh1EuVv43Xs9iOPHcs+Esv5DTgcz/EFobfXcrxHo E6E5Sgyobv1Si5LmEHthyPkDzKrORvzlwueMoQWepkcTejojuJTy889T7NUXRGz8BvSG qKkwDD86jXknl5Vu+Ys8iPDJD5BQRu0aVDT2Tr1yRvnS7TzrZyyekzGxCidmhKM2z/+6 jjEWUaT5q6hvrMx+n/DPK7i7papKdNiMOZIPH1GJeZvTo0eilJaq7TobFR33vBeWQ/xC ekcYcTAL1Qj/MxPw1cV398r6gr5e+wk9Oh7r5rvdNEwauVnjaOBHl445m09flBKVfFnr haAw==
X-Gm-Message-State: APjAAAUAki7DLSDQRJiSMMBGUbphLbboiIEtxdXIk0KCwUsqsGZuHVtP GyIdjaCm7dcbnfyAsI4UdX1KsBB2+gZ1zlDDoLA=
X-Google-Smtp-Source: APXvYqw4TVmn1+wyP4GkM+MbZ6hZqVwciFJvb/NsOoBUjm2bWx+jq02d4IOPBaDKRiGu/dXI4b6NB4sWjkhZkx5HIQM=
X-Received: by 2002:a7b:c30f:: with SMTP id k15mr5852458wmj.11.1565183708329; Wed, 07 Aug 2019 06:15:08 -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: Wed, 7 Aug 2019 22:14:32 +0900
Message-ID: <CAPK2DezCoW5HfK02NxGFzs5-+wEcEubX6PGsShQTP2=L3p63JA@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, "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f17bed058f86ba98"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/w-DySobqCs4n1A6ew4jS23hohms>
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: Wed, 07 Aug 2019 13:15:14 -0000

Hi Jan,
Your suggestion looks good to my SKKU team and me.
I agree with your suggestion that our Consumer-Facing Interface YANG data
model leverages the existing NACM.

Could you like me to take any further steps with your sketch?

With your work, my team will be able to continue the revision of
Consumer-Facing Interface YANG data model.

Thanks.

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>