I'm slowly absorbing the contents of draft-vanderstok-ace-coap-est-02.
I'm building draft-ietf-6tisch-zerotouch-join with the assumption that it might run over DTLS, use EDHOC w/OSCORE, or some DTLS-over-CoAP mechanism.

Good

I looked through section 6, and I don't understand why COAPS would be used
From the Registrar through an ESTcoaps-to-HTTPS Proxy to the MASA. The
Registrar as not in the constrained networks, and can speak HTTPS just fine.
That's why we proxy the COAPS traffic to the Registrar, so that the
Registrar does not have to live (entirely) in the constrained network.

If this is a unrealistic use case, it should go from the document.

So, in the ANIMA BRSKI context, we have the Join Proxy to connect the insecure (unencrypted) network with the JRC as we can not assume the registar (JRC) is
within radio distance of all pledges.

For EDHOC and DTLS-over-COAP, we can use the option as described
in draft-ietf-6tisch-minimal-security section 5.1 to keep the proxy
stateless.

For DTLS, I thought we had a few IDs on how to relay DTLS in a stateless manner.
I can't seem to find any (Yes, I did look through expired drafts too).

You mean expired est-coaps drafts?
Indeed, the draft never considered these, assuming they were off topic and were adequately treated elsewhere. The next version of est-coaps draft will be less BRSKI oriented and I think the subject of stateless join proxy is off topic. (BTW they are systematically called "circuit proxy" in keyinfra draft).

Are there some options for DTLS?
Is there a way to statelessly (on the join proxy) relay traffic?

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




_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace

Reply via email to