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

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.

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

The config file could be a MByte large. One will work with cryptographic hashes of
the config. 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.

  And vendors for long have local scripting that would easily allow to create
  very quickly new, tailored config outputs - and such scripts provided by the vendor
  can equally have vendor signed output, so optimizing NASR config assessment should
  be possibleto do very agile, especially for large operators.

Secondly: You need to trust someone. Like you trust a TLS connection to go to google
if it presents a cert saying *.google.com, you do trust the shown config to be
from a "trusted" vendor when its signed with that trusted vendors certificate (and
all the device-level trusstworthyness as from RATS was assessed).

> 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 explained above, it is not about about minimizing variations. It is about avoiding
re-assessment unnecessarily when there are only irrelevant config/operational changes. 

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

[I would argue that tenths of thousand of operators across millions of routers
can create at least as many undesired service failures as evil hackers,
each of which likely has to reinvent such an attack from scratch. but
does not really matter. Solution needs to work for evil and stupid. ]

I am happy to obsess about this, because i have dealt with this problem 
for decades, and RFC8994 is one very comprehensive but complex solution to
the problem for one specific service (eliminate all config options so security
guarantees are absolute irrelevant of config).

To me, your concern is actually a core reason why we should have NASR, because
the problem of analyzing config behavior is of core importance to reliable
network operations far beyond specific security-guaranteed path services,
and NASR is the best way to drive standardization to improve.

One can repeatedly see issues where networks go down because manual or SDN
orchestration (recently more the latter) has brought down networks due to
unintended consequences of config changes that are insufficiently analyzed/understood.
IMHO mostly because of arrogance of SDN controller developers and/or operator
wanting to deal with a problem in the wrong way. NASR can be the framework
to expose these issues and opportunity for us to define how to solve them.

So, what's the solution ?

First of all, i think the problem of guaranteeing that traffic stays on a
path is much smaller to validate than the aforementioned "traffic will not
be disrupted". 

Secondly, more novel networks like DC will have more novel, simpler cnfigs
and newer/better router OS that result in easier analyzed configs.

Thirdly, there is a very limited number of options to create copies of
traffic (beside LI), so that's IMHO very easy to analyze.

Fourth: The complexity of evaluation "stays on an approved path" very much depends
on the choosen network service. And if you want NASR service quickly, you
may choose for that traffic a configuration option that makes it easy!

For example, if i wanted to ensure that traffic goes only on predetermined good paths,
in a way that makes it easy to validate in config files, i could easily do that
with a very high degree of confidence by simply using RSVP-TE with
strict ERO, aka: explicit hop-by-hop indicated in the headend
router, and easily validated by examining just a small portions of the configs
of all the routers along the path. Or manually doing the same with per-hop
static routes (if you don't have RSVPT-TE capability). And the confidence is of
course high that other configs could derail that traffic.

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

> (even leaving aside Richard's
> concerns about whether operators are actually going to let peers
> poll the operational state of their devices).

Doesn't have to be peers. Working for a vendor, i would of course primarily love
the option of the evidence being created by scripts in routers that the router
(hence the vendor) can sign - because that option void introduction of a third party
and allows to limit attestation such that no undesired exposure of "internal" data
happens. I think the RATS/NASR folks primarily think of an external controller
based analsysis of config run by a third party (and hence signed by it). Which is fine
too given how such a controller could be from vendors, but laos from a range of other
parrties that the network operator would expose  the routerinformation too, because those
organizations would be required to have similar visiblity anyhow:
FCC or contractor thereof, SAIC (for e.g.: customers with federal contracts) - just to name
two coming to mind from the USA.

More likely outsideof regulation just "extended internal" parties: the security department
of an operator is typically quite disjoint from the actual network operations department and
if i as a customer get a signed attestation from that security department, that
would go a long way in havin trust in the service. There are also well structured
operators where customerr services are provided by an "overlay" organization
which equally would easily get insight into router configs of the whole network
and then attesting to a specific customers service properties indepentend of
the actual network operations department.

I am pretty sure that the more we are getting into trustworthy evidence 
of proper "secure" operations of network services subject to compliance
requirements that we will have to deal with all these technical issues of
validation anyhow in the industry. But only by adding the aspect of cryptographic signing
and defining attack models and chain of evince through an approach like NASR
will we be able to standardize solutions for this problem space in the IETF.
Without that, the  bet that IETF could do is just hand waiving in the face of
obfuscated, secretive and ultimately untrustworthy operational practices.

Cheers
    toerless

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

-- 
---
[email protected]

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