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

On Wed, Apr 16, 2025 at 05:02:32PM -0400, Watson Ladd wrote:
> > RANCID has been doing a great job for decades, but by would you believe
> > that a network device is exposing its actual (potential latent) and
> > operational state to you? All devices could already lie to you because
> > they are compromised. If your are an organization that could be subject
> > to audits or some other forms of accreditation or accountability, than
> > maybe you would like to show that acquired data about your systems is
> > authentic and also auditable after the fact. That can include critical
> > data flows in side your domain or to its "edges" (following the
> > assumption that a healthy network device will not forward transfer units
> > over non-endorsed or otherwise secured interconnects).
> 
> I'm confused. Why does RATS magically solve this problem? You can have
> the world's most secure boot chain, and if the software is compromised
> it might still lie/you will be mislead about the consequences of the
> configuration being in a state because by assumption the software
> doesn't behave properly.

RATS does not "magically" solve the problem. RATS simply adds remote attestation
to devices and software stacks that support secure boot, secure hardware/concepts
(e.g.: TPM) and software stacks. Which is a damned lot of work to implement. 

Of course there is no black an white, and everything is a matter of probabilities,
but secure boot/hardware/software is the best toolset we have to protect
against evil impairment and to also support a wide range of compliance
purposes beyond that.

So yes, there should be a great amount of trust one should be able to
have that hardware/software is not impaired when these secure device/software
level aspects are well implemented. 

And with the use of different trust anchors (vendor, operator, certifying
entities, you can also derive trust in specific behavior from the entities
that you consider authoritative for the specific aspect.

> That's the gap which I think Eric and I think
> can't be crossed: going from the configuration to the property, not
> getting the config out (which sure, throw RATS at it)

Example:

You trust that the router is running authentic software from the trusted
vendor because the image is signed by the vendor and the routers secure boot
chain and trusted execution environment did perform secure boot, attesting
to the fact that that specific software is running.

You also trust that thet specific version of the software provides correct
"show run config" (or the like) output because you also have an attestation
statement for that software version from a validation authority you can
trust - such as a signature from that authority for the software versions
secure hash.

But i think Eric does not think that the config could be "non-authentic/impaired",
but rather that it is difficult/impossible to derive from the configuration
a specific behavior. But in response to that i provided hopefully sufficient
high-level examples of possible config options that makes it darn simple
to evaluate from config that specific traffic not derailed from a path
that is easily determined from the config (and operational state).

Cheers
    Toerless

> --
> Astra mortemque praestare gradatim

-- 
---
[email protected]

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