Re: [Anima] Discovery of proxy/registrar insufficient (GRASP and more).

On 13-Apr-22 03:00, Toerless Eckert wrote:
> Note: I am writing this as a problem against only the join-proxy draft, but i think
> there may also be text affected in constrained-voucher. I just have not checked
> specifically which text.
> 
> draft-ietf-anima-constrained-join-proxy:
> 
> 1. GRASP discovery
> 
> 514     6.1.2.  GRASP discovery
> 
> 516        This section is normative for uses with an ANIMA ACP.  In the context
>                                                                 ^ ... according to RFC8994
> 
> 517        of autonomic networks, the Join Proxy uses the DULL GRASP M_FLOOD
> 518        mechanism to announce itself.  Section 4.1.1 of [RFC8995] discusses
> 519        this in more detail.  The Registrar announces itself using ACP
> 520        instance of GRASP using M_FLOOD messages.  Autonomic Network Join
> 521        Proxies MUST support GRASP discovery of Registrar as described in
> 522        section 4.3 of [RFC8995].
> 
> This is insufficient. Section 4.3 only describes the GRASP objective for
> EST-TLS, which uses the objective-value "EST-TLS". For the constrained join proxy,
> you need to specify the objective to use a new appropriate objective. For
> example, you could specify to continue to use AN_join_registrar, but use an
> objective-value of "EST-COAPS". That would IMHO be in the spirit of how we
> defined the RFC8995 GRASP objective. And astoundingly (;-)) it wouldn't require
> a new IANA registration (i think, Brian ?).

If RFC8990 has a weakness, it is indeed that only the initial registration
of a GRASP objective requires a specification and expert review. Personally
I think this is a good thing, since it allows for flexible extensibility.
Since the designated expert is Michael Richardson, he might have an opinion.

I agree that if extra values of the objective are needed, they should
be specified, and making that an Updates: 8995 seems appropriate.

> 
> Likewise, draft-ietf-anima-constrained-join-proxy needs to specify the Objective
> for Pledges to use for sectin 6.2.2. Section 4.1.1 of RFC8995 specifies astoundingly an empty
> objective-value instead of the logical "EST-TLS". I think this may be the same
> type of oversight as discussed below. I would suggest to also use "EST-COAPS".
> 
> Note that it is not sufficient to delta RFC8995 and mention "EST-COAPS", because
> the GRASP objective also needs to indicate UDP instead of TCP. Even though it
> is longer, it would IMHO be prudent to copy the whole GRASP objectives and
> examples from RFC8995 and accordingly modify them, so that the constrained-proxy
> draft is "standalone" in this respect (even if a page longer).

But it must still be Updates: 8995 if it extends the details of the objective.
(Regrettably, the proposed "Extends:" tag is still only an I-D.)

> 
> (but before finishing, see below for point 4.)
> 
> 2. Other (primarily CoAP) discoveries
> 
> Isn't there the thought that some other variations of BRSKI will use protocol
> variations, such as not CBOR+JSON ? some other "CMP" encoding ?
> 
> I am asking, because it seems to me we need to be aware, that the constrained-proxy
> is logically "just" a DTLS proxy, but once we have more than one DTLS BRSKI
> variation, we still need to be able for pledges to connect to registrar(s) that
> talk the BRSKI variation that the pledge supports. What we define here initially
> is effectively proxy/registrar for EST-COAPS. So let's assume, we get another
> protocol, OTHER1-DTLS. The constrained proxy continues to work, but it would now
> need to discover the OTHER1-DTLS Registrar, allocate a new UDP port number on
> which to offer proxy services for OTHER1-DTLS and announce that to pledges.
> 
> I fail to find appropriate text to that (extensibility) extend in the draft.
> 
> I wonder if the names choosen for est-coaps discovery, brski.jp and brski.rjp are
> ideal indicative of the fact that we're rather defining brski-est-coaps.jp and
> brski-est-coaps.rjp. I guess beauty/explicitness may need to take second place
> over encoding efficiency, but lets make sure that the draft text as well as
> the registration texts with IANA are as explicit as we can make them.
> 
> 3. 6tisch discovery
> 
> [I-D.ietf-6tisch-enrollment-enhanced-beacon] is now RFC9032, please update draft
> accordingly.
> 
> Upon quick browse of RFC9032 i fail to see how/where RFC9032 would be able to
> deal with more than one discovery protocol. E.g.: How would we discover
>     BRSKI-EST-COAPS-REGISTRAR
>     BRSKI-EST-COAPS-PROXY
>     OTHER1-DTLS-REGISTRAR
>     OTHER1-DTLS-PROXY
> 
> ?
> 
> 4. Stateful vs. stateless proxy discovery
> 
> How do i know as a customer of equipment know that all my pledges/proxies/registrars
> will interoperate in the face of those devices seemingly being able to freely
> pick stateful and/or stateless mode of operations ?
> 
> Given how none of the discovery methods so far includes a specification of the
> supported mode(s) of a proxy/registrar, i guess we will end up with only very
> limited solutions where even two vendors can pick different preferences (ony
> stateful, thre other stateless), and we end up with non-interoperable-by-vendor
> networks ?
> 
> First of all, whatever the desire of the authors is, it should be written more
> explicitly in the document. "Interoperability considerations" or the like.
> 
> Secondly, i would very much like to see discovery methods to indicate whether
> stateful and/or stateless are supported.
> 
> For example, with GRASP, it would of course be easy to indicate:
>     EST-COAPS-STATEFUL
>     EST-COAPS-STATELESS
> 
> This would require two separate GRASP objectives if a Registrar/Proxy supports both,
> but would be the most easy solution.

Alternatively add options to the objective value. The value can be whatever we want,
as long as we can say it in CBOR and make sure that the RFC8995 definition is a proper subset.

     Brian

> 
> Similarily, i guess we could have equal variations of the names for other discovery
> mechanisms.
> 
> Cheers
>      Toerless
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 