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

[Richard Barnes <[e-mail]>]

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 <[e-mail]>
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\) <liuchunchi=[e-mail]>
> *Date:* 2025-03-29 19:19
> *To:* [e-mail]; IETF SAAG <[e-mail]>
> *CC:* [e-mail]
> *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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>