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

Luigi Iannone <ggx@gigix.net> Fri, 04 October 2024 13:24 UTC

Return-Path: <ggx@gigix.net>
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 DEAB1C14CF0C for <nasr@ietfa.amsl.com>; Fri, 4 Oct 2024 06:24:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20230601.gappssmtp.com
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 eDVxxNZUjS78 for <nasr@ietfa.amsl.com>; Fri, 4 Oct 2024 06:24:32 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A82C14F6B7 for <nasr@ietf.org>; Fri, 4 Oct 2024 06:24:31 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-37cfff59d04so1902286f8f.1 for <nasr@ietf.org>; Fri, 04 Oct 2024 06:24:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20230601.gappssmtp.com; s=20230601; t=1728048270; x=1728653070; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Qk+EfMChcqhVwuDTHPSGeQkv9EIwvB423f+VWZRLmT8=; b=RMmtgCyOpzwLFwADZGnt06GGyEY4xz/03D5Sbe7qQidx1wmQ9RU5xKQvksuCq6K1uk i0N0ln0LbJ8opoJ8L9peHfhyU8HIHFTqBLYLPvBGpwm/840kUTDA/ZMLqCwD0l/d8dbe CjYqcS1BBkZHms+IsatOtqbxRcvvr/QsEqfZ4xorojnK9GpFjRAtwYvt6BaZPW5Ww3qh gIWz3HJiwVJiuXrn9Bu6VReOMIGXxevGTPJNdAgutIJ+a37MIPb+UrCrHPK3pjRTOE/1 rQxQ0YJ09n9xSX+TP66SdRKgFy5pGUrxpO/h8eO4p01mCT5edOSXkVWVpfsIidTYLsGV IW4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728048270; x=1728653070; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Qk+EfMChcqhVwuDTHPSGeQkv9EIwvB423f+VWZRLmT8=; b=jMY7lXujtqEDDMzUKxaSyfFvr5pLJiTm4QS2zsrfft0ROxw0+YOvTcbWWkdcG9Wlrz bxmlCeaKPbO3UlhgwaFbb6VDG6htOzpKydkchDZuhnWFIs8cgsVWwEE02olkWJACZ/NV 6tPkn7YOYus6TBZ5FUKh3yWNcSHB3HGWM78lgmI1i7B6YWJuff4GvGmSrkaOBOsP5SvD hdP0rvf0K9lpoCda/xtdBVNPOK+r6qP6+/B0aBdQMXIejXlgs+YZSI7lQHqy9YHK7+cO 33HrD37FT2ylWpbij5XibCCZqzxur9DGpEHB6IkITwdkXVquoTwKXptG4m0ZP7dL46WC s2lA==
X-Forwarded-Encrypted: i=1; AJvYcCWr60COirLeux3oLfR+LRYHvVPLSoDGciZp12yFDScOobTOosubseHu+0vC/7KoGXlX6GSW@ietf.org
X-Gm-Message-State: AOJu0YxIXdakf4/4RU9bKsoGM7SaQrrHlpolMUQSVkybVwX8mBLifFfQ z3T7IdCszUKMqXpj/oX25YasOTzFr8z7yeECZOboyglf0ESzmuBV/P+yy+K5/Hg=
X-Google-Smtp-Source: AGHT+IH0iQZ9327IWP0YlmQ6uAapSNe4feSzmKDm590DrMBlrUVAMWty+lC9MLyXeIbkj5uAY5iEpg==
X-Received: by 2002:a5d:500e:0:b0:374:c2bb:8387 with SMTP id ffacd0b85a97d-37d0f720844mr1409427f8f.30.1728048270137; Fri, 04 Oct 2024 06:24:30 -0700 (PDT)
Received: from smtpclient.apple (91-167-176-17.subs.proxad.net. [91.167.176.17]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-37d081f710esm3283528f8f.2.2024.10.04.06.24.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Oct 2024 06:24:29 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <bcb2832ba5f24192be84c5c596ae41dd@huawei.com>
Date: Fri, 04 Oct 2024 15:23:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <214266DA-D2DE-4E7B-BB0F-C76D6A0C5B5D@gigix.net>
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> <bcb2832ba5f24192be84c5c596ae41dd@huawei.com>
To: junzhang <junzhang1=40huawei.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3818.100.11.1.3)
Message-ID-Hash: KZE5X5N5QRRCST34WFTWWJAVD7WU3ZQX
X-Message-ID-Hash: KZE5X5N5QRRCST34WFTWWJAVD7WU3ZQX
X-MailFrom: ggx@gigix.net
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+ietf@sandelman.ca>, Toerless Eckert <tte@cs.fau.de>, "Liuchunchi (Peter)" <liuchunchi@huawei.com>, 刘鹏辉 <liupenghui1982@163.com>, Meiling Chen <chenmeiling@chinamobile.com>, nasr <nasr@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [nasr] 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/N7XvDLoA9ndoX9FJbC0sMSwaMfk>
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>

Hi,

isn’t this falling close to the concept of “proof of non transit”, i.e. being sure the traffic does _not_ go through a specific path?

I think this point was raised in the past but (while interesting) deemed to be too hard to solve (at least now).

I think that is a nice question to be asked in a couple of years, when we have implemented whatever solution NASR will design and see if “can we use it to prove (even partially) that traffic did not go here or there?"

Ciao

L.

> On 4 Oct 2024, at 10:38, junzhang <junzhang1=40huawei.com@dmarc.ietf.org> wrote:
> 
> 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
> 
> 
> 
> 
> -- 
> nasr mailing list -- nasr@ietf.org
> To unsubscribe send an email to nasr-leave@ietf.org