Re: [OPSAWG] 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

"Panwei (William)" <william.panwei@huawei.com> Sun, 24 January 2021 14:33 UTC

Return-Path: <william.panwei@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7183A0D00 for <opsawg@ietfa.amsl.com>; Sun, 24 Jan 2021 06:33:12 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cSwaUZ4jPdJK for <opsawg@ietfa.amsl.com>; Sun, 24 Jan 2021 06:33:10 -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 802363A0CFF for <opsawg@ietf.org>; Sun, 24 Jan 2021 06:33:10 -0800 (PST)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DNvzc52dBz67fH3; Sun, 24 Jan 2021 22:10:52 +0800 (CST)
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sun, 24 Jan 2021 15:14:07 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Sun, 24 Jan 2021 22:14:05 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.2106.006; Sun, 24 Jan 2021 22:14:05 +0800
From: "Panwei (William)" <william.panwei@huawei.com>
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, opsawg <opsawg@ietf.org>
Thread-Topic: =?utf-8?B?W09QU0FXR10g8J+UlCBXRyBBZG9wdGlvbiBDYWxsIG9uIGRyYWZ0LWxlYXIt?= =?utf-8?Q?opsawg-sbom-access-00?=
Thread-Index: AQHW4rQ/sXnF/p0fh0WTpUiSKojPN6ov7wNg
Date: Sun, 24 Jan 2021 14:14:05 +0000
Message-ID: <f2377d643f834831b0ed94e87c3e832c@huawei.com>
References: <0682b5b8-63a1-6e79-6f70-d255f04d8013@sit.fraunhofer.de>
In-Reply-To: <0682b5b8-63a1-6e79-6f70-d255f04d8013@sit.fraunhofer.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.152.99]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/J3-pFNm7fm17RcjOS21q--ZbNXA>
Subject: Re: [OPSAWG] =?utf-8?q?=F0=9F=94=94_WG_Adoption_Call_on_draft-lear-o?= =?utf-8?q?psawg-sbom-access-00?=
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jan 2021 14:33:13 -0000

I've read the draft and I support the adoption. In addition, I have the following comments:

1) 
1. Introduction
An application-layer management system retrieving an SBOM in order
to evaluate the posture of an application server of some form.
These application servers may themselves be containers or
hypervisors. Discovery of the topology of a server is beyond the
scope of this memo.

Comment> I know there are application-layer firewalls, but I don't think it's also appropriate to use "application-layer" to describe the management system. The management system manages the application server, but should not be specific to "application-layer".

Comment> For an application server which doesn't support MUD before, if it wants to advertise its SBOM info, it needs to send a MUD URL and the related MUD file contains a SBOM URL, why doesn't it just send a SBOM URL?

2)
1. Introduction
A network-layer management system retrieving an SBOM from an IoT
device as part of its ongoing lifecycle. Such devices may or may
not have interfaces available to query SBOM information.

Comment> I also suggest not using "network-layer" to describe the management system, but saying that the management system evaluates the network behavior of the IoT devices.

Comment> For disambiguation, in the last sentence, it's better to say "to be queried for SBOM information".

3)
1.3. Discussion points
Are there other retrieval mechanisms that need to be specified?

Comment> Can the SBOM info be directly stored/written in the MUD file?

4)
3. The mud-sbom augmentation to the MUD YANG model
In the description of "leaf-list sbom-local", it is said:
"The choice of sbom-local means that the SBOM resides at
a location indicated by an indicted scheme for the
device in question, at well known location
’/.well-known/sbom’. For example, if the MUD file
indicates that coaps is to be used and the host is
located at address 10.1.2.3, the SBOM could be retrieved
at ’coaps://10.1.2.3/.well-known/sbom’. N.B., coap and
http schemes are NOT RECOMMENDED.";

Comment> The leaf-list "sbom-local" only indicates the transport Protocol, how can the MUD controller know the host address?

5)
4. Examples
The first MUD file demonstrates how to get the SBOM
without ACLs, and the second has ACLs.

Comment> Here should be "The first three MUD files demonstrate ..., and the forth has ACLs."

6)
5. Security Considerations
Another risk is a skew in the SBOM listing and the actual software
inventory of a device/container. For example, a manufactuer may
update the SBOM on its server, but an individual device has not be
upgraded yet. This may result in an incorrect policy being applied
to a device. A unique mapping of a device’s firmware version and its
SBOM can minimize this risk.

Comment> Can we add the firmware version info in the MUD file? So that there will be the mapping of firmware version and SBOM.

Regards & Thanks!
Wei Pan

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Henk
> Birkholz
> Sent: Tuesday, January 5, 2021 12:10 AM
> To: opsawg <opsawg@ietf.org>
> Subject: [OPSAWG] 🔔 WG Adoption Call on
> draft-lear-opsawg-sbom-access-00
> 
> Dear OPSAWG members,
> 
> this starts a call for Working Group Adoption on
> https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on
> Monday, January 25.
> 
> As a reminder, this I-D describes different ways to acquire Software Bills of
> Material (SBOM) about distinguishable managed entities. The work was
> updated by the authors on October 13th and now elaborates on three ways
> SBOM can be found, including a MUD URI as one of the options.
> 
> Please reply with your support and especially any substantive comments
> you may have.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg