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

"Liuchunchi(Peter)" <liuchunchi@huawei.com> Tue, 13 August 2024 03:07 UTC

Return-Path: <liuchunchi@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 35BFAC1D4A97 for <nasr@ietfa.amsl.com>; Mon, 12 Aug 2024 20:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 NG_1CBNh0fFb for <nasr@ietfa.amsl.com>; Mon, 12 Aug 2024 20:07:18 -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 0539EC180B5D for <nasr@ietf.org>; Mon, 12 Aug 2024 20:07:18 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Wjbnb3vHpz6FGjb; Tue, 13 Aug 2024 11:04:03 +0800 (CST)
Received: from lhrpeml100006.china.huawei.com (unknown [7.191.160.224]) by mail.maildlp.com (Postfix) with ESMTPS id 1C92B140B39; Tue, 13 Aug 2024 11:07:15 +0800 (CST)
Received: from dggpeml500018.china.huawei.com (7.185.36.186) by lhrpeml100006.china.huawei.com (7.191.160.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 13 Aug 2024 04:07:14 +0100
Received: from dggpeml100018.china.huawei.com (7.185.36.133) by dggpeml500018.china.huawei.com (7.185.36.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Tue, 13 Aug 2024 11:07:12 +0800
Received: from dggpeml100018.china.huawei.com ([7.185.36.133]) by dggpeml100018.china.huawei.com ([7.185.36.133]) with mapi id 15.01.2507.039; Tue, 13 Aug 2024 11:07:12 +0800
From: "Liuchunchi(Peter)" <liuchunchi@huawei.com>
To: 刘鹏辉 <liupenghui1982@163.com>, Meiling Chen <chenmeiling@chinamobile.com>
Thread-Topic: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120
Thread-Index: AQHa5qJ27uMFWKuQ5k61P7NYnBbHRLIeuLbTgAVFZgCAAI6OIA==
Date: Tue, 13 Aug 2024 03:07:12 +0000
Message-ID: <ca7257d77709444a914c402f419ad0b0@huawei.com>
References: <202407231553159277592@chinamobile.com>, <514b701e.3dbe.190e2e04151.Coremail.liupenghui1982@163.com>, <202408011054476926448@chinamobile.com>, <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>
In-Reply-To: <744c46d5.25b2.19149927bcb.Coremail.liupenghui1982@163.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.114.71]
Content-Type: multipart/alternative; boundary="_000_ca7257d77709444a914c402f419ad0b0huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: FOODO4BEMLUIRO2U3H55E5QVXEZLFPQW
X-Message-ID-Hash: FOODO4BEMLUIRO2U3H55E5QVXEZLFPQW
X-MailFrom: liuchunchi@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: Michael Richardson <mcr@sandelman.ca>, "nasr@ietf.org" <nasr@ietf.org>
X-Mailman-Version: 3.3.9rc4
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/DFquD5bm1pgyaugA8Xgn9ULW1A8>
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>

> What is the exact significance of this demand of NASR, just meet this kind of law?......

It is for leakage prevention purposes, for both business secret protection and legal compliance considerations.


> the law may not be written in such detail, personally I think it should be the Terrestrial boundary...

By the time of lawmaking I think no technology permitting such promise was available.
By terrestrial boundary, I think meiling means it is not the ONLY factor when orchestrating a path―device integrity and free of tampering for example is another key factor should be considered when orchestration.

PCL

From: 刘鹏辉 <liupenghui1982@163.com>
Sent: Tuesday, August 13, 2024 10:30 AM
To: Meiling Chen <chenmeiling@chinamobile.com>
Cc: Michael Richardson <mcr@sandelman.ca>; nasr@ietf.org
Subject: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120


Large cloud vendors have different server regions in different countries and operate across borders, the law may not be written in such detail, personally I think it should be the Terrestrial boundary...



What is the exact significance of this demand of NASR, just meet this kind of law?......



At 2024-08-09 18:00:06, "Meiling Chen" <chenmeiling@chinamobile.com<mailto:chenmeiling@chinamobile.com>> wrote:
Indeed, after considering the example mentioned by Mic,
Terrestrial boundary is not the only determining attribute, need more properties for real no go abroad, right?

Best,
Meiling

From: Michael Richardson<mailto:mcr@sandelman.ca>
Date: 2024-08-05 03:13
To: =?UTF-8?B?5YiY6bmP6L6J?=<mailto:liupenghui1982@163.com>; nasr@ietf.org<mailto:nasr@ietf.org>
Subject: [nasr] Re: 回复: Re: Secure Routing Path Consideration- China Mobile-ietf120

I don't see anything in your summary of GDPR that says that encrypted PII can
not cross another territory.

At each end the GDPR clearly applies, but for example, I see nothing in your
description that prevents data from Geneva to Bern (both in Switzerland) from
travelling on fiber to the south of Lake Geneva/Leman.  That is, through
France. (is that a better route for fiber? Probably not. But a redundant
microwave link from mountain to mountain would make a lot of sense)
(Or: Zagreb to Bucharest, both EU countries, via Belgrade)
Does GDPR really apply here?

I'm sure such edicts exist, but if GDPR mandates this, it would be best to have
a very specific clause referenced.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca<mailto:mcr@sandelman.ca>  http://www.sandelman.ca/        |   ruby on rails    [




[https://count.mail.163.com/beacon/webmail.gif?type=webmail_mailtrace&guid=pre_cac6aa139d88fd4620ae8fc6facaae9b]