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

On Mon, Apr 14, 2025 at 8:23 PM Toerless Eckert <[email protected]> wrote:

> On Fri, Apr 11, 2025 at 03:50:04PM -0700, Eric Rescorla wrote:
> > 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.
>
> Well, if you don't raise a technical concern against an answer, that's not
> helpfull.
> And "non persuasive" is not a technical concern. But i guess what you
> wrote below is
> attempting to express the technical challenge you see.
>

You seem to be operating under the assumption that I'm somehow
required to go back and forth with you indefinitely as long as you're
willing to argue. That's not how this works. The proponents of some
project have the burden to build consensus and it's perfectly reasonable
for others to timebox that interaction.


> 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).
>
> Firstly: The "number of known good configurations" is a red herring. Where
> did that come from ?
>

It's a point I raised in the meeting that I don'tthink has ever been
adequately
addressed.


The config file could be a MByte large. One will work with cryptographic
> hashes of
> the config.


This is irrelevant to my point one way or the other.



> Yes, 99% of the config is irrelevant to assessment, so the NASR
> mechanics needs to unnecessary re-assess config changes that are
> irrelevant.
> But that can easily be optimized:
>
>   First run the file of interest is eg: "show conf everything".
>   Then the NASR logic looks at whats relevent. For example only a subset
>   of interfaces and routing entries. And issues a request for a file
>   that contains only that subset "show conf int e0 e7 e13; show conf
> routing X.Y.0.0/16"
>   With such an optimiation, NASR logic would need to re-assess confidence
>   in desired operations only when relevant config changes happen.
>

"NASR logic" is doing a lot of work here. Actually writing that logic
requires
examining every single configuration directive to determine which ones
are security relevant. Has someone done that exercise? If so, please
point me to it.

> 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.
>
> Verifying "other people's" config such as "show config all" is something
> that
> support personal in vendors has done for decades. Including me. Its not
> that
> hard to automate (with todays tools... 30 years back it was not ;-).
>

As I've been trying to explain, this is a different thing, roughly
comparable to mechanically determining that a piece of code
does what it's supposed to do. That's different from just looking
at specific things to see if they're right. As an analogy, when I
have a piece of code that's misbehaving, I first look at the
defect in the obvious places, but if I need to verify that code
behaves correctly, I need to look at unobvious places as well.



> As explained above, it is not about about minimizing variations. It is
> about avoiding
> re-assessment unnecessarily when there are only irrelevant
> config/operational changes.
>

And as I said, knowing what irrelevant is part of the problem.



> > So, no, I don't think what you have written above provides much in the
> > way of evidence that this is practical.
>
> Please tell me what additional evidence you would like to see beond the
> above
> explanations. I am sure that the NASR team would be happy to provide more
> exemplary evidence too, but only when it was clear upfront what the actual
> "accept" criteria are on your side - because it is impossible to have a
> technical argument purely against "i am not convinced" (without further
> explanation).
>

I've already explained what I'm looking for a number of times, but perhaps
I should be more explicit:

A demonstration or at least evidence that it's practical to take actual
router
configurations produced by other people and mechanically verify the specific
semantic properties of interest. To try to short-circuit a lot of back and
forth, what
you have above "show conf <...>" is insufficient because we need to know
that there are no other directives which could affect these processes.

What would I find persuasive here? I could imagine a number of things, but
probably the best would be, as I said above:

- Some set of predicates we wanted to verify about a network element
- A written analysis of all the configuration directives in some production
system
  and which ones could impact those predicates.


-Ekr

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