Subject: [Ace] DTLS proxy in EST-coaps

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Nov 2017 20:16:35 -0500

Hi,

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.

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.

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

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

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

---

From: peter van der Stok <[email-masked]>
Date: Fri, 17 Nov 2017 03:09:35 +0100

> might run over DTLS, use EDHOC w/OSCORE, or some DTLS-over-CoAP 

Good
> Registrar does not have to live (entirely) in the constrained network.

If this is a unrealistic use case, it should go from the document.
> 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).
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Sandeep Kumar <[email-masked]>
Date: Fri, 17 Nov 2017 07:48:52 +0000

DTLS relaying draft was in DICE wg. The WG was not chartered for the activity. Other SDOs picked it up and filed the gaps.

Sandeep
________________________________
From: Ace <[email-masked]> on behalf of peter van der Stok <[email-masked]>
Sent: Friday, November 17, 2017 3:09:35 AM
To: Michael Richardson
Cc: [email-masked]
Subject: Re: [Ace] DTLS proxy in EST-coaps

Good

________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Nov 2017 08:49:36 -0500

peter van der Stok <[email-masked]> wrote:
    >> 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.

I don't think that it was est-coaps.
I think it was maybe 2 years ago, there were some proposals to proxy DTLS in
a stateless way.

I was sure at the time that a solution on top of CoAP would be better, so I
didn't pay a lot of attention.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Nov 2017 09:11:52 -0500

Sandeep Kumar <[email-masked]> wrote:
    > DTLS relaying draft was in DICE wg. The WG was not chartered for the
    > activity. Other SDOs picked it up and filed the gaps.

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

I was reminded in a private email that the document I wanted was yours:
  https://tools.ietf.org/html/draft-kumar-dice-dtls-relay-02

but it does not detail what the DRY header would look like.

I assume it has to fit into DTLS clothing so that it can be demux'ed.
I was hoping that your document had already figured that part out.
Perhaps you have some thinking you can share?

Which SDOs picked up the gap, and where are the documents?
Were there IANA allocations required?

---

From: Sandeep Kumar <[email-masked]>
Date: Mon, 20 Nov 2017 07:48:57 +0000

Thread uses DTLS relay as a building block for bootstrapping. The DRY was solved with Thread specific messaging. You can find some details in their public whitepapers.

-----Original Message-----
From: Michael Richardson [mailto:[email-masked]]
Sent: Friday, November 17, 2017 3:12 PM
To: Sandeep Kumar <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Ace] DTLS proxy in EST-coaps

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