[nasr] Re: Scope: Forwarding AND Routing or JUST Forwarding?

"Liuchunchi(Peter)" <liuchunchi@huawei.com> Wed, 09 October 2024 03:26 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 38BEAC1516E2 for <nasr@ietfa.amsl.com>; Tue, 8 Oct 2024 20:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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] 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 3Y9ZdT4rdNjj for <nasr@ietfa.amsl.com>; Tue, 8 Oct 2024 20:26:12 -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 1E422C14F6E4 for <nasr@ietf.org>; Tue, 8 Oct 2024 20:26:12 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4XNdZT6Yyfz6K9Gb for <nasr@ietf.org>; Wed, 9 Oct 2024 11:25:53 +0800 (CST)
Received: from lhrpeml100004.china.huawei.com (unknown [7.191.162.219]) by mail.maildlp.com (Postfix) with ESMTPS id 8D7B9140114 for <nasr@ietf.org>; Wed, 9 Oct 2024 11:26:10 +0800 (CST)
Received: from kwepemg500005.china.huawei.com (7.202.181.42) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 9 Oct 2024 04:26:09 +0100
Received: from dggpeml100018.china.huawei.com (7.185.36.133) by kwepemg500005.china.huawei.com (7.202.181.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 9 Oct 2024 11:26:07 +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; Wed, 9 Oct 2024 11:26:07 +0800
From: "Liuchunchi(Peter)" <liuchunchi@huawei.com>
To: Luigi Iannone <ggx@gigix.net>, nasr <nasr@ietf.org>
Thread-Topic: [nasr] Scope: Forwarding AND Routing or JUST Forwarding?
Thread-Index: AQHbGXZiWgQnDTugsE24Op7Et9j7B7J9rLvg
Date: Wed, 09 Oct 2024 03:26:07 +0000
Message-ID: <031de228064b4e9fb8c4d3ca353dd241@huawei.com>
References: <3FDB94A5-A84E-44D7-8AEB-28343025169B@gigix.net>
In-Reply-To: <3FDB94A5-A84E-44D7-8AEB-28343025169B@gigix.net>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Message-ID-Hash: VZTLRRBCHG7BG22FMMIP654ARSYIMXLW
X-Message-ID-Hash: VZTLRRBCHG7BG22FMMIP654ARSYIMXLW
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
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [nasr] Re: Scope: Forwarding AND Routing or JUST Forwarding?
List-Id: Network Attestation for Secure Routing <nasr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nasr/G0fD1Yad-1foOSBVJnfMC8yKOqI>
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>

This question also appeared during our discussion with clients outside of IETF-- even if we consider distributing trust-topology information and do routing based on trust-metrics (important, still, let alone the possible wg overlaps), we will still need a means of forwarding verification and auditing to check if it worked or not. Considering increased ietf pace, focusing on forwarding audits and visibility might be a good idea. 

Leakage or deviation might not be 100% avoidable after all.. but when it happens, nasr could help fix it asap. When it does not happen, operators can use nasr as a transparency auditing tool to generate exculpatory evidence that network did its job to meet transmission security requirements.

> -----Original Message-----
> From: Luigi Iannone <ggx@gigix.net>
> Sent: Tuesday, October 8, 2024 7:36 PM
> To: nasr <nasr@ietf.org>
> Subject: [nasr] Scope: Forwarding AND Routing or JUST Forwarding?
> 
> Hello NASRers,
> 
> One of the topic that we can tackle on the mailing list and finalize during the
> interim is about the scope of NASR in particular about “Routing vs
> Forwarding”.
> 
> During the BoF, several persons pointed out that we are not clear on whether
> NASR is about:
> 
> 1) Fowarding: being able to audit a path and obtain a proof of transit. Building
> the path being out of scope.
> 
> 2)  Routing: This is forawarding + Building the path by distributing trust and
> reachability information.
> 
> In my personal opinion I see NASR more on the forwarding side, hence
> focusing on the auditing tools.
> 
> Extending routing solution to distribute relevant information for NASR to
> work can be done in the future and not necessarily in the NASR WG but as an
> extension of other protocols, hence in their respective WGs.
> 
> Anyone to share more thoughts on this point?
> 
> L.
> --
> nasr mailing list -- nasr@ietf.org
> To unsubscribe send an email to nasr-leave@ietf.org