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 ?).
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 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.
Similarily, i guess we could have equal variations of the names for other
discovery
mechanisms.
Cheers
Toerless
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
