Support for other discovery protocols than GRASP? Or non-ACP usages?

[EskoDijk]

For the Join Proxy, BRSKI-AE refers to Section 4 of RFC 8995. This section says:

This section is normative for uses with an ANIMA ACP. The use of the GRASP mechanism is part of the ACP. Other users of BRSKI will need to define an equivalent proxy mechanism and an equivalent mechanism to configure the proxy.

So it narrows the context down to only GRASP, and only for an ANIMA ACP. Is BRSKI-AE also targeting the same narrow scope? If the scope is wider it would need to define the discovery mechanism(s) for the Join Proxy, explicitly.

It could re-use GRASP for example for a non-ACP context, but in that case it would still need to explicitly define this other context and say that/how GRASP is re-used. For other protocol use, like mDNS or DNS-SD, a detailed definition would be needed following the quoted RFC 8995 paragraph.

[EskoDijk]

FYI @DDvO

[DDvO]

FYI @DDvO

Since this is not my area of expertise, I asked @stfries to respond.

[stfries]

To Esko's question. No I don't think that BRSKI-AE is only targeting a specific environment in general. In its current state it is certainly more suitable for engineered environments based on the discovery discussion we have. If we rely on the best effort approach for the first step, then it is fine.

In conjunction with Toreless' proposed discovery draft, would it be workable in both cases, the registrar discovery and the Join Proxy discovery likewise for ANIMA ACP? The part on Join Proxy Discovery is already part of it also considering specific parameters.

That said, I would not see a value to specify parts of it now in BRSKI-AE directly, when the intention is to have a more versatile discovery, which can be combined with different BRSKI variants later on.

[EskoDijk]

Agree that BRSKI-AE should be applicable to a wider scope than just "ACP". We could assume the present scope is "engineered environments" and that we re-use the 8995 discovery solution. What I see then is that this scope is already larger/different than the 8995 scope of "ACP" for which GRASP use was defined. For example, I could have an engineered environment that is not an ACP. As background: RFC 8994 defines the ACP in more detail; basically it's the control plane part that's automatically formed by a bunch of IP routers and there is also a separate data plane that is used for the application traffic.

In IoT systems like building control, the IoT devices may need to bootstrap not on an ACP -- but on the regular data plane. This would be the most typical case, where only the routers/switches can be on the ACP and not the sensors/actuators.

So it's not immediately obvious that 8995 GRASP use can be directly used in non-ACP use cases like building control, because 8995 seemingly defines and restricts GRASP use to the ACP case. Not 100% sure if GRASP can be readily "ported" to non-ACP cases or whether there's some hidden dangers there. E.g. GRASP requires a security definition if used beyond ACP context, see https://datatracker.ietf.org/doc/html/rfc8990#section-2.5.1.

At least this would require in BRSKI-AE a sentence saying "We hereby define GRASP can be used for new use context X, and security is provided by solution Y" and some text explaining what X and Y are.

Or simpler, we could say in a paragraph we intend to use GRASP and/or other solutions (mDNS?) to be used for our new use context X (beyond ACP) and defer details to the discovery draft. (In case GRASP is used in the ACP context, we can rely on existing 8995/8990 definitions so that case should be already covered.)

So that's why I opened this issue - to clarify the scope and get some text to make this clear in the draft.

[stfries]

We uploaded an updated version of BRSKI-AE, which explicitly takes the new work on discovery into account. Specifically section 4.2.1 now addresses the engineered environment directly and refers to enhancements to the new discovery draft. The section is described more generally with respect to discovery and does not flesh out a specific approach. Therefore we understood GRASP covered. Do you see it necessary to refer to GRASP explicitly? I would like to be less specific here as we also do not mention other approaches for non-ACP environments. So the intention was to stay agnostic regarding enhanced approaches and rather refer to the new draft..

[DDvO]

Hi @EskoDijk, we just came across this issue, where Steffen provided an answer and we believe that this has.been solved meanwhile. Can it be closed now? If so, I'd ask you to do that.

[EskoDijk]

I think we still need to clarify a few things! Looking at this text:

Perform discovery as defined in BRSKI [RFC8995], Section 4, but using the service name "brski-registrar-cmp" instead of "brski-registrar"

Maybe "Section 4" was referring to Section 4.3 specifically? -> Registrar discovery. The problem is that Section 4 / 4.3 doesn't mention the service name "brski-registrar" because it's about GRASP discovery and that uses other names, not DNS-SD service names. So maybe it was intended to refer to the mDNS/DNS-SD discovery of RFC 8995 instead? That seems ok to me.

So if that's right then just refer to Appendix B of RFC 8995 and Section 8.6 for the discovery, and say that mDNS/DNS-SD discovery can be used with a query for service types "_brski-registrar-cmp._tcp.local.", to find a CMP registrar.

If we do this then the GRASP scope issue that this issue was about, goes away - we just don't say anything about GRASP or how it could / could not be used for BRSKI-AE and defer that to later.

[stfries]

Good catch! Yes, the intention was to refer to the mDNS/DNS-SD discovery in Appendix B of RFC 8995. This needs to be corrected.

[DDvO]

Thank you Esko and Steffen for reacting.

@stfries could you please do the needed adaptations?

[stfries]

Done in commit for md file only. @DDvO, please check if the other files need to be generated as well.

[DDvO]

Thanks @stfries. I've tweaked the way the references are presented and also generated the PDF etc. files.

@EskoDijk, anything more to do on this issue?

[EskoDijk]

@DDvO Nothing more, I'll close it now. Thanks