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

[Watson Ladd <[e-mail]>]

On Mon, Apr 14, 2025 at 10:50 PM Liuchunchi(Peter)
<liuchunchi=[e-mail]> wrote:
>
>
>
> 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:
>
>
>
> [My device] Operators have administrative control over all devices in his domain, regardless of vendors.
> [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 that conducts YANG-based extraction. There is WIP YANG-provenance draft that confirms YANG config coming from a right source. There is WIP multiple-verifiers draft that works with many vendors in one single domain.
>
>
>
> Is this trust assumption and scope-narrowing statement good for you?

But at this point what is this doing that RANCID doesn't? Why do we
need transit proofs and all that, if we're never exiting a domain?
>
>
>
> Best,
>
> Peter
>
>
>
> From: Eric Rescorla <[e-mail]>
> Sent: 2025年4月12日 6:50
> To: Toerless Eckert <[e-mail]>
> Cc: Henk Birkholz <[e-mail]>; Richard Barnes <[e-mail]>; Meiling Chen <[e-mail]>; Liuchunchi(Peter) <[e-mail]>; [e-mail]; IETF SAAG <[e-mail]>; Luigi Iannone <[e-mail]>
> Subject: Re: [nasr] Re: [saag] Re: NASR BOF Follow-Up
>
>
>
> On Fri, Apr 11, 2025 at 3:37 PM Toerless Eckert <[e-mail]> 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 <[e-mail]>
> > 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
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> saag mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim