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

On 03.04.25 21:11, Eric Rescorla wrote:
> 
> 
> On Thu, Apr 3, 2025 at 6:09 AM Richard Barnes <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> 
>     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.
> 
> 
> I think the key point here is that attestation just acts to
> demonstrate that a given endpoint has a given configuration, but what
> relying parties are actually interested in is whether the endpoint
> conforms to a specific policy.

This is an interesting point.

Typically, remote attestation is not limited to Evidence about 
configuration. But more importantly, Evidence does not necessarily 
include policies originating from an Attester for appraisal by a 
Verifier at all. Certain policy could be conveyed (e.g., represented by 
a hash value, a "measurement") to a Verifier that is fueled by 
corresponding Reference Value Provider with corresponding "reference 
hashes" for said policies.
If Claims that represent policies are in fact required to be in Evidence 
and those polices change quite often over time (are "volatile"), then a 
finer granularity of Claims about polices in combination with 
correspondingly granular Appraisal Policies for Evidence could allow for 
remote attestation procedures to appraise those, too (to mitigate some 
of the combinatoric explosion you are mentioning below).

I am not certain that that would be the best way to do it, though, as 
that would generate quite a lot of Evidence - and thereby the freshness 
of Attestation Results is often in question. Maybe a telemetry channel 
enabled via YANG Push, for example, would be a better way to do that, if 
the telemetry originates from a trustworthy ("RATS approved") network 
device?

> 
> In some cases, there is a relatively straight line between
> configuration and policy. For instance, in the case of DRM, the
> content provider wants to know that the endpoint won't exfiltrate the
> raw content, and it can assure itself of this by determining that the
> endpoint running one of a small set of media players/CDMs, etc. that
> it knows prevent -- or at least resist -- exfiltration. This is
> also consistent with just knowing a hash of the code because there
> are only a small number of valid configurations.
> 
> 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:
> 
> - Having the element attest to the state of the code and the
>    relevant configuration directives.
> 
> - Having the element attest to the code and then somehow assert
>    that the state of the configuration directives guarantees
>    some set of properties (e.g., "all data of class X follows
>    path Y").
> 
> In the former case, it is quite likely that there will be a large
> number of valid states, because each directive may have multiple
> acceptable values, and so you end up with combinatoric explosion
> issues if you just have a list of hashes [0]. In the latter case we
> need some language for talking about the policy claims; I suppose
> that's possible, but it seems like it could get complicated quickly,
> and I don't see anything like that in these drafts, though perhaps
> I'm missing it.

Policy is still out-of-scope of the RATS charter, but there are popular 
options, such as signed OPA Rego fragments.

> 
> Either approach requires studying the impact of every existing
> configuration directive for each device type to know what the
> impact will be on the relevant policy claims. This seems challenging
> at best.
> 
> -Ekr
> 
> 
> [0] Of course you could hash the individual configuration values,
> but this is much the same as publishing the configuration.

Is it? I am curious why.


Viele Grüße,

Henk

> 
> 
>     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]>
> 
>     -- 
>     nasr 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]