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

On Tue, Apr 15, 2025 at 9:20 AM Toerless Eckert <[email protected]> wrote:

> > "Is it practical to mechanically verify that a configuration is
> acceptable?"
>
> I hope i gave sufficient practical insight in my prior answer to support
> the "Yes" to this question, if not, then please challenge that answer or
> ask for what might have been unclear in it.
>

No, I don't think you did. I've already responded in that thread.


> "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?"
>
> I think we repeated answered this concern by pointing out that the
> party allowed to receive information about the router such as (parts of)
> the
> configuration MUST be trusted to handle that information in a required
> responsible
> fashion.


This isn't my point but rather Richard's so I'll leave this part to him.

-Ekr



> Such as passing on to a subscriber or application ly an evaluation such as
> the availability of the desired service guarantees (path properties)
> And i gave several examples of such receiving parties (3rd party device
> from
> trusted vendor, compliance/regulatory authority assigned entity,
> federation assigned entity,
> service-provider/operator run, ...). Other NASR people gave more example.
>
> Of course transfer of configuration to such a third party uses existing
> SSH/TLS with authentication/authorization and then Netconf/Restconf/CLI.
>
> Authorization too can for decades now express constraints such as that
> only config can be retrieved. This has also for long been used to allow
> some well-controlled co-management primarily on the edge to subscriber
> operators, e.g.: on MPLS/VPN-PE routers of SPs.
>
> Cheers
>     Toerless
>
> On Tue, Apr 15, 2025 at 10:17:11AM +0200, Henk Birkholz wrote:
> > Hi ekr,
> >
> > I apologize for mixing provenances... again! For me, dipping in into this
> > thread occasionally, it is not easy to track data origin vs. data source
> > without a napkin note.
> >
> > Both questions:
> >
> > "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?"
> >
> > and
> >
> > "Is it practical to mechanically verify that a configuration is
> acceptable?"
> >
> > sound like really good questions to me. Personally, I am under the
> > assumption that both of these questions are not RATS questions and maybe
> not
> > even SEC area questions. They seem to me more like OPS area questions,
> > right?. Please chime in here on the SAAG list, if you think that was a
> weird
> > thing to say! (Obviously, opsec is a thing, but I am referring the
> > "mechanics" of the solution providing an answer to the questions).
> >
> > I also think that (from a RATS perspective) the answer to those
> questions is
> > really interesting (as it could inform the exposure of RATS conceptual
> > messages). Will these questions be worked on?
> >
> >
> > Viele Grüße,
> >
> > Henk
> >
> >
> > On 11.04.25 23:29, 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]
>

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