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

Hi Richard,

TL;DR
Why is there a need for an Attester to expose deep network details 
(processed by an Attester) as part of remote attestation procedures?


In order to demonstrate its trustworthiness, an Attester (in this 
instance I am assuming a router in a trusted routing path, for example) 
does not have to expose any Claims that it conveys as Evidence as raw 
values (e.g., the deep network details you were mentioning). The option 
to expose such raw values as Claims exists, but that certainly is not a 
necessity.

Yes, the shape of Evidence conveyed has a direct impact on the appraisal 
procedure for that type of Evidence (Verifier behavior). If a 
specification defines the exposure of raw values as Claims in Evidence, 
that's what a Verifier will require reference values for. But in which 
scenario is it necessary to do that (especially when crossing the system 
boundaries of a trust domain)?

I assumed the point in this context was to establish the trustworthiness 
of network devices (e.g. router). Trustworthy routers then could become 
trustworthy hops on a path (e.g., via 
draft-voit-rats-trustworthy-path-routing). I think the intend in this 
context is for all hops on a routing path to demonstrate trustworthiness 
(via attestation results that again can take on many forms ranging from 
a boolean to trust vectors as proposed in draft-ietf-rats-ar4si - or 
something custom). If the Attestation Results of all hops on a path can 
demonstrate a trustworthiness that is feasible for Relying Parties (for 
example, some trusted path orchestrator), a corresponding "proof of 
transit" computed for that path becomes more believable.

Which type of Claims are exposed to the trusted third parties that are 
Verifiers depends on the setup/distribution of RATS roles in a system. 
If the Verifier Owner is the same authority as the all the hops 
conducting the remote attestation procedure, it might even be okay to 
expose device details (such as deep network details). More common though 
is the exposure of hash digests as Claims in Evidence. If the Verifier 
Owner is a different authority than the hop owner, it seems needlessly 
reckless to expose such information without any other layer of protection.

There are, for example, other mechanisms that could be added here to 
protect sensitive/confidential Claims in Evidence, if you really must 
convey those as raw values, such as selective disclosure (e.g., 
draft-ietf-spice-sd-cwt, maybe augmented with an additional encryption 
of disclosed claims).

I think, my main question here is the TL;DR: Why would there be a 
general need to expose deep network details processed by an Attester to 
conduct remote attestation?


Viele Grüße,

Henk

On 10.04.25 16:18, Richard Barnes wrote:
> Q18 - To be blunt, I feel like folks are using RATS and all its 
> complexity as a smokescreen.  At the end of the day, the RATS Verifier 
> has to see the deep network details, and they have to be someone who is 
> not the network operator.  The fundamental problem is still there.
> 
> --Richard
> 
> On Thu, Apr 10, 2025 at 7:10 AM Meiling Chen 
> <[email protected] <mailto:[email protected]>> wrote:
> 
>     Hi Richard,
>     Q6, the motivation does not to prove that a packet didn't go
>     someplace, but rather follows the pre-designed path consistently.
>     I completely agree that we cannot prove that a data packet did not
>     go somewhere, I need to be more clear, what we need to do is to
>     prove that the forwarding process did indeed pass through the
>     planned nodes. This is the same principle as the presumption of
>     innocence.
> 
>     Q18, this issue is highly related to RATS,
>       "the Network  attest to a Relying Party some properties about the
>     overall state of the network"--> this is the content that has
>     already been completed by RATS, which we call attestation result,
>     what  NASR do new? the answer is to make a choice based on these
>     attestation results.
>     You can review *RFC9334/ RFC9683/ RFC9684* for more detailed
>     informations about how to evaluate and verify.
> 
>     Best,
>     Meiling
> 
>         *From:* Richard Barnes <mailto:[email protected]>
>         *Date:* 2025-04-03 21:08
>         *To:* Meiling Chen <mailto:[email protected]>
>         *CC:* Liuchunchi
>         <mailto:[email protected]>; [email protected]
>         <mailto:[email protected]>; IETF SAAG <mailto:[email protected]>; Luigi
>         Iannone <mailto:[email protected]>
>         *Subject:* [nasr] Re: [saag] Re: NASR BOF Follow-Up
>         Thanks for the summary, Meiling.  That covers most of the issues
>         that I remember being raised.  I would just like to touch on a
>         few of these points:
> 
>         Q6 is a big one.  The motivating examples in the BoF were all
>         about proving that a packet didn't go someplace, which as
>         multiple people pointed out, cannot be done.  If this work is to
>         go anywhere, it needs to solve a problem that is actually solvable.
> 
>         On Q18, I think Meiling's summary accurately captures what was
>         said at the microphone, but I think that response is deeply
>         misleading.  This solution will result in detailed network state
>         information going outside of operator networks, or it cannot
>         work.  Let me try to state it clearly:
> 
>         - The basic premise here is that the Network wants to attest to
>         a Relying Party some properties about the overall state of the
>         network
>         - In order to evaluate whether the properties are true, a
>         Verifier has to to actually look at the detailed network state
>         - The Verifier has to be either the Relying Party or someone the
>         Relying Party trusts
>         - The Verifier **cannot** be the Network, because then the
>         Network is just self-asserting and you don't need any technology
>         at all
> 
>         Yes, the technical implementation might involve hashes.  But
>         fundamentally, the information has to leave the Network.  So
>         another thing the proponents need to demonstrate is that there's
>         any plausible scenario where a network operator is going to be
>         willing to expose this information.
> 
>         It was not raised in the BoF, but I would like to point out a
>         logical inconsistency at the core of the proposition here: On
>         the one hand, the proponents assert that end-to-end
>         cryptographic protections are not sufficient to keep endpoints
>         safe.  On the other hand, the premise of the proposed solution
>         is ... more cryptography.  Attestations, MACSEC, etc.  So the
>         argument here cannot rest on a hand-wavy "cryptography isn't
>         enough"; you need to articulate what specific risks you're
>         addressing.
> 
>         Honestly, when I read the charter for this work, I did not
>         initially have as negative a reaction.  I initially presumed it
>         was like verified SFC, and that you would do things like making
>         a firewall rule a little more permissive if the flow had been
>         verified upstream.  It's not implausible that there are some use
>         cases of that shape.  But instead, the presentations in the BoF
>         framed an impossible problem and an unworkable solution, which
>         clearly I could not support.
> 
>         Hope that helps,
>         --Richard
> 
> 
>         On Thu, Apr 3, 2025 at 12:05 AM Meiling Chen
>         <[email protected]
>         <mailto:[email protected]>> wrote:
> 
>             Hi all,
> 
>             We will continue to track and actively address the issues
>             raised on NASR BoF, for convenience, I have brought the Q&A
>             record to the email list.
>             Welcome to continue discussing with those who are concerned
>             about these issues.
> 
>             Q1: Why is not end-to-end protection sufficient and why
>             should we care about where the traffic goes through?
>             Q2:  Why this is important to assure at the network layer?
>             Q3: List actual concrete examples of existing regulations.
>             Q4: List the technical requirements in detail.
>             Q5: NASR being a possible way to address pervasive traffic
>             monitoring threats?
> 
>             Q6: Proof of transit does not imply that the packet didn’t
>             exit the path. ---->PoNT is out of scope.
> 
>             Q7: There is work about proof of transit that has been done
>             in SFC, what is needed to highlight what is not there (in
>             routing, RATS, SFC PoT) which NASR will provide.-->
> 
>             NASR is the joint use of attestation techncology and proof
>             of transit.
> 
>             Q8: What about lawful interceptions?---->
> 
>             Trustworthiness as defined in RATS can attest that a router
>             does what is supposed to do, including lawful interception
>             if it is what it is supposed to do.
> 
>             Q9: There is work from RATS, like RFC 9684, that can be used
>             in NASR. Why an independent effort? Why not putting this
>             work in an existing WG?---->
> 
>             RATS is the building block to create path attestation, whose
>             usage is then verified with proof of transit. These two
>             things together look out of the scope of RATS. NASR does not
>             want to replace RFC 9684, but rather leverage it.
> 
>             Q10: What is exactly the definition of a path in NASR? BGP
>             session? Tunnel? physical links?---->
> 
>             A document in PANRG has a good definition of what a path is.
> 
>             Q11: Trustworthiness and traffic engineering are already
>             addressed in different places, so what is new in NASR? ---->
> 
>             The possibility for the customers to verify that the traffic
>             has been engineered in the way they asked. How to do it is
>             the gap NASR wants to fill.
> 
>             Q12: Candidate solutions from problems exist in other venues
>             (Routing security / SFC)---->
> 
>             True, but they do not address the combination (forwarding).
> 
>             Q13: Proposed work may result in fragmentation of the
>             Internet, including and excluding poeople?---->
> 
>             No. That is the wrong terminology to use. NASR is about path
>             complaint to a set of claims. Is a specific service in a
>             limited domain not a general service for the Internet.
> 
>             Q14: Clarification of requirements whether the requirement
>             is to detect nodes along the path that do not support NASR?---->
> 
>             No. Only have proof that traffic went through a set of nodes
>             that support NASR.
> 
>             Q15: Bringing the work to RATS would not work. RATS is
>             already bloated and bringing all this work there is not
>             possible.
> 
>             Q16: PoT has cryptographic cost.--->
> 
>             Implementation on SRv6 shows that the cost is very limited.
> 
>             Q17: Remark about the scope of implementation: Internet or
>             limited domain?--->
> 
>             limited domain implemented at the operator level.
> 
>             Q18: Need to verify every configuration (binary /
>             configuration files / routers) in order to determine the
>             properties of the path?--->This is not how remote
>             attestation works. There is no configuration shared, the
>             configuration is attested through trusted third party. You
>             share hash values that attest the the property.
> 
>             Q19: Why not doing this in the SFC WG?---->Piece can be done
>             in other WG, but from a global perspective wold be better to
>             have a WG.
> 
>             Q20: For reliability, what about having multiple paths? Can
>             it be a scalability issue? ----Yes, the attribute of
>             multiple path is included.
> 
>             Best,
>             Meiling
> 
>                 *From:* Liuchunchi\(Peter\)
>                 <mailto:[email protected]>
>                 *Date:* 2025-03-29 19:19
>                 *To:* [email protected] <mailto:[email protected]>; IETF SAAG
>                 <mailto:[email protected]>
>                 *CC:* [email protected] <mailto:[email protected]>
>                 *Subject:* [saag] NASR BOF Follow-Up
> 
>                 Hi NASR, SAAG,____
> 
>                 __ __
> 
>                 Thanks everyone for participating and contributing
>                 valuable feedbacks to the NASR BOF last week! Thank you
>                 Nancy and Luigi for mediating a productive discussion,
>                 and thanks Deb for supervising the process.____
> 
>                 __ __
> 
>                 During the process, we had extensive discussions that
>                 showed both major interests in the problem and differing
>                 understanding of the objective. For example, NASR
>                 represents new use case requirements that aim to extend
>                 Remote Attestation benefits to the network scale,
>                 providing more comprehensive security visibility and
>                 behavioral assurance across network deployments to the
>                 customers. But NASR is not intended, in any capacity, to
>                 serve as a substitute for end-to-end encryption
>                 technology, etc. ____
> 
>                 __ __
> 
>                 The poll result shows a clear consensus that this is an
>                 IETF problem, but a rougher (at best) or no consensus
>                 that the problem is well understood. ____
> 
>                 __ __
> 
>                 To help on that, next steps we will work on a dedicated
>                 document that collects all valuable feedbacks from the
>                 BOF and resolve them one-by-one. Again, we sincerely
>                 thank everyone who contributed valuable feedbacks and
>                 cares about bringing more security and transparency to
>                 networks!____
> 
>                 __ __
> 
>                 Best regards,____
> 
>                 Peter (Chunchi) Liu____
> 
>                 __ __
> 
>             _______________________________________________
>             saag mailing list -- [email protected] <mailto:[email protected]>
>             To unsubscribe send an email to [email protected]
>             <mailto:[email protected]>
> 
> 
> _______________________________________________
> saag mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]