Re: [netmod] A review of draft-ietf-netmod-node-tags

Qin Wu <bill.wu@huawei.com> Wed, 19 January 2022 03:47 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F223A1BEE; Tue, 18 Jan 2022 19:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 IFk10AScyIC7; Tue, 18 Jan 2022 19:47:35 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E65F3A13E1; Tue, 18 Jan 2022 19:47:35 -0800 (PST)
Received: from fraeml740-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Jds5z6FWyz67mgD; Wed, 19 Jan 2022 11:47:19 +0800 (CST)
Received: from canpemm500007.china.huawei.com (7.192.104.62) by fraeml740-chm.china.huawei.com (10.206.15.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 19 Jan 2022 04:47:32 +0100
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm500007.china.huawei.com (7.192.104.62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 19 Jan 2022 11:47:30 +0800
Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2308.021; Wed, 19 Jan 2022 11:47:30 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "chopps@chopps.org" <chopps@chopps.org>, "netmod@ietf.org" <netmod@ietf.org>
CC: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "draft-ietf-netmod-node-tags@ietf.org" <draft-ietf-netmod-node-tags@ietf.org>
Thread-Topic: A review of draft-ietf-netmod-node-tags
Thread-Index: AdgM5ujKzwj0r7wITwmsigswevEflg==
Date: Wed, 19 Jan 2022 03:47:30 +0000
Message-ID: <34b9e3703dbe401caa783f21ef3c3b06@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NNhGZ6M_qK-sBafVARZbXgYzSEc>
Subject: Re: [netmod] A review of draft-ietf-netmod-node-tags
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jan 2022 03:47:40 -0000

Hi, Chris:
Adrian and I talk about user tag management during his review of draft-ietf-netmod-node-tags. One issue raised by Adrian is about whether we will face a situation where one user want to add a user tag while the other user intends to remove such tag.
So the question related to RFC8819 is:
Has RFC8819 missed to talk about the risks associated with an attacker adding or removing tags so that a requester gets the wrong data?
See more details below.

-Qin
>>Section 5 has
>>   As the main consumer of
>>   data object tags are users, users may also remove any tag from a live
>>   server, no matter how the tag became associated with a data object
>>   within a YANG module.
>>
>>Suppose there are two users accessing the same YANG data objects on a 
>>live
>server. This doesn't seem unreasonable in the case of different users or monitoring tools reading data about the network or devices.
>>
>>Doesn't this text lead to "warring tag removal" where one user adds a 
>>tag,
>and another user removes it?
>>
>>Maybe this is limited to user tags so that each user may have their own
>tags. But, in this case, it needs to be clearer what a user tag contains and how it is used. 
>>
>>It would still be pretty annoying is Benoit added user:benoit to some 
>>data
>objects, and I went and removed them.

> [Qin Wu] Yes, I believe it is limited to user tags, since IETF tags are design time tags, so does implementation tags. It is unlikely to face the situation "warring tag removal".
>But for user tag, your are right, user has its own tags and each user may have different privilege therefore. User with low privilege can not remove the tag owned by high privilege user.
>But I am not sure this is the scope of this document, It seems to me implementation specific and should not in the scope of this document, agree?
> (See also section 5.3)

[AF] Agree about implementation. But maybe, "An implementation MAY include mechanisms to stop users' removing each other's tags or to apply privilege levels to different users."

>>Should section 10 talk about the risks associated with an attacker 
>>adding
>or removing tags so that a requester gets the wrong data?

> [Qin Wu] User tag is not registered, how user tag is defined and removed is not scope of this document, in my opinion. Take a look at RFC8819, RFC8819 also doesn't flag this as a issue, do you think we should do this?

[AF] Hmmm. Maybe 8819 missed this?
I agree this refers to the previous point.
Actually: 
1. Just go back and check that it is clear that only user tags can be added/removed dynamically 2. Add a note to section 10 to say
   "Note that appropriate privilege and security levels need to be applied to the addition and removal of user tags to ensure that a user receives the correct data."