[saag] Re: [nasr] Re: Re: Re: Re: Re: Re: NASR B OF Follow-Up
Toerless Eckert <[email protected]>
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
Wrt to leakage prevention:
There are various methods in routers to limit possible traffic flows
to some desired 'subdomain' of a network, or exit-points, or whatever you
want to call it. VPNs being of course a well-known and widely used/sold
type of service with such properties. L2VPN, L3VPN being specifically the
IETF standardzied methods to do so flexibly. And various ways to create them through
appropriate configuration.
Lets remember that NASR can, but does not need to provide/use new services. It
can equally be simply a method to provide a more automated secured and trustworthy
infrastructure to asses existing services. Such as any type of existing VPN
or other confined environment type of service.
In other words: leakage prevention does in most cases not need to be a new requirement.
It is the requirement number one for almost all network services today sold to
customer with some degree of confinement of traffic requirements. Like any
enterprise / industry / "IoT" / government / ... network and whatever
"firewall" / "VPN" services they host or subscribe to (or often a combination thereof).
RATS+NASR are just there to take the magic trust out of assesment and replace
it my a flexible cryptographically secured framework of automating it.
And PoT is a great additional method to do actual forwarding plane assesment,
something which we actually did not have in before. And it can be a great
additional fail-safe for when operational state analysis alone is seen as too
complex or infeasible.
Cheers
Toerless
On Thu, Apr 10, 2025 at 10:13:48PM -0700, Watson Ladd wrote:
> On Thu, Apr 10, 2025 at 8:15 PM 刘鹏辉 <[email protected]> wrote:
>
> > Hi all,
> >
> >
> > As I mentioned before, as a trusted node, network devices must first pass
> > some form of third-party authoritative trusted authentication (or operator
> > customized authentication), and at the same time run pre built
> > authenticated trusted components on the device. These trusted components
> > have undergone strict testing and cannot run other non authenticated
> > software on the network. By obtaining these authentication information (as
> > evidence) to prove whether the network device is a trusted node, it is
> > selected by the arranger when providing business services. These
> > authentication information as evidence, such as certificates, operational
> > status, configuration information, etc., should be available for customers
> > to query. The orchestration and network equipment here are owned by the
> > operator. The POT containing evidence is retained along with the
> > transmitted business data for verification in case of legal issues.
> >
> > NASR is written into the SLA as a service to clarify the responsibilities
> > of both parties.
> >
> > If these cannot be met, customers may as well choose physical dedicated
> > lines to transmit data without the need for NASR.
> >
>
> I think the problem here is that there's a gap between the properties NASR
> is supposed to give (say the quality of the copper in the connections being
> transited) and what's visible or interpretable in the router state (a whole
> bunch of BGP configs that dynamically change). A proof of transit is
> somewhat useful, but there's an issue in translating that into e.g.
> "failure will never send your traffic over a path you don't want". We might
> need to add an Extensible Analysis to NASR to be sure the attributes users
> care about are ones that can be covered.
>
> Sincerely,
> Watson
>
>
>
> > BR,
> >
> > Penghui liu
> >
> >
> >
> >
> >
> >
> > At 2025-04-11 08:11:12, "Toerless Eckert" <[email protected]> wrote:
> > >Eric,
> > >
> > >>From my understanding, this analysis does not need to be constrained to
> > >configuration state. In fact, i would never want to trust configuration state
> > >alone, but only configuration and operational state.
> > >
> > >This is the same for existing rats for e.g.: secure bootstrap. The attestation provided
> > >by a device is not that it has some "operating system file with some cert/signature",
> > >but that that is actually the running OS.
> > >
> > >In the same way, you would start collecting enough attestation to trust the commands
> > >through which you retrieve operational state (including prior valiation of all credentials
> > >to talk to the routers). Such as (YANG equiv) "show int * macsec state"
> > >or the like (to circle back to my most favourite feature ;-). Which would show
> > >enough details to know the credentials of the peer and that the interfaces traffic
> > >is MacSEC secured with approved session and data encryption protocols.
> > >
> > >It is then the controller who provides the attestation for the fact that the network
> > >(or subdomain or whatever) is running MacSec beteween all members.
> > >
> > >And if we could get scripts into routers to do this analysis of operational state
> > >locally on a router, that would be even better, because then it could probably
> > >be extending what the router can attest to itself - and the NASR controller needs to
> > >primarily provide only attestation as to the seamless connectivity of the per-hop
> > >encrypted topoloy or path of interest.
> > >
> > >Cheers
> > > toerless
> > >
> > >On Thu, Apr 10, 2025 at 12:28:39PM -0700, Eric Rescorla wrote:
> > >> On Thu, Apr 10, 2025 at 11:02 AM Henk Birkholz <[email protected]>
> > >> wrote:
> > >>
> > >> > Hi ekr,
> > >> >
> > >> > auditing the "correctness" of configuration or configurable state is an
> > >> > additional step that comes with its own security considerations, I think.
> > >> >
> > >> > The fact that a network device is trustworthy (it is doing what it is
> > >> > intended to do (by the Verifier Owner) and nothing else) does not
> > >> > directly translate to an operational state that is doing what every
> > >> > Relying Party expects it to do, I think.
> > >> >
> > >> > In remote attestation, the Verifier can be considered a trusted third
> > >> > party that takes on the burden of Evidence appraisal. As there are can
> > >> > be a quite colorful bouquet of Attester and Evidence types, that
> > >> > (sometimes quite significant burden/complexity) burden of Evidence
> > >> > appraisal is off-loaded to Verifiers so that the audience of Relying
> > >> > Parties can consume digestible Attestation Results tailored to their needs.
> > >> >
> > >> > If there is additional "relevant stuff" w.r.t. a network device which
> > >> > needs to be evaluated, that might be a task that remote attestation is
> > >> > only in support of - but that does not seem to be an explicit part of
> > >> > establishing trust in the trustworthiness in a remote peer/router. Or am
> > >> > I missing something very obvious here?
> > >> >
> > >>
> > >> I don't know if you're missing something, but I don't really see how
> > >> this addresses my point, which is about the complexity of evaluating
> > >> the relevant Evidence, not about who does it. Specifically, my concern
> > >> is that it will not be practical to determine whether a given router
> > >> configuration enforces the high level semantics desired by the
> > >> Relying Party, e.g., that the data is going directly from this system
> > >> to system B without any ability for anyone else to see it. In order
> > >> to ensure this, someone has to know that all configuration values
> > >> that might implicate this guarantee are in known good states. That
> > >> could happen by, for instance:
> > >>
> > >> - The Verifier seeing Claims for all the relevant configuration values
> > >> - The vendor determining which configuration values are relevant
> > >> and causing the device to emit a higher level Claim
> > >>
> > >> But in either case, someone needs to take on the analysis of all
> > >> the configuration values. Has this been done for the types of devices
> > >> in question?
> > >>
> > >> -Ekr
> > >>
> > >>
> > >> >
> > >> >
> > >> > Viele Grüße,
> > >> >
> > >> > Henk
> > >> >
> > >> > On 06.04.25 22:52, Eric Rescorla wrote:
> > >> > >
> > >> > >
> > >> > > On Sun, Apr 6, 2025 at 12:41 PM Michael Richardson
> > >> > > <[email protected] <mailto:mcr%[email protected]>> wrote:
> > >> > >
> > >> > >
> > >> > > Eric Rescorla <[email protected] <mailto:[email protected]>> wrote:
> > >> > > > However, it's not clear to me that that's true in this case,
> > >> > > because
> > >> > > > unlike media players, network devices are highly configurable
> > >> > > and a
> > >> > > > large number of the configuration directives might impact the
> > >> > > relevant
> > >> > > > security claims. Thus, determining whether an element is
> > >> > policy
> > >> > > > conformant is a matter of knowing not just what code it is
> > >> > > running
> > >> > > > but the state of every relevant configuration directive. One
> > >> > > could
> > >> > > > imagine this working at least three ways:
> > >> > >
> > >> > > I think you are making routers sound way more complicated than they
> > >> > are.
> > >> > >
> > >> > >
> > >> > > 1. 90% of directives have little to no affect.
> > >> > > (I have one toe in the routing/operations space. I'm ASN26227)
> > >> > >
> > >> > >
> > >> > > Perhaps, but they still need to be individually examined in order to
> > >> > > to determine that. Has someone done that?
> > >> > >
> > >> > >
> > >> > > 2. they are significantly less complicated than Windows, yet all
> > >> > > that media
> > >> > > based DRM stuff you mentioned is dependant upon windows boot
> > >> > > doing the
> > >> > > right thing.
> > >> > >
> > >> > >
> > >> > > But essentially none of the relevant stuff that needs to be attested to
> > >> > > is configurable (by design). You just attest to the CDM contents.
> > >> > >
> > >> > >
> > >> > > > In the former case, it is quite likely that there will be a
> > >> > large
> > >> > > > number of valid states, because each directive may have
> > >> > multiple
> > >> > > > acceptable values, and so you end up with combinatoric
> > >> > explosion
> > >> > > > issues if you just have a list of hashes [0]. In the latter
> > >> > > case we
> > >> > >
> > >> > > yet, the *routing* people with the expertise here, and a few
> > >> > > operators seem
> > >> > > pretty sure they can do this.
> > >> > >
> > >> > >
> > >> > > It's not uncommon to see people be overconfident about things
> > >> > > prior to attempting them, especially in the area of security. Has
> > >> > > someone actually gone through the exercise of examining every
> > >> > > directive and determining which ones are relevant?
> > >> > >
> > >> > > -Ekr
> > >> > >
> > >> > >
> > >> > > > Either approach requires studying the impact of every existing
> > >> > > > configuration directive for each device type to know what the
> > >> > > > impact will be on the relevant policy claims. This seems
> > >> > > challenging
> > >> > > > at best.
> > >> > >
> > >> > > --
> > >> > > Michael Richardson <[email protected]
> > >> > > <mailto:mcr%[email protected]>> . o O ( IPv6 IøT consulting )
> > >> > > Sandelman Software Works Inc, Ottawa and Worldwide
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > _______________________________________________
> > >> > > saag mailing list -- [email protected] <mailto:[email protected]>
> > >> > > To unsubscribe send an email to [email protected]
> > >> > > <mailto:[email protected]>
> > >> > >
> > >> >
> > >
> > >> --
> > >> nasr mailing list -- [email protected]
> > >> To unsubscribe send an email to [email protected]
> > >
> > >
> > >--
> > >---
> > >[email protected]
> > >
> > >--
> > >nasr mailing list -- [email protected]
> > >To unsubscribe send an email to [email protected]
> >
> > _______________________________________________
> > saag mailing list -- [email protected]
> > To unsubscribe send an email to [email protected]
> >
>
>
> --
> Astra mortemque praestare gradatim
--
---
[email protected]
_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]