[saag] Re: [nasr] Re: Re: NASR BOF Follow-Up
Henk Birkholz <[email protected]>
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
On 11.04.25 15:38, Eric Rescorla wrote: > > > On Fri, Apr 11, 2025 at 2:01 AM Henk Birkholz > <[email protected]> wrote: > > 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)? > > > Probably not very much. What salt does is make it more difficult to > amortize computation > across multiple hashed values. However, if the total number of possible > values > is low (e.g., you have some configuration setting with 3 values) then > you can > just exhaustively search at query time. That makes a lot of sense - and might be another good reason not to put these types of Claims into Evidence. I still think it is better to include software components that provide the conveyance mechanism (e.g., a YANG server with YANG Push capability) in a TCB and then use successfully appraised software components for trusted telemetry to convey such values for evaluation. Viele Grüße, Henk > > -Ekr > > > > 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]>> > > <mailto:[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> > > <mailto:liuchunchi > <mailto:liuchunchi>>[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> > > > *Date:* 2025-03-29 19:19 > > > *To:* [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>; IETF SAAG > > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > > *CC:* [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > <mailto:[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]>> > > <mailto:[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]>> > > > <mailto:[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]>> > > <mailto:[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]>> > > > <mailto:[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > > > > _______________________________________________ saag mailing list -- [email protected] To unsubscribe send an email to [email protected]