Peter, Michael *:
Wrt to seervice discovery in general: I am happy to help with the text,
but lets first agree on the functionality.
Here is what i think, please reject points if you have arguments against them,
otherwise i'd assume you agree ;-):
1. "AN_join_registrar" and "AN_Proxy" where defined in RFC8995 for use with ANI.
To me that means those objectives indicate that by default those objectives
will provide ANI/ACP certificates.
2. There is no need to introduce new objective values just because we use a new
protocol (EST-coaps instead of EST-tls). Instead, that should be done via
the objective-value. RFC8995 already nicely uses "EST-TLS" for
"AN_join_registrar".
I have no idea why we did not also do this for "AN_Proxy", but we just left it
blank there. But we can easily assume that Empty ("" as in the RFC8995 example)
is the same as "EST-TLS".
3. I think the GRASP announcements MUST indicate what mode the Registrar
supports. Stateful or stateless. Or if it supports both, then just have
GRASP announcements for both and let the Proxy pick.
4. I think by using explicit objective-values to indicate the protocol we are
also future proof when we come up with even more protocols like CMP or the like.
5. The constrained proxy draft describes three discovery options:
(a) Proxy Discovers Registrar
(b) Pledge discovers Proxy
(c) Pledge discovers Registrar.
In ANI/ACP, we do not have case (c). I do not see how it could ever happen,
so we should not introduce it.
6. To me, this means the ANI/ACP service discovery for use with constrained
proxy are:
Proxy Discovers Registrar:
objective-name: "AN_join_registrar", protocol UDP, objective-value:
"EST-COAPS"
objective-name: "AN_join_registrar", protocol UDP, objective-value:
"EST-COAPS-JPY"
Pledge Discovers Proxy:
objective-name: "AN_Proxy", protocol UDP, objective-value: "EST-COAPS"
EST-COAPS-JPY is stateless with JPY header. EST-COAPS is stateful. There is
no
need for the AN_Proxy objective to distinguish here, because to the Pledge,
it does not matter how the Proxy talks to the Registrar.
7. Until there is sufficient proof of the opposite, i will claim that multihop
ASM IP Multicast in support of admin-scope COAP group communication via
ff05::fd
will not exist in the mayority of target deployments of constrained proxy.
And this can simply render constrained BRSKI to become undeployable. So its
IMHO
not to be taken lightly.
Therefore i think it is very prudent to also explicitly define how to use
GRASP
outside of ANI/ACP context as an option. We still have to close the gap of
suggesting/
writing down an easy draft how to do GRASP just via DTLS, but should be IMHO
similarily simple as Brians draft-carpenter-anima-quads-grasp (i just
wouldn't want
to invent new crypto when we already have DTLS as a dependency for
constrained BRSKI anyhow.
And a small GRASP daemon using the same DTLS as BRSKI is equally simple to
develop
(i claim) as a proxy daemon. Certainly a completely different ballpark than
trying to get network layer IP multicast even if it's RPL MPL (not under
the same
control in most platforms as the BRSKI code..).
9. In result, i would suggest:
1) Pledge (or Proxy) Discovers Registrar:
objective-name: "brski-rjp", protocol UDP, objective-value: "EST-COAPS"
2) Proxy Discovers Registrar (stateless):
objective-name: "brksi-rjp", protocol UDP, objective-value:
"EST-COAPS-JPY"
3) Pledge Discovers Proxy:
objective-name: "brski-jp", protocol UDP, objective-value: "EST-COAPS"
Logic for Pledge is simple: If it can discover a registrar via
"brski-rjp"/"EST-COAPS",
then it uses that. Else it has to look for "brski-jp"/"EST-COAPS"
10. IMHO, the text for 1) should be in constrained voucher, not constrained
proxy,
because this is the option that can work without any brski proxy in
networks where
discovery works across multiple hops. No need for this to depend on proxy.
Only 2) and 3) are specific to proxy. This would make constrained voucher
more logically
standalone.
11. For use with DNS-SD, we would encode the same parameters as in 9. according
to
how we do things in DNS-SD:
1) Proxy or Pledge Discovers Registrar:
service-name: "brski-rjp", protocol UDP, TXT key: proto=EST-COAPS
2) Proxy Discovers Registrar (stateless):
objective-name: "brksi-rjp", protocol UDP, TXT key: proto=EST-COAPS-JPY
3) Pledge Discovers Proxy:
objective-name: "brski-jp", protocol UDP, TXT key: proto=EST-COAPS
Cheers
Toerless
On Tue, Apr 26, 2022 at 09:02:51AM +0200, 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.
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,
Please replace with:
6.1.2 ANI/GRASP discovery
This section is normative for the use with Autonomous Network
Infrastructures (ANI) based on an Autonomous Control Plane (ACP,
[RFC8994])
the Registrar announces itself to a stateless
NIT: s/In the context of autonomic networks, /When it is used, /
Aka: we don't need a full autonomic network, just ACP with (constrained)
BRSKI. We call this ANI, but i don't think we need to introduce the term
ANI here (surplus).
Join Proxy using ACP instance of GRASP using M_FLOOD messages.
Q: I am unclear right now why the draft claims it does not need discovery
for the Registrar when the Proxy is stateful. This is a question i have
independent of use of ACP. I think the constrained Jon Proxies always need
to be able to discover the Registrar. And i wouldn't know how the Proxy
would know whether it can talk stateful or stateless with the Registrar
unless the Registrar would announce what mode it supports (or this is
implied by the service name).
Section 4.3 of [RFC8995] discusses this in more detail. The
following changes are necessary with respect to figure 10 of
[RFC8995]:
Not figure 10. The formal definition is in Figure 13, the example is in
Figure 12.
[RFC8995]: * The transport-proto is IPPROTO_UDP
Maybe add: instead of IPPROTO_UDP for BRSKI,
* the objective is AN_REGISTRAR
The objective name should IMHO stay unchanged "AN_registrar" as it is
defined for RFC8995, but the draft would claim to be updating RFC8995
by introducing additional objective-values ("BRSKI_RJP"...).
* the objective name is "BRSKI_RJP".
I am personally actually not very happy with those brski.* URL names.
It would be nice if those names would be consistent across discoveries,
but technically there is no need. So let me propose the names i
would prefer:
"EST-COAP-DTLS"
"EST-COAP-DTLS-SL"
Reason: The RFC8995 name was not "BRSKI", but "EST-TLS". The logical
equivalent is therefore "EST-COAP-DTLS". This would be for the stateful
proxy. For the stateless proxy option, we add "-SL".
(Brian was pointing out the objective value could be a structure, but
i think there is simplicity in a simple list of numeric/string
objective-values
Afaik, TLS itself also uses that simple approach of enumeration to select
the crypto option to pick between initiator and responder. )
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] .
I would just write that ... "The Registrar performs announcements
as described in RFC8995, section 4.3 except for the new objective-values
and resulting use of IPPROTO_UDP in the locator option.
Here is an
example M_FLOOD announcing the Registrar on example port 5685.
[M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
[["AN_registrar", 4, 255, "EST-COAP-DTLS-SL"],
^^^^^^^^^^^^^^^^^^
[O_IPv6_LOCATOR,
h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5685]]]
Figure 5: Example of stateless Registrar GRASP message
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[M_FLOOD, 51804321, h'fda379a6f6ee00000200000064000001', 180000,
[["AN_registrar", 4, 255, "EST-COAP-DTLS"],
^^^^^^^^^^^^^^^
[O_IPv6_LOCATOR,
h'fda379a6f6ee00000200000064000001', IPPROTO_UDP, 5686]]]
Figure 5: Example of stateful Registrar GRASP message
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Aka: simply provide both announcement examples if thats what we agree upon.
The Registrar uses a routable address that can be used by enrolled
s/address that/address (fda3:79a6:f6ee:0000:0200:0000:6400:0001 in the example)
that/
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
remove autonomic networks (as note above)
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]
.
As for the Registrar announcements i would suggest:
- Objective name stays unchanged, "AN_Proxy"
- Ideally, the same new objective-value is used as for the registrar:
"EST-COAP-DTLS"
... and we would not need to distinguish between "EST-COAP-DTLS" and
"EST-COAP-DTLS-SL", because there should be no difference for the Pledge.
... except that for that to be true we would need to agree on the same
time for state maintenance / expiry for stateful/stateless proxies. Which
is an open discuss IMHO. E.g.: one of the benefits of the stateless proxy is
that the Registrar could keep registration state much longer than a stateful
proxy might want to do. In this case, "EST-COAP-DTLS" for just the stateful
proxy would be an indicator to send state-refresh messages (i hope they do
exist on COAP as in HTTP) much more often).
Here is an example M_FLOOD announcing the Registrar at fe80::1, on
standard coaps port 5684.
[M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000,
[["AN_Proxy", 4, 1, "EST-COAP-DTLS"]
[O_IPv6_LOCATOR1G,
h'fe800000000000000000000000000001', IPPROTO_UDP, 5684s]]
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
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 http://www.sandelman.ca/ | ruby
on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
