[saag] Re: [nasr] Re: 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]