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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 03 October 2024 21:26 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 2B2D2C14F60E for <nasr@ietfa.amsl.com>; Thu, 3 Oct 2024 14:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=sandelman.ca
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 VYZlTZFEmych for <nasr@ietfa.amsl.com>; Thu, 3 Oct 2024 14:26:26 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5294C14F5EB for <nasr@ietf.org>; Thu, 3 Oct 2024 14:26:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C8E041800D; Thu, 3 Oct 2024 17:26:24 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavis, port 10024) with LMTP id ZRaNiHX55__a; Thu, 3 Oct 2024 17:26:24 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1727990783; bh=cFb4MbGsoSyiLLBZy5JWzBi48kJTYlxvA0hyzxW+zY8=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=R+Vv1stBhrDknBpcGg2B5oOTEVgLZPLrM3fXW4NMow6+XAEikwVM26edBWx2NXaJ1 PHzDhKcCt8AzEV42y5Ri+sA085CSssGEqCLEdNFuh2SojQlmmDzK92mEPI0PQmiKu4 D1B3SNoh9B383J0hIUjNpe7Q/HbH8hVZxpKLvc3ty1m+YpAKXFP4P1x38b3dzdNYOb u0scKqy8glURHsVQ4+deIcofrF37Sf2OR77dtQAKgV3sX7KK52XftAnRb7862pQD2k f6r60xtaTyCDqKC0W27t+AskJqf3imgAVcqKBd8COtLrLuikz2PPYFAyd+ioSmUtyj we5f2ySTxtSIw==
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id EC52A1800C; Thu, 3 Oct 2024 17:26:23 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E332647B; Thu, 3 Oct 2024 17:26:23 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Toerless Eckert <tte@cs.fau.de>
In-Reply-To: <Zv7t5QNKYiBXkLYf@faui48e.informatik.uni-erlangen.de>
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>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Thu, 03 Oct 2024 17:26:23 -0400
Message-ID: <5925.1727990783@obiwan.sandelman.ca>
Message-ID-Hash: OECCMT435JRA5XSGBPHNBP3TTSAVW2LS
X-Message-ID-Hash: OECCMT435JRA5XSGBPHNBP3TTSAVW2LS
X-MailFrom: mcr+ietf@sandelman.ca
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>, =?us-ascii?B?PT91dGYtOD9CPzVZaVk2Ym1QNkw2Sj89? = <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/BsSZ8bVyDB74NZOda3CQgzMakfM>
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>

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