MIME-Version: 1.0
References: <87c61c52-839f-f66e-a66a-b737f01ca93f@ietf.contact>
 <CABcZeBMOvFXkQ2OFBpz2Ri5_Oz-pHGs=2fHvBNptOdjQy9F7ww@mail.gmail.com>
 <11730e71-f409-bbaf-9bc1-4f88d207bcab@ietf.contact>
 <CABcZeBMDg9cFGtf6AMwSiq3ZnZnrvwoAc7TjD0Ftq-JC8jWusQ@mail.gmail.com>
 <d3de69d6-f46b-fe0c-b6dc-8180864bd9b0@ietf.contact>
 <CABcZeBO15H=+ds0deqvtOzKvX+JvFzCn2pht3fcKYcp7df=UFw@mail.gmail.com>
 <52b08a1b-45e2-b03b-a0a8-12e55b56bfa8@ietf.contact>
 <CABcZeBOwZ3=pz=Xz1D3YwJ6_svTidt5azWDFnTwexsE508rmkA@mail.gmail.com>
 <ee313d5a-967b-c434-804c-097e4777ca20@ietf.contact>
 <CABcZeBP7-A52XPghkCWa7f15Xa1UvoHKujhNPzvoH+cP+McSWQ@mail.gmail.com>
 <Z_mZqmJs8Su1Tt2Y@faui48e.informatik.uni-erlangen.de>
 <CABcZeBMK5kBN2YG4Xev5CTVyk00BXAUWa4P_Ov9Q7K+-b1B5Pw@mail.gmail.com>
 <52075b58d6f64ef98871f1296a6e347f@huawei.com>
 <CACsn0c=sfhN+zJ7r7vpCe4gOXbLU8HAA0hwvgxoB3cGmMTH4WQ@mail.gmail.com>
 <c73fe830-413e-04b8-92f7-28c994034c81@ietf.contact>
 <CACsn0c=+2b5-x9FnjZHDFWxs31HUyPyd42==DeyKqXuP2SVssg@mail.gmail.com>
 <59336c94-08ea-2961-6390-50bf70f7befd@ietf.contact>
 <CACsn0cmGaWNRP6Nrj1F1O8vYeuM2EB9d9Ah6N_Lz-m6cp0y7HQ@mail.gmail.com>
 <2025052016324389942321@chinamobile.com>
 <CACsn0cm7r77B-fOwhP4sfOMsvxBhy_75wAYERzG6Fp6co7ZeYA@mail.gmail.com>
 <4cfab84c8bc74efdbb642650638931d7@huawei.com>
In-Reply-To: <4cfab84c8bc74efdbb642650638931d7@huawei.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 23 May 2025 09:32:00 -0700
Message-ID: 
 <CABcZeBNGt_9iG10enECOT0JgA1EwN1MsR-RDNDCC+a4TiG8WxQ@mail.gmail.com>
To: Luigi IANNONE <luigi.iannone@huawei.com>
Content-Type: multipart/alternative; boundary="00000000000068518b0635d0251c"
Message-ID-Hash: 5XKLFHCMBWTWREZBYH4QW36623TBFLOW
CC: Watson Ladd <watsonbladd@gmail.com>,
 Meiling Chen <chenmeiling@chinamobile.com>,
 Henk Birkholz <henk.birkholz@ietf.contact>,
 Liuchunchi <liuchunchi=40huawei.com@dmarc.ietf.org>,
 Toerless Eckert <tte@cs.fau.de>, "nasr@ietf.org" <nasr@ietf.org>,
 IETF SAAG <saag@ietf.org>, Luigi Iannone <ggx@gigix.net>
Precedence: list
Subject: =?utf-8?q?=5Bnasr=5D_Re=3A_=5Bsaag=5D_Re=3A_Re=3A_Re=3A_NASR_BOF_Follow-Up?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/nasr/2Zf34mAsnljjbRBo7Ccp8O2gda0>

--00000000000068518b0635d0251c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 22, 2025 at 12:52=E2=80=AFAM Luigi IANNONE <luigi.iannone@huawe=
i.com>
wrote:

> Hi Watson,
>
> >
> > Correct. Some claims are easy to verify. Most aren't. Statements that
> "the
> > router supports X" aren't really interesting. Statements that "this
> > configuration will never pass your traffic over a bad link" are, but ar=
e
> a lot
> > harder to show.
> >
> > >
>
> [LI] Agreed. This is a very claim hard show/attest.
> Note however that this is not what NASR is trying to do.
> NASR is more about router has feature X, Y, and Z which is what I want,
> and that traffic goes through the selected routers that support X, Y and =
Z.
> NASR is not about proving that traffic does not go somewhere else (proof
> of non-transit is out of scope).
>

As I understood the presentations, you wanted to make claims like:

* This traffic was sent over an encrypted link
* All traffic to address X will be sent over an encrypted link
* This traffic is not being sent to a spanning port or otherwise available
for monitoring

Correct?

-Ekr



-Ekr


> Ciao
>
> L.
>

--00000000000068518b0635d0251c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 22,=
 2025 at 12:52=E2=80=AFAM Luigi IANNONE &lt;<a href=3D"mailto:luigi.iannone=
@huawei.com">luigi.iannone@huawei.com</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">Hi Watson,<br>
<br>
&gt; <br>
&gt; Correct. Some claims are easy to verify. Most aren&#39;t. Statements t=
hat &quot;the<br>
&gt; router supports X&quot; aren&#39;t really interesting. Statements that=
 &quot;this<br>
&gt; configuration will never pass your traffic over a bad link&quot; are, =
but are a lot<br>
&gt; harder to show.<br>
&gt; <br>
&gt; &gt;<br>
<br>
[LI] Agreed. This is a very claim hard show/attest. <br>
Note however that this is not what NASR is trying to do. <br>
NASR is more about router has feature X, Y, and Z which is what I want, and=
 that traffic goes through the selected routers that support X, Y and Z.<br=
>
NASR is not about proving that traffic does not go somewhere else (proof of=
 non-transit is out of scope). <br></blockquote><div><br></div><div>As I un=
derstood the presentations, you wanted to make claims like:</div><div><br><=
/div><div>* This traffic was sent over an encrypted link</div><div>* All tr=
affic to address X will be sent over an encrypted link</div><div>* This tra=
ffic is not being sent to a spanning port or otherwise available for monito=
ring</div><div><br></div><div>Correct?</div><div><br></div><div>-Ekr</div><=
div><br></div><div><br></div><div><br></div><div>-Ekr</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Ciao<br>
<br>
L.<br>
</blockquote></div></div>

--00000000000068518b0635d0251c--