[saag] Re: [nasr] Re: Re: NASR BOF Follow-Up
Henk Birkholz <[email protected]>
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
On 10.04.25 21:01, Eric Rescorla wrote: > > > On Thu, Apr 10, 2025 at 11:40 AM Henk Birkholz > <[email protected]> wrote: > > On 03.04.25 21:11, Eric Rescorla wrote: > > > [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. > > > Because the values themselves are generally low entropy, so if you > publish their hashes, then it's generally easy to determine the preimage. > > -Ekr Would some salt help here (like the salted hashes in sd-cwt)? Viele Grüße, Henk > > > 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]> > <mailto:[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:liuchunchi > <mailto:liuchunchi>[email protected] > <mailto:[email protected]>> > > *Date:* 2025-03-29 19:19 > > *To:* [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>; IETF SAAG > > <mailto:[email protected] <mailto:[email protected]>> > > *CC:* [email protected] <mailto:[email protected]> > <mailto:[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]> > <mailto:[email protected] <mailto:[email protected]>> > > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > -- > > nasr mailing list -- [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > _______________________________________________ saag mailing list -- [email protected] To unsubscribe send an email to [email protected]