On 26-Apr-22 19:02, Peter van der Stok wrote:
HI,
To add to the discussion, below the text that I adapted for Graps discovery in
contrsined-join-proxy draft.
Comments are welcome, Corrections are encouraged.
Are you intending to define a new GRASP objective "AN_REGISTRAR"? If so, you must be
consistent (you have "AN_registrar" elsewhere) and you need an entry in IANA
Considerations.
Or are you just extending "AN_join_registrar" as defined in RFC8995? That
seems easier.
Same points for "AN_JOIN_PROXY" (RFC8995 defines "AN_Proxy").
I think that each place you have "the objective name is...", you mean "the objective
value is...".
Regards,
Brian
Peter
______________________________________________________________________________
6.1. Join Proxy discovers Registrar
In this section, the Join Proxy and Registrar are assumed
to
communicate via Link-Local addresses. This section describes the
discovery of the Registrar by the stateless Join Proxy. The
statefull Join Proxy discovers the Registrar as a Pledge.
6.1.2. GRASP discovery
This section is normative for uses with an ANIMA ACP. In the context
of autonomic networks, the Registrar announces itself to a stateless
Join Proxy using ACP instance of GRASP using M_FLOOD messages.
Section 4.3 of [RFC8995] discusses this in more detail. The
following changes are necessary with respect to figure 10
of
[RFC8995]: * The transport-proto is IPPROTO_UDP * the objective is
AN_REGISTRAR * the objective name is "BRSKI_RJP". The Registrar
announces itself using ACP instance of GRASP using M_FLOOD messages.
Autonomic Network Join Proxies MUST support GRASP discovery of
Registrar as described in section 4.3 of [RFC8995] . Here
is an
example M_FLOOD announcing the Registrar on example port 5685.
[M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
[["AN_registrar", 4, 255, "BRSKI_RJP"],
[O_IPv6_LOCATOR,
h'fda379a6f6ee00000200000064000001', IPPROTO_UDP,
5685]]]
Figure 5: Example of Registrar announcement message
The Registrar uses a routable address that can be used by
enrolled
constrained Join Proxies.
6.2. Pledge discovers Registrar
In this section, the Pledge and Registrar are assumed to communicate
via Link-Local addresses. This section describes the discovery of
the Registrar by the Pledge. Once the Pledge is enrolled and
functions as a stateful Join Proxy, it continues with the
same
Registrar port and address.
6.2.2. GRASP discovery
This section is normative for uses with an ANIMA ACP. In the context
of autonomic networks, the Registrar uses the DULL GRASP M_FLOOD
mechanism to announce itself. Section 4.1.1 of [RFC8995] discusses
this in more detail. The following changes are necessary with
respect to figure 10 of [RFC8995]: * The transport-proto is
IPPROTO_UDP * the objective is AN_REGISTRAR * the objective name is
"BRSKI_JP" The Registrar announces itself using ACP instance of GRASP
using M_FLOOD messages. Autonomic Network Join Proxies MUST support
GRASP discovery of Registrar as described in section 4.3 of [RFC8995]
.
Here is an example M_FLOOD announcing the Registrar at fe80::1, on
standard coaps port 5684.
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_Registrar", 4, 1, "BRSKI_JP"],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000001', IPPROTO_UDP, 5684]]]
Figure 6: Example of Registrar announcement message
6.3. Pledge discovers Join Proxy
In this section, the Pledge and Join Proxy are assumed to
communicate
via Link-Local addresses. This section describes the discovery of
the Join Proxy by the Pledge.
6.3.2. GRASP discovery
This section is normative for uses with an ANIMA ACP. In the context
of autonomic networks, the constrained Join Proxy uses the DULL GRASP
M_FLOOD mechanism to announce itself. Section 4.1.1
of [RFC8995]
discusses this in more detail. The following changes are necessary
with respect to figure 10 of [RFC8995]: * The transport-proto is
IPPROTO_UDP * the objective is AN_JOIN_PROXY * the objective name is
empty The constrained Join Proxy announces itself using ACP instance
of GRASP using M_FLOOD messages. Autonomic Network Registrars MUST
support GRASP discovery of constrained Join Proxies as described in
section 4.3 of [RFC8995] .
Here is an example M_FLOOD announcing the constrained Join Proxy at
fe80::2, on standard coaps port 5684.
[M_FLOOD, 12340815, h'fe800000000000000000000000000002', 180000,
[["AN_JOIN_PROXY", 4, 1, ""],
[O_IPv6_LOCATOR,
h'fe800000000000000000000000000002', IPPROTO_UDP, 5684]]]
Figure 7: Example of Join Proxy announcement message
________________________________________________________________________________________
Toerless Eckert schreef op 2022-04-26 02:16:
On Wed, Apr 13, 2022 at 01:19:21PM -0400, Michael Richardson wrote:
(1)
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.
I don't think this is true. As soon as EST-COAPS proliferates as an RFC,
the choice of TLS vs. COAPS becomes not only a necessity for constrained
devices, but also a preference choice by solution designers. Less code
modules etc.
Also, RFC8995 promised the COAPS solution as part of ANI (the way i see it).
I always imagined in-ceiling network switches that do full ACP but
are also gateways to IoT edge networks as a good size candidate market
example.
(2)
Separate question: Do we have a good understanding which solution
that needs the constrained proxy will use which discovery mechanism ?
I am asking because if/where there are gaps in supported discovery mechanisms,
we might be able to suggest GRASP without ACP. Which would be somewhat
of another
draft..
https://github.com/anima-wg/constrained-join-proxy/issues/17
<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?
(3)
No. The example does not need to show both. Just constrained version as a
standalone GRASP objective IMHO. I would suggest to clone the text from
RFC8995 and accordingly modify it.
> 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.
(4)
In the first place this needs to be written down.
But i'd rather like to argue it away because i think it is an unnecessary
constraining "hack".
Why have all this discovery mechanisms when they are not even used correctly.
Underspecifying the exact service(s) a Registrar offers is like announcing
"Oh, go to google for the WHATEVER services".
I don't see that implementations would get more complex, but rather
simpler if we simply are able to distinguish the different protocol options
by their service name/parameters and have proxies/clients be able to select
them.
At least thats my opening offer, lets discuss ;-) But see below.
> 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.
(5)
That "trial&error" too should be described if its here to stay. Even if just
through a reference to an appropriate section in 8995 (if its in there, not
sure).
(6)
How about cert renewal, did you folks discuss if this would ever be something
pledges would want to do through the proxy ? In the case of ACP we did
discuss this, and i thinkit's in 8994 as well. E.g.: when cert is expired, so
the enrolled device can not wield its cert for secure network access, but its
still good enough for renewal.
> 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.
(7)
I guess a compromise for (4) would be new text that leaves the decision for
how to deal with the next enrollment protocol/encoding to such a followu draft:
IF implementers of a new variant feel that all existing/deployed registrars
will and should be able to support the new protocol variant (e.g.:
brski-xmp-xyz),
then that protocol option does not need to come up with a new variation.
IF implementers feel that is not appropriate, then:
a) A new set of service names is required (brski-xmp-xyz.jp/rjp or the
like)
b) constrained proxies supporting both the new and the old will have to
effectively run separate instances for them, e.g.: each instance having
a separate UDP port number towards the pledge and using separate
service names from registrar and to proxy.
> 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
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.
No opinion. Sounds like the easiest solution, unless you do want some
way to support 6TISCH ?
> 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 ?
Because, we defined the proxy to have a standard interface.
What does that mean ? Do all proxies need to support both modes, or
is there only the requirement for one mode, but some undefined entity has to
figue out what registrar/proxies in some network should decide to use ?
(Except for CoAP/OSCORE vs CoAPS above)
OSCORE = ?
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.
Cheers
Toerless
--
] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | network architect [
> ] m...@sandelman.ca <mailto:m...@sandelman.ca> http://www.sandelman.ca/ <http://www.sandelman.ca/> |
ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca <mailto:mcr+i...@sandelman.ca>>,
Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
Anima mailing list
Anima@ietf.org <mailto:Anima@ietf.org>
https://www.ietf.org/mailman/listinfo/anima
<https://www.ietf.org/mailman/listinfo/anima>
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
