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

Meiling Chen <chenmeiling@chinamobile.com> Tue, 13 August 2024 08:55 UTC

Return-Path: <chenmeiling@chinamobile.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 E38B0C1516E2 for <nasr@ietfa.amsl.com>; Tue, 13 Aug 2024 01:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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=unavailable 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 kL-UNAwmrkmj for <nasr@ietfa.amsl.com>; Tue, 13 Aug 2024 01:55:51 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta6.chinamobile.com [111.22.67.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0C578C151088 for <nasr@ietf.org>; Tue, 13 Aug 2024 01:55:49 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee166bb1f934be-03db9; Tue, 13 Aug 2024 16:55:48 +0800 (CST)
X-RM-TRANSID: 2ee166bb1f934be-03db9
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[10.2.53.48]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee166bb1f92a28-be204; Tue, 13 Aug 2024 16:55:48 +0800 (CST)
X-RM-TRANSID: 2ee166bb1f92a28-be204
Date: Tue, 13 Aug 2024 16:55:47 +0800
From: Meiling Chen <chenmeiling@chinamobile.com>
To: Liuchunchi <liuchunchi=40huawei.com@dmarc.ietf.org>, 刘鹏辉 <liupenghui1982@163.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>, <ca7257d77709444a914c402f419ad0b0@huawei.com>, <630665a9.436d.1914a2e2fc7.Coremail.liupenghui1982@163.com>, <c15aa26cea984239baf9d2d96b6ed5a7@huawei.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.9.115[cn]
Mime-Version: 1.0
Message-ID: <2024081316554685917119@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart548108262476_=----"
Message-ID-Hash: GJJVAEKARNPM2TLR2TLK5H6X2XJN7RON
X-Message-ID-Hash: GJJVAEKARNPM2TLR2TLK5H6X2XJN7RON
X-MailFrom: chenmeiling@chinamobile.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/VTU5xaZ3CN0Ps9tsSrlj_4AD6BU>
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>

sorry penghui, email blocked again.

To sum up, 
Data needs to circulate, but the law or regulations are beginning to control the data export, is this a consensus?
Data leakage is an important reason for the emergence of such laws and regulations, so the key point is data can be transmitted
securely and reliably.

of course, VPN is currently the solution, the only way, Our goal is to enhance the security of VPN at the IP layer by NASR.

Best,
Meiling
 
·¢¼þÈË£º Liuchunchi\(Peter\)
·¢ËÍʱ¼ä£º 2024-08-13 14:57
ÊÕ¼þÈË£º ÁõÅô»Ô
³­ËÍ£º Meiling Chen; Michael Richardson; nasr@ietf.org
Ö÷Ì⣺ [nasr] Re: »Ø¸´: Re: Secure Routing Path Consideration- China Mobile-ietf120
>> mybe we need some addtional cases for meeting this kind of law, legal compliance?
 
This is not a use case I think, legal compliance is a policy driver. Use cases are business-specific scenarios that specifies clients, topology, needs and offerings. Like remote training transmission connectivity service (that prevents leakage) we discussed at this IETF. 
 
VPN has its vulnerabilities, we discussed at the BOF too ¨C traffic analysis, deprecated crypto, ¡­ 
 
Germany TTDSG states a similar legal requirement of data sovereignty (¡°no go abroad¡±). 
 
 
From: ÁõÅô»Ô <liupenghui1982@163.com> 
Sent: Tuesday, August 13, 2024 1:20 PM
To: Liuchunchi(Peter) <liuchunchi@huawei.com>
Cc: Meiling Chen <chenmeiling@chinamobile.com>; Michael Richardson <mcr@sandelman.ca>; nasr@ietf.org
Subject: Re:RE: [nasr] Re: »Ø¸´: Re: Secure Routing Path Consideration- China Mobile-ietf120
 
I mean beside the usecase for business secret protection, which already can be met by VPN,  mybe we need some addtional cases for meeting this kind of law, legal compliance?
 
Anyway, if there would be sufficient protective measures, GPDR allows for the transmission of data across borders. but we have no positive usecase for the ¡° no go abroad¡±£¬the related technology cannot evolve for long time....
 
At 2024-08-13 11:07:12, "Liuchunchi(Peter)" <liuchunchi@huawei.com> wrote:
> 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> 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
Date: 2024-08-05 03:13
To: =?UTF-8?B?5YiY6bmP6L6J?=; 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  http://www.sandelman.ca/        |   ruby on rails    [