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

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

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.

You are right, and this is the reason we emphasize many times that this is not for public internet use—it only works in one limited domain, where a single operator has administrative control over all devices in his domain, like CMNET metro network owned by China Mobile. Theoretically (and practically) the operator owns all these devices. So it is not really “other people’s devices”, it is “my devices”. Meiling can add to this if I am wrong or right.

So this may yield two major trust assumptions:


  1.  [My device] Operators have administrative control over all devices in his domain, regardless of vendors.
  2.  [Truthful intention] Operators extract real router configurations out of truthful intention, using whatever best techniques available.

[Ongoing techniques] Extraction techniques, we have to-be-RFC TPM-CHARRA draft<https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/22/> that conducts YANG-based extraction. There is WIP YANG-provenance<https://datatracker.ietf.org/doc/draft-lopez-opsawg-yang-provenance/> draft that confirms YANG config coming from a right source. There is WIP multiple-verifiers draft<https://datatracker.ietf.org/doc/draft-zhang-rats-multiverifiers/> that works with many vendors in one single domain.

Is this trust assumption and scope-narrowing statement good for you?

Best,
Peter

From: Eric Rescorla <[email protected]>
Sent: 2025年4月12日 6:50
To: Toerless Eckert <[email protected]>
Cc: Henk Birkholz <[email protected]>; Richard Barnes <[email protected]>; Meiling Chen <[email protected]>; Liuchunchi(Peter) <[email protected]>; [email protected]; IETF SAAG <[email protected]>; Luigi Iannone <[email protected]>
Subject: Re: [nasr] Re: [saag] Re: NASR BOF Follow-Up

On Fri, Apr 11, 2025 at 3:37 PM Toerless Eckert <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>

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