[saag] Re: [nasr] Re: Re: NASR BOF Follow-Up
Toerless Eckert <[email protected]>
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
> "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.
> "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. 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]