[saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follo w-Up

On Tue, Apr 15, 2025 at 01:18:24PM -0400, Watson Ladd wrote:
> > [Ongoing techniques] Extraction techniques, we have to-be-RFC TPM-CHARRA draft that conducts YANG-based extraction. There is WIP YANG-provenance draft that confirms YANG config coming from a right source. There is WIP multiple-verifiers draft that works with many vendors in one single domain.
> >
> > Is this trust assumption and scope-narrowing statement good for you?
> 
> But at this point what is this doing that RANCID doesn't? Why do we
> need transit proofs and all that, if we're never exiting a domain?

I thought the constraining of scope related to starting the charter with single-domain
not about the mechanics of extraction.

The specific protocol mechanics to extract in a secure and trusted fashion config and
operatinal state from network devices is (IMHO) just a technical detail - albeit of
course important for MTI standards. The key contribution of NASR (IMHO) would be
to derice a semantic analysis of that data. Which over time can be simplified a lot by evolving
our YANG models to explicitly express such service semantics.

For example, a specific reference NASR service use case spec could describe exactly
the set of YANG model data to collect and how to analyze it to assess the correct
operation of the desired service across the path. 

Cheers
    Toerless

> >
> >
> >
> > Best,
> >
> > Peter
> >
> >
> >
> > From: Eric Rescorla <[email protected]>
> > Sent: 2025年4月12日 6:50
> > To: Toerless Eckert <[email protected]>
> > Cc: Henk Birkholz <[email protected]>; Richard Barnes <[email protected]>; Meiling Chen <[email protected]>; Liuchunchi(Peter) <[email protected]>; [email protected]; IETF SAAG <[email protected]>; Luigi Iannone <[email protected]>
> > Subject: Re: [nasr] Re: [saag] Re: NASR BOF Follow-Up
> >
> >
> >
> > On Fri, Apr 11, 2025 at 3:37 PM Toerless Eckert <[email protected]> wrote:
> >
> > Which part of my prior answer was unclear ?
> >
> >
> >
> > It's not so much that it was unclear as that I didn't find it persuasive.
> >
> >
> >
> >
> >
> > Of course it is practical to automatically verify configurations.
> > The more feature-rich a router is, the harder it will be. I described some of
> > the basic issues of complex config dependencies in rfc8368, which is a use-case
> > for rfc8994, which you reviewed as AD. Validation also depends a lot
> > lot on the type of service you are trying to validate correct configuration for.
> >
> > Today, most configurations in "professionally managed networks" are created from
> > known/assumed-to-be working correctly configuration templates anyhow. So a lot of
> > validation happening today for config is simply a comparison between pulled config
> > state on the router against the target (policy * template) generated config. There
> > are whole management empires built around these approaches such as intent based
> > networking, intent rendering and the like. Just hang out with NMRG.
> >
> > But as also answered, config alone will never be sufficient to capture all cases,
> > so yo do need to poll operational state of the devices and match that against
> > expectation as well. Same process. Just will tell you think like wheter you actually
> > do have a secure network link to a neighbor with known/trusted credentials and the
> > right routing table entries. As opposed to just looking at "config", which is something
> > that may exist even independently of whether the router is even running.
> >
> >
> > All that is done in many many network operators automatically for a long time time.
> > We just have not applied cryptographic signing of authentication/verificiation, especially
> > when multiple parties are involved.
> >
> >
> >
> > But the fact that multiple *mutually distrusting* parties are involved is the
> >
> > source of the problem. If you are the person managing the devices, then,
> >
> > yes, you can have a small number of known good configurations and
> >
> > readily check that the deployed configurations are OK (mostly).
> >
> >
> >
> > But the situation with NASR is totally different: you need to consume other
> >
> > people's configurations and verify if they are OK, and you don't get to
> >
> > control them to minimize your variation. Worse yet, you have to worry that
> >
> > they are deliberately changing unexpected configuration directives in order
> >
> > to undermine the protections they are claiming [0]. This is a totally different
> >
> > problem, which is roughly the same as the difference between writing
> >
> > correct code and verifying that someone else's code is correct.
> >
> >
> >
> > So, no, I don't think what you have written above provides much in the
> >
> > way of evidence that this is practical (even leaving aside Richard's
> >
> > concerns about whether operators are actually going to let peers
> >
> > poll the operational state of their devices).
> >
> >
> >
> > -Ekr
> >
> >
> >
> > [0] I expect people to argue that this is too aggressive a threat model, but
> >
> > the whole reason to have all this encryption is to prevent the counterparty
> >
> > from lying about its state.
> >
> >
> >
> >
> >
> > And create a seamless link between infrastructure
> > validation, such as secure boot etc. with rats and service validation. And orchestration
> > of validation with that crypto approach, which ultimately what sstage 1 of NASR is.
> >
> > Cheers
> >     Toerless
> >
> > On Fri, Apr 11, 2025 at 02:29:12PM -0700, Eric Rescorla wrote:
> > > On Fri, Apr 11, 2025 at 11:50 AM Henk Birkholz <[email protected]>
> > > wrote:
> > >
> > > > On 11.04.25 19:23, Eric Rescorla wrote:
> > > >
> > > > Hi Ekr,
> > > >
> > > > sorry for dragging you through this convo, but I think I now have a
> > > > better understanding of your problem statement than before. Thanks!
> > > >
> > > > As far as I am understanding it for now, the question is: "is it
> > > > possible to determine that the configuration/policy of a device is
> > > > acceptable in a fashion that does not expose that configuration/policy
> > > > to a counterparty?" That question would be independent from "RATS
> > > > Evidence" which was popping up in the thread before.
> > > >
> > >
> > > To be clear, that was *Richard's* question. My question was prior to that,
> > > namely "Is it practical to mechanically verify that a configuration is
> > > acceptable?"
> > >
> > > -Ekr
> >
> > --
> > ---
> > [email protected]
> >
> > _______________________________________________
> > saag mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> 
> 
> 
> -- 
> Astra mortemque praestare gradatim
> 
> -- 
> nasr mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

-- 
---
[email protected]

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