On Mon, May 02, 2022 at 01:22:33PM -0400, Michael Richardson wrote:
> I am saying that the existing GRASP M_FLOOD specified in RFC8995,
>
> and I'm saying that we'd have:
> $transport-proto /= IPPROTO_UDP ; ...
Agreed.
> GRASP DULL is easy.
> In some sense, for IoT networks, there is *only* the ACP :-)
Indeed. But it seems if we want to see constrained BRSKI to get deployed, we
need to worry about the most likely deployable/implementable multi-hop
discovery of Registrar by Proxies, and i don't think ASM IP Multicast as
required
for FF05::FD is very likely not it.
a) hop-by-hop GRASP as in ACP, just without ACP and over DTLS instead of over
TCP/TLS
is one option.
b) Coap discovery hop-by-hop proxying is probably the other option
Either one would need to be defined, likely in a separate document.
For a) its easy for me to write it down. For b) i am not even 100% sure
how to do it, have to dig. Should be less code ultimately though...
> >> 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".
>
> No, that's not at all what we said.
Registrars need to discoverable anyhow for their IP address. ANd
every announcement does include a UDP port number anyhow. And
expecting that all stateful registrars operations can always be
runniing over the default coap port is contradicting the
purpose of discovery and should fail any reasonable INT IESG review IMHO.
Besides, i do not believe that all code on all target devices will
always share a single coap stack. It would be bad if constrained
brski would only work well on those most constrained devices where you
MUST use a single coap stack for code-size reasons, but will not
work on larger devices where every app easily integrates its own
coap stack and therefore has its own sockets for it.
> > 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.
>
> I think that we did exactly this.
Will only work if registrars can announce which port runs brski with est-coaps
and
which port runs brski with est-coap-jpy.
> > 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
>
> Nope, never. Just like in BRSKI.
How many readers will understand what gaps there are for automatic
lifecycle maintenance of the certificate when its not written in the
document ? I am not aware that there is a plan for an rfc8994 type
document to outsource such text to, and it's IMO easy to fix.
IMHO suggested text:
Registrars discovered for BRSKI MAY also be used by enrolled devices
for certificate/key renewal using the enrolled certificate.
Thoughts ?
> > 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.
>
> You can bikeshed the names. I don't really care.
Nonono ;-) You (constrained) folks bikeshed' the names by introducing brki-jp
and brki-rjp
instead of just reusing brki-registrar and brski-proxy from RFC8995. To save 3
or 6 bytes.
I only care about distinguishing the names for different protocol versions so i
get
automatically working registrar and port selection tht will be interoperavble
without expecting a superset-of-all-protocols implementation on a registrars.
> > 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 ?
>
> What does "what does that mean"? I wrote an explanation, that I don't think
> you read.
See my open questions above.
> The "standard" interface from a join proxy to the pledge (if it's DTLS) is to
> use CoAP over DTLS, on the port given. The details of how it gets back to
> the Registrar is irrelevant to the pledge.
Right - miscommunication - i was only worried about the pledge knowing which
port a registrar
supports statefull and/or stateless. The pledge doesn't see a difference.
> (If it's TLS, then it's RFC8995.
> (If it's OSCORE/EDHOC, then it's TBD)
> >> (Except for CoAP/OSCORE vs CoAPS above)
> > OSCORE = ?
> OSCORE. RFC8613.
Yepp, thanks. found it just a tad in before ;-)
I think it would be useful to have a sentence for marketing somehwere in the
constrained
proxy document saying how this proxy is easily reuseable for any future
enrolment
protocol variations (for example using the fictional EST-COAP-OSCORE as an
example):
the whole stateful/stateless operation stays the same, only the service-names
for
discovery would need to be reinvented. And of course big proxies could run all
those
protocols in parallel.
Cheers
Toerless
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
