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

On Tue, Apr 15, 2025 at 07:27:00PM -0700, Eric Rescorla wrote:
> > 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.

I am very appreciative of the time spend by you here helping the community
with your insights. So i definitely want to treat your time as a precious resource.

The advice given to me to help the process was to focus on
helping to resolve any open technical challenges brought forward against the proposal.
That is what i am trying to do to the best of my abilities.

> > 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.

Yes, i know you raised it. As i tried to explain below, i think there is
no reason to ask for a (limited) number of known good configs. Thats whay i am
asking. Circling back after having read the entire email i have not seen
an explanation for this requirement, so if you think it persists beyond
what you wrote in the rest of your mail, then please explain.

> 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.

Just one example for RSVP-TE (traffic engineering) which i mentioned:

Many network providers sell for about 20 years advanced network services
where a customer traffic flow is given explicit throughput (and even latency) 
guarantees. For each instance of such a traffic there is an upfront
offline calculation about which path this traffic can take, and bandwidth and
buffers along the path is reserved for this traffic.

This traffic is often so big that it could take down other network paths
or traffic if it was incorrectly or unexpected re-routed along a different path.

So i think that through the (a) wide-spread successful use of these services
(b) for decades (c) by many service providers (d) avoiding such
catastrophic failure scenarios, we have pretty good evidence that networks
can perfectly well make traffic follow a predetermined path under
normal operating circumstances. Existing RATS stuff allows us to trust
that the config retrieved from a router is what's actually used. And
NASR use-cases just change desired properties from throughput/latency to
other, like location, certification, or the like.

We could even skip the parsing/independent validation of the config
if the whole config was created by a provisioning tool known to be
sufficiently good / bug-free. It justneeds to create signature for the
config we can then verify.

There are a lot of commercial tools that do independent verification of
various aspects of config. Validating that a particular RSVP-TE traffic
follows a specific path is quite simple IMHO. I'll ask on TEAS about
independent tools that could do this (thats the WG responsible for
TE).

> > 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.

I actually don't think it is that different. When i am looking at MBytes of
config/operational state of routers in a network where some traffic is
not flowing as it should, i think i am doing a lot of the same steps
you describe. And i have done this both as a customer when i was just
running a network, but also as a developer when i read the code to
understand all the interactions of all the features that would impact
the traffic flow in the forwarding plane - and how the features interacted.

> > 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.

Sure, and i think that is very easy to asses in an automated fashion -
especially when you consider that service provider network configs
are based on only really small subsets of possible configs and
features.

And to repeat from previous email: There are lots of things that can
go wrong in a router,but if you understand how to configure explicit
paths for traffic (as i was giving the example), then it is extremely
easy to ensure that the traffic will not derail from this path.
And that is is IMHO very easy then to determine from config.

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

Thanks. "PRAGMA Do-what-i-mean" is really often difficult to implement

> 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.

Sure.

> 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

As in: The details of the necessary config across multiple router to
asses that the traffic will flow across a specific path to validate
independently.

> - A written analysis of all the configuration directives in some production
>   system and which ones could impact those predicates.

As in all the possible gotchas that could if configured (as a mistake) would
derail the traffic.

Let me circle back on this.

Thanks a lot again!

Cheers
    Toerless

> -Ekr

> -- 
> nasr mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

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