[nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120

junzhang <junzhang1@huawei.com> Fri, 04 October 2024 08:38 UTC

Return-Path: <junzhang1@huawei.com>
X-Original-To: nasr@ietfa.amsl.com
Delivered-To: nasr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741F8C14F73E for <nasr@ietfa.amsl.com>; Fri, 4 Oct 2024 01:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.095
X-Spam-Level:
X-Spam-Status: No, score=0.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_DOTEDU=1.999] autolearn=no 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 hC9CY-RIOFfu for <nasr@ietfa.amsl.com>; Fri, 4 Oct 2024 01:38:10 -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 7D305C14F609 for <nasr@ietf.org>; Fri, 4 Oct 2024 01:38:10 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XKhjv13PPz6G9cj; Fri, 4 Oct 2024 16:37:07 +0800 (CST)
Received: from lhrpeml100001.china.huawei.com (unknown [7.191.160.183]) by mail.maildlp.com (Postfix) with ESMTPS id C7C6C140B38; Fri, 4 Oct 2024 16:38:07 +0800 (CST)
Received: from dggpeml500020.china.huawei.com (7.185.36.88) by lhrpeml100001.china.huawei.com (7.191.160.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 4 Oct 2024 09:38:06 +0100
Received: from frapeml500008.china.huawei.com (7.182.85.71) by dggpeml500020.china.huawei.com (7.185.36.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Fri, 4 Oct 2024 16:38:04 +0800
Received: from frapeml500008.china.huawei.com ([7.182.85.71]) by frapeml500008.china.huawei.com ([7.182.85.71]) with mapi id 15.01.2507.039; Fri, 4 Oct 2024 10:38:02 +0200
From: junzhang <junzhang1@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Toerless Eckert <tte@cs.fau.de>
Thread-Topic: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120
Thread-Index: AQHa4/TNYpR72WIDqUWtB59ueF54lLITJ/KAgAREJ4CAB1H5lIAFur4AgAAKSwCAACU6AIAAGwCAgE4MwACAArA3gIAAKCuAgAAj4oCAANdBAA==
Date: Fri, 04 Oct 2024 08:38:02 +0000
Message-ID: <bcb2832ba5f24192be84c5c596ae41dd@huawei.com>
References: <fe9299737de2469da894ed6e55a53bf1@huawei.com> <5aaf2f9d.1c92.19110d4dea0.Coremail.liupenghui1982@163.com> <17219.1722798809@obiwan.sandelman.ca> <202408091800065008405@chinamobile.com> <744c46d5.25b2.19149927bcb.Coremail.liupenghui1982@163.com> <ca7257d77709444a914c402f419ad0b0@huawei.com> <630665a9.436d.1914a2e2fc7.Coremail.liupenghui1982@163.com> <c15aa26cea984239baf9d2d96b6ed5a7@huawei.com> <ZvyK4n-BI9S-SF94@faui48e.informatik.uni-erlangen.de> <24175.1727974451@obiwan.sandelman.ca> <Zv7t5QNKYiBXkLYf@faui48e.informatik.uni-erlangen.de> <5925.1727990783@obiwan.sandelman.ca>
In-Reply-To: <5925.1727990783@obiwan.sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.52.119]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: UCW5NDJSE2QNLZOHIUJC7QGFE3OM2ZWD
X-Message-ID-Hash: UCW5NDJSE2QNLZOHIUJC7QGFE3OM2ZWD
X-MailFrom: junzhang1@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Liuchunchi(Peter)" <liuchunchi@huawei.com>, 刘鹏辉 <liupenghui1982@163.com>, Meiling Chen <chenmeiling@chinamobile.com>, "nasr@ietf.org" <nasr@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120
List-Id: Network Attestation for Secure Routing <nasr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nasr/n-M_4lXfKtP20wl550U8GlGXOl0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nasr>
List-Help: <mailto:nasr-request@ietf.org?subject=help>
List-Owner: <mailto:nasr-owner@ietf.org>
List-Post: <mailto:nasr@ietf.org>
List-Subscribe: <mailto:nasr-join@ietf.org>
List-Unsubscribe: <mailto:nasr-leave@ietf.org>

Dear Michael and Toerless,
       
           In the cloud computing area, there is a concept called assured deletion, that is, to give a proof that after the data is removed from the cloud, and no one else can access it again. One typical approach to realize it is 
           (1) encrypt the data such that it is computationally prohibitive to decrypt the data without the decryption key, 
then (2) store the encrypted data in the cloud while keeping the decryption key secure, 
and finally (3) securely delete the encryption key.
          
                   https://cdn.stmarytx.edu/wp-content/uploads/2020/10/Cloud-Storage-Assured-Deletion-Considerations-and-Schemes.pdf

          Is it related to the avoidance of copying traffic that you have discussed?
          Yours,
                 Jun Zhang

-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca> 
Sent: Thursday, October 3, 2024 11:26 PM
To: Toerless Eckert <tte@cs.fau.de>
Cc: Liuchunchi(Peter) <liuchunchi@huawei.com>; =?us-ascii?B?PT91dGYtOD9CPzVZaVk2Ym1QNkw2Sj89?= <liupenghui1982@163.com>; Meiling Chen <chenmeiling@chinamobile.com>; nasr@ietf.org
Subject: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120


Toerless Eckert <tte@cs.fau.de> wrote:
    > But avoidance of copying of traffic by undesired third parties if course a core
    > benefit that NASR can provide. And those prior examples can provide examples of
    > the attack vectors why that is undesirable. Even with todays easily available
    > end-to-end encryption.

NASR can not provide any kind of avoidance of copying!
(To do that you'd need quantum entangled links of the kind the QIRG is contemplating)

What NASR can do is provide assurance that when you have such links, that:
a) there are no stealth routers in the path.
b) that the two sides of each QIRG link are operating nominally.

    > But maybe much simpler: nation state actors have the means to extract and even decrypt
    > end-to-end traffic. But if they can not see the traffic because it does not run across
    > the paths desired by them, because they pass their network taps - then
    > they can't do that.

yes.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide