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

["Liuchunchi(Peter)" <[e-mail]>]

It is worth mentioning that I consulted Clarence's team and their response is as follows:
Proof of Transit is one of the use-cases that Path Tracing solves very efficiently.

It records the timestamp and Interface ID and therefore works like a Proof of Transit.

I think it works sufficiently for a basic POT functionality. But the question is whether or not we want to carry more security information (configs, enabled functionalities, runtime logs, original attestation results) and stuff it into a keyed hash, or signature.

Peter

From: Meiling Chen <[e-mail]>
Sent: Wednesday, April 9, 2025 5:32 PM
To: Luigi IANNONE <[e-mail]>; ekr <[e-mail]>; Michael Richardson <[e-mail]>; rlb <[e-mail]>
Cc: [e-mail]; IETF SAAG <[e-mail]>
Subject: [saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follow-Up

Hi all,
Many people on BoF are concerned about how to implement PoT, such as Q16 and Q17 issues, the draft Path Tracing in SRv6 networks(https://datatracker.ietf.org/doc/draft-filsfils-ippm-path-tracing/02/) is helpful for this issue.

This draft was previously in the Spring, now moved to the IPPM WG based on feedback from the IPPM and Spring WG.
https://datatracker.ietf.org/doc/draft-filsfils-ippm-path-tracing/02/

I found that  path tracing has been implemented, path tracing is to record the routing nodes passed through, and the PoT of NASR only need to add an additional value of attestation result, it doesn't seem to add much cost.


It is worth mentioning that I consulted Clarence's team and their response is as follows:
Proof of Transit is one of the use-cases that Path Tracing solves very efficiently.
PT provides efficient, HW friendly solution implemented in the base router forwarding pipeline as highlighted by the several implementations in the draft.

I hope the above information is helpful for everyone to understand the implementation of POT.

Best,
Meiling

From: Luigi IANNONE<mailto:[e-mail]>
Date: 2025-04-07 15:21
To: Eric Rescorla<mailto:[e-mail]>; Michael Richardson<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>; IETF SAAG<mailto:[e-mail]>
Subject: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up
Hi,

From: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, April 6, 2025 10:53 PM
To: Michael Richardson <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; IETF SAAG <[e-mail]<mailto:[e-mail]>>
Subject: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up



On Sun, Apr 6, 2025 at 12:41 PM Michael Richardson <[e-mail]<mailto:[e-mail]>> wrote:

Eric Rescorla <[e-mail]<mailto:[e-mail]>> 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.