[nasr] Re: [saag] Re: Re: Re: Re: Re: NASR BOF Follow-Up

"Liuchunchi(Peter)" <liuchunchi@huawei.com> Thu, 29 May 2025 02:32 UTC

Return-Path: <liuchunchi@huawei.com>
X-Original-To: nasr@mail2.ietf.org
Delivered-To: nasr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4CCD82E2E716; Wed, 28 May 2025 19:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyDw56hP5ZDC; Wed, 28 May 2025 19:32:41 -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 mail2.ietf.org (Postfix) with ESMTPS id 071BE2E2E70F; Wed, 28 May 2025 19:32:41 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4b79Pt2pcpz6M4bt; Thu, 29 May 2025 10:32:34 +0800 (CST)
Received: from lhrpeml100002.china.huawei.com (unknown [7.191.160.241]) by mail.maildlp.com (Postfix) with ESMTPS id B997D1400E3; Thu, 29 May 2025 10:32:37 +0800 (CST)
Received: from kwepemf500004.china.huawei.com (7.202.181.242) by lhrpeml100002.china.huawei.com (7.191.160.241) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 29 May 2025 03:32:36 +0100
Received: from kwepemo200018.china.huawei.com (7.202.195.205) by kwepemf500004.china.huawei.com (7.202.181.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 29 May 2025 10:32:34 +0800
Received: from kwepemo200018.china.huawei.com ([7.202.195.205]) by kwepemo200018.china.huawei.com ([7.202.195.205]) with mapi id 15.02.1544.011; Thu, 29 May 2025 10:32:34 +0800
From: "Liuchunchi(Peter)" <liuchunchi@huawei.com>
To: Meiling Chen <chenmeiling@chinamobile.com>, Luigi IANNONE <luigi.iannone@huawei.com>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follow-Up
Thread-Index: AQHb0DjclfOzvYqYH0a6esR6LT+PMrPo4UEg
Date: Thu, 29 May 2025 02:32:34 +0000
Message-ID: <eee1fab03ecd4d54a13f69c73b969d86@huawei.com>
References: <202505290926323110183@chinamobile.com>
In-Reply-To: <202505290926323110183@chinamobile.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.114.71]
Content-Type: multipart/alternative; boundary="_000_eee1fab03ecd4d54a13f69c73b969d86huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: M4PT5SSD52W5FPJ5R2TECY3LPDQCYFET
X-Message-ID-Hash: M4PT5SSD52W5FPJ5R2TECY3LPDQCYFET
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
CC: Toerless Eckert <tte@cs.fau.de>, nasr <nasr@ietf.org>, IETF SAAG <saag@ietf.org>, Luigi Iannone <ggx@gigix.net>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [nasr] Re: [saag] Re: Re: Re: Re: Re: NASR BOF Follow-Up
List-Id: Network Attestation for Secure Routing <nasr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nasr/Ic3PNHAr91JpgRGXVEeP2Old-cQ>
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>

Okay I think there is some minor confusion here…

1. The router in question would forward/has forwarded specific
traffic classes on specific links and not others.
[LI] Nope. NASR is not about forwarding on specific links. It is about being able to proof that traffic went through a certain set of devices that fulfil a set of claims (or requirements if you wish…).
2. That specific traffic classes would be/had been encrypted
using MACSEC.
[LI] Nope. (as I state in a previous mail) this is orthogonal to NASR. Whether you want to use it is not part of the NASR problem statement.


“A five tuple flow X use encrypted links“ IS a claim at device level. It is attestable by aggregating the evidences (configurations of all devices on path) and be inspected by the verifier.

Peter

From: Meiling Chen <chenmeiling@chinamobile.com>
Sent: Thursday, May 29, 2025 9:27 AM
To: Luigi IANNONE <luigi.iannone@huawei.com>; Eric Rescorla <ekr@rtfm.com>
Cc: Toerless Eckert <tte@cs.fau.de>; nasr <nasr@ietf.org>; IETF SAAG <saag@ietf.org>; Luigi Iannone <ggx@gigix.net>
Subject: [saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follow-Up

Hi,

I think Luigi's reply is completely in line with the original intention.

Best,
Meiling


发件人: Luigi IANNONE<mailto:luigi.iannone@huawei.com>
时间: 2025/05/27(星期二)15:46
收件人: Eric Rescorla<mailto:ekr@rtfm.com>;Meiling Chen<mailto:chenmeiling@chinamobile.com>;
抄送人: Watson Ladd<mailto:watsonbladd@gmail.com>;Henk Birkholz<mailto:henk.birkholz@ietf.contact>;Liuchunchi<mailto:liuchunchi=40huawei.com@dmarc.ietf.org>;Toerless Eckert<mailto:tte@cs.fau.de>;nasr<mailto:nasr@ietf.org>;IETF SAAG<mailto:saag@ietf.org>;Luigi Iannone<mailto:ggx@gigix.net>;
主题: RE: Re: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up
HI,

I think there is a bit of a  misunderstanding …


The BOF presented a number of problems that allegedly NASR was trying
to solve, including that:

1. The router in question would forward/has forwarded specific
traffic classes on specific links and not others.
[LI] Nope. NASR is not about forwarding on specific links. It is about being able to proof that traffic went through a certain set of devices that fulfil a set of claims (or requirements if you wish…).
Attesting that the set of devices fulfils the requirements is done by extending the RATS technology.
Proving that the traffic did go through those devices is done a proof of transit technology for which there are a couple of early ideas documented.

2. That specific traffic classes would be/had been encrypted
using MACSEC.
[LI] Nope. (as I state in a previous mail) this is orthogonal to NASR. Whether you want to use it is not part of the NASR problem statement.

NASR represents one specific proposal for addressing these problems,
which is to attest to the code and configuration running on specific
network elements. So, yes, a system like NASR needs to establish
that the code and configuration guarantees these properties in
order to address the stated problem.
[LI] You do not need that level of granularity.
It's certainly not sufficient
to demonstrate that the device simply supports MACSEC, because
it might be disabled.

If you think there is some other set of problems that need to be
solved, and that these don't need to be then I think you need to state
that more clearly.
[LI] Agreed. We certainly need to do more work in clarifying the problem and possible solution space.
The ongoing exchange in very helpful in this sense.
Thanks
Ciao
L.



-Ekr