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

[Toerless Eckert <[e-mail]>]

No strong opinions here, but i have in the past seen "use-case" as a broad term
covering all reasons why customers want something. Especially in the IETF.
Both "local compliance" and "business reasons" would be sub-bullet items IMHO.

Wrt. data leakage prevention: I remember even as much as 20 years ago or longer,
Providers using IP Multicast where requesting that TV traffic that was encrypted
would still not be permitted to go to subscribers who did not pay for it, but
that those customers would be prohibited by IP Multicast routing policies to
request that traffic. Which required us vendors to implement a wide variety
of policy filtering of IP Multicast routing (IGMP/MLD policy filtering for example).

The reason was simply that content providers had woken up to the attack vector
of encryption keys to not be very good long-term, or that in multicast, the
encrpyption key had to be shared to multiple subscribers, so some subscribers that
where permitted to receive the content could extract and share the encryption key
with subscribers that had not paid for the content. And network filtering to
prohibit such network dissemination would circumvent that attack vector. Of course,
legitimate receivers could can still can today decrypt their content with
appropriate software, but re-sending the whole decrypted content to more
receivers requires a lot more network resources than sharing decryption keys.

Not sure if any of this multicast example is of interested to be written down
in any part of NASR docs, let me know if it is. Else this was just meant as
an example of history in network based leakage prevention to prohibit
encryption key sharing or long-term key cracking as an attack vector.

The unicast equivalent of course is not to upload to-be-protected content to
publically accessible web-caches because that too would make dissemination of
that content plus key cracking easier.


Cheers
    Toerless

On Tue, Aug 13, 2024 at 06:57:05AM +0000, Liuchunchi(Peter) wrote:
> >> 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 – traffic analysis, deprecated crypto, …
> 
> Germany TTDSG states a similar legal requirement of data sovereignty (“no go abroad”).
> 
> 
> From: 刘鹏辉 <[e-mail]>
> Sent: Tuesday, August 13, 2024 1:20 PM
> To: Liuchunchi(Peter) <[e-mail]>
> Cc: Meiling Chen <[e-mail]>; Michael Richardson <[e-mail]>; [e-mail]
> 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)" <[e-mail]<mailto:[e-mail]>> 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: 刘鹏辉 <[e-mail]<mailto:[e-mail]>>
> Sent: Tuesday, August 13, 2024 10:30 AM
> To: Meiling Chen <[e-mail]<mailto:[e-mail]>>
> Cc: Michael Richardson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> 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" <[e-mail]<mailto:[e-mail]>> 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:[e-mail]>
> Date: 2024-08-05 03:13
> To: =?UTF-8?B?5YiY6bmP6L6J?=<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> 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   [
> ]     [e-mail]<mailto:[e-mail]>  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> 
> [https://count.mail.163.com/beacon/webmail.gif?type=webmail_mailtrace&guid=pre_cac6aa139d88fd4620ae8fc6facaae9b]
> [https://count.mail.163.com/beacon/webmail.gif?type=webmail_mailtrace&guid=pre_adbf418b320540ab18e030851aba19bf]

-- 
---
[e-mail]