[alto] Comments to Ayoub’s presentation of “Towards a Trust-Enhanced ALTO” at the 5th ALTO Interim

liuchunchi <liuchunchi@huawei.com> Wed, 31 May 2023 10:55 UTC

Return-Path: <liuchunchi@huawei.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED522C151B2C for <alto@ietfa.amsl.com>; Wed, 31 May 2023 03:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYR0OCJoDuiU for <alto@ietfa.amsl.com>; Wed, 31 May 2023 03:55:39 -0700 (PDT)
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 73375C151B20 for <alto@ietf.org>; Wed, 31 May 2023 03:55:39 -0700 (PDT)
Received: from lhrpeml500002.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QWQz41s28z6J7fP for <alto@ietf.org>; Wed, 31 May 2023 18:50:40 +0800 (CST)
Received: from canpemm500005.china.huawei.com (7.192.104.229) by lhrpeml500002.china.huawei.com (7.191.160.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 31 May 2023 11:55:36 +0100
Received: from dggpeml500018.china.huawei.com (7.185.36.186) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Wed, 31 May 2023 18:55:34 +0800
Received: from dggpeml500018.china.huawei.com ([7.185.36.186]) by dggpeml500018.china.huawei.com ([7.185.36.186]) with mapi id 15.01.2507.023; Wed, 31 May 2023 18:55:34 +0800
From: liuchunchi <liuchunchi@huawei.com>
To: "alto@ietf.org" <alto@ietf.org>, "ayoub.messous@fujitsu.com" <ayoub.messous@fujitsu.com>
CC: Qin Wu <bill.wu@huawei.com>
Thread-Topic: Comments to Ayoub’s presentation of “Towards a Trust-Enhanced ALTO” at the 5th ALTO Interim
Thread-Index: AdmTDEbNEm0cdlsCRmC8Hc9RQm4AZAAofqzg
Date: Wed, 31 May 2023 10:55:34 +0000
Message-ID: <63b321d8cf774ff19ed4b97be866d2f8@huawei.com>
References: <ed6227b0d24243fc8a37460b20029d86@huawei.com>
In-Reply-To: <ed6227b0d24243fc8a37460b20029d86@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.39.60]
Content-Type: multipart/alternative; boundary="_000_63b321d8cf774ff19ed4b97be866d2f8huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/mRWmW8jA7_opix1qGm8oH1-o0so>
Subject: [alto] Comments to Ayoub’s presentation of “Towards a Trust-Enhanced ALTO” at the 5th ALTO Interim
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2023 10:55:45 -0000

Hi ALTOers, Hello Ayoub

Just joined the 5th ALTO interim yesterday, regarding Ayoub’s deck about adding trust to ALTO, I may have a few ideas and comments open for discuss.


l  Comments 1: Regarding the Cost Map and trustworthiness metrics, I think it could be a direction where we abstract the security policy into security budget, and abstract device trustworthiness into security cost. A trusted router/path costs near-zero security cost while less trusted routers/paths could use up the security budget, which represent the physical significance of accumulating too much security risk this topology could take.


l  Comments 2: Regarding how to use the trust inputs received from the ALTO server and how to share trusted output with ALTO client, I think it could also be a direction where we have privacy-preserving computation techniques run on edge servers. A cryptographically accelerated edge server could 1. help end user device receive trust information from ALTO server in order to compute and optimize network performance in a cryptographically secure way, 2. help offload heavy cryptographic computation tasks from end devices to edge servers, 3. prevent direct user exposure of plain-text, privacy-sensitive information (basically a powerful proxy). Personally, I believe privacy-preserving cryptographic computing techniques, such as Zero-Knowledge Proof, Fully Homomorphic Encryption and Federated Learning is too powerful to avoid talking about. If anyone is interested I can prepare an insight analysis and/or a new mailing list.


l  Comments 3: Since routing security is important I think we need some mechanisms not only to assess the trustworthiness of the routing path, but also to ensure the actual using of this trusted routing path. For example, how to guarantee or prove a certain data packet has actually traversed a selected trusted path step-by-step. Does this deserve research attention?


Best regards,
Chunchi