IETF Logo Mail Archive

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

Luigi IANNONE <luigi.iannone@huawei.com> Mon, 07 April 2025 07:21 UTC

Return-Path: <luigi.iannone@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 C360B184356C; Mon, 7 Apr 2025 00:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=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 dynt3NHf53HC; Mon, 7 Apr 2025 00:21:15 -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 6E3181843561; Mon, 7 Apr 2025 00:21:15 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4ZWLFt63KDz6L57D; Mon, 7 Apr 2025 15:20:18 +0800 (CST)
Received: from frapeml500002.china.huawei.com (unknown [7.182.85.205]) by mail.maildlp.com (Postfix) with ESMTPS id 8D5C1140277; Mon, 7 Apr 2025 15:21:10 +0800 (CST)
Received: from frapeml500003.china.huawei.com (7.182.85.28) by frapeml500002.china.huawei.com (7.182.85.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 7 Apr 2025 09:21:10 +0200
Received: from frapeml500003.china.huawei.com ([7.182.85.28]) by frapeml500003.china.huawei.com ([7.182.85.28]) with mapi id 15.01.2507.039; Mon, 7 Apr 2025 09:21:10 +0200
From: Luigi IANNONE <luigi.iannone@huawei.com>
To: Eric Rescorla <ekr@rtfm.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up
Thread-Index: AQHbpzYDkpEfovs6Ykql7jieYGH85bOXy11w
Date: Mon, 07 Apr 2025 07:21:10 +0000
Message-ID: <402410dcf55348409d12a2daaedc016a@huawei.com>
References: <ef08bf0afa924713acc629dff8156761@huawei.com> <2025040312042771743841@chinamobile.com> <CAL02cgSg53nOB8BCSNCLGC78r41P_1VzBPoj2yOJP1qbS0jqfA@mail.gmail.com> <CABcZeBPFaJMsWyNozXS+osh251631vCStkrmOk=WQig5c1_0qw@mail.gmail.com> <19058.1743968487@obiwan.sandelman.ca> <CABcZeBPGt-OLy9KGpTM22neE7F9ysD=Wm0zK6yHZoQ3gFHXqGw@mail.gmail.com>
In-Reply-To: <CABcZeBPGt-OLy9KGpTM22neE7F9ysD=Wm0zK6yHZoQ3gFHXqGw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.206.215.61]
Content-Type: multipart/alternative; boundary="_000_402410dcf55348409d12a2daaedc016ahuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: FQQAXGGQJTQQRYXT7YUPMKKRQFBFKQS5
X-Message-ID-Hash: FQQAXGGQJTQQRYXT7YUPMKKRQFBFKQS5
X-MailFrom: luigi.iannone@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: "nasr@ietf.org" <nasr@ietf.org>, IETF SAAG <saag@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [nasr] Re: [saag] 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/8Q-xekynRu9wIVRsCPLe4GXWV-U>
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,

From: Eric Rescorla <ekr@rtfm.com>
Sent: Sunday, April 6, 2025 10:53 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: nasr@ietf.org; IETF SAAG <saag@ietf.org>
Subject: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up



On Sun, Apr 6, 2025 at 12:41 PM Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr%2Bietf@sandelman.ca>> wrote:

Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:
    > However, it's not clear to me that that's true in this case, because
    > unlike media players, network devices are highly configurable and a
    > large number of the configuration directives might impact the relevant
    > security claims. Thus, determining whether an element is policy
    > conformant is a matter of knowing not just what code it is running
    > but the state of every relevant configuration directive. One could
    > imagine this working at least three ways:

I think you are making routers sound way more complicated than they are.

1. 90% of directives have little to no affect.
   (I have one toe in the routing/operations space. I'm ASN26227)

Perhaps, but they still need to be individually examined in order to
to determine that. Has someone done that?

[LI] I do not think that the need is to attest the router as a whole. I is more about what is relevant for the flow that is using NASR service.
[LI] Taking the example of POT in the context of SFC, you may want an attestation that the function is the one you need/want and a proof that the traffic went through the function. In this case you do not need to attest every single knob of the router (which agreed would be a daunting, if not impossible).

L.

v2.46.0 | Report a Bug | By Email | System Status