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

From: Toerless Eckert <[email-masked]>
Date: Tue, 12 Apr 2022 17:00:19 +0200

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Apr 2022 08:45:39 +1200

> 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.

> 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 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

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 13 Apr 2022 07:28:28 +0200

Thanks Brian, inline

> Since the designated expert is Michael Richardson, he might have an opinion.

Right.

> be specified, and making that an Updates: 8995 seems appropriate.

I was wondering about that. So the logic is that the objective name is
indeed IANA registered that points to rfc8995, and we amend that objective
with new options. 

Could/should we be able to indicate in the IANA objective registry the new
proxy RFC or is that only taken care of by the Update flag/tracking ?

> (Regrettably, the proposed "Extends:" tag is still only an I-D.)

Right. Binary flag doesn't allow too many values ;-)

> as long as we can say it in CBOR and make sure that the RFC8995 definition is a proper subset.

Let me expand on that in a separate answer

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Apr 2022 13:19:21 -0400

Toerless Eckert <[email-masked]> wrote:
    > 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 ?).

Yes, you are right, we need to have a new objective to announce.
I guess that we don't really think about the constrained-join-proxy really
being used in an ACP context, but we really should that right.

https://github.com/anima-wg/constrained-join-proxy/issues/17

    > 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).

I think you are asking us to show an example that advertises both RFC8995,
and the constrained version, correct?

    > Isn't there the thought that some other variations of BRSKI will use
    > protocol variations, such as not CBOR+JSON ? some other "CMP" encoding
    > ?

We decided that Registrars will be responsible for interoperation, and will
support all protocols the operator expects to use.   If you buy a Registrar
that does not do X and a pledge that only does X, then it fails, and you were
stupid.

    > 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.

You aren't wrong, but you also aren't right.
Pledges are expected to try all options (possibly concurrently if they have
CPU/ram) until they find one that works.    There is no reason the join proxy
needs to know the details of the Registrar supports, only that they support a
way to talk to it.

    > 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

Fair point.

    > [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

Yes, are you right.
RFC9032 does not support DTLS at all.
It supports RFC9031 only.
Perhaps we should simply indicate that we don't support 6TISCH.

    > 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 ?

Because, we defined the proxy to have a standard interface.
(Except for CoAP/OSCORE vs CoAPS above)

How the join proxy keeps state (in memory or in the network) is a private
matter between the JP and the Registrar, and does not concern the pledge.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-