[Anima] Re: Re-using the constrained Join Proxy solution defined by Thread

[Esko Dijk <[e-mail]>]

Hello,

> Esko Dijk<esko.dijk=[e-mail]> wrote:
>      > that actually specifies the key elements in the form of code. Whatever we can
>      > learn from this code is public knowledge, so it's the easiest way to
>      > kickstart this discussion.
>
> Yes, but unfortunately the code can contain software patents :-(
That's no problem at all if you want to look at the code or even compile 
it and use in your prototypes. Only when the code would be commercially 
/ industrially used (in products or services) then patents can become 
relevant.
(Says the guy who worked on patents for many years and did patent 
courses, but who's not a lawyer (un?)fortunately :-) )

>      > 1. Relay of DTLS (or any other protocol over UDP) packets happens in the
>      > payload of unsecured coap:// messages sent to the "Border Agent" (located on
>      > a Border Router i.e. 6LBR).
>
>      > 2. Relay messages are secured by link-layer encryption just like all other
>      > traffic in a Thread mesh network.
>
> I'm confused here.
> I know that Thread does network-layer onboarding via the Commissioner.
> (And that there can be application layer onboarding too)
> I want to be sure I understand if the 6LBR is the Join Proxy?

The Join Proxy (aka Joiner Router) can be any device in the mesh i.e. 
the link-local neighbor of the Pledge (aka Joiner) with the required 
relay capabilities.  It's not a "sleepy device", but a sufficiently 
capable always-on device.
The final target of the CoAP relay message is the 6LBR (aka Border 
Agent). From there, it's relayed further in another way (tunneled) to 
the Commissioner, which I didn't discuss yet in my email.

>      > 3. UDP destination port of the CoAP relay messages is 61631.
>      > 4. URI path of the CoAP relay messages are fixed at "/c/rx" and "/c/tx" - one
>      > for each direction.
>
> Do clients then "poll" or "observe" on /c/tx?
No, it's only POST request if a UDP datagram becomes available to send 
to the other side. Both sides act as CoAP client as well as CoAP server 
to do this.

>      > 5. Relay messages contain the state - i.e. it's stateless on the Join Proxy -
>      > encoded as TLVs, not encrypted.
>
>      > 6. There are TLVs for the source port of the joining device, the link-local
>      > address IID of the joining device, the identity ("RLOC16") of the Join Proxy
>      > itself, and finally the DTLS payload being relayed.
>
>      > 7. Relay messages are sent to an IPv6 destination address of the "Border
>      > Agent" that's based on configured network-wide data.
>
> I am having difficulty with these three points.
> These are TLVs in the CoAP? Or is there another layer of TLV?
The TLVs are the payload of the CoAP request message. The format of TLVs 
is fully Thread-specific; not standardized by CoAP in any way.

>      > - JPY message can't be sent outside of the bounds of the single mesh network
>
> Why can't we sent them further?
You could send them further, however because the CoAP message payload 
(the TLVs) travels unprotected, it would mean that anyone can 
potentially observe it and/or modify it when the data gets on the 
Ethernet infrastructure network or on the Internet (if it would be sent 
there).  That's why I just say it can't be sent further; assuming the 
mesh network is still some sort of "reasonably safe" environment with 
trusted nodes and link layer security.
In Thread this is solved by an additional relay mechanism to send from 
Border Agent to Commissioner using a fully secured "tunnel" (separate 
DTLS session).

>      > - it stops at the boundary (Border Agent / 6LBR). So it can't reach a
>      > Registrar directly; another relay step is needed.
>
> "it" meaning the Thread version.
Indeed, for the reasons above and maybe partly just because the design 
emerged in that way with multiple stages.

>      > Some of these aspects could make it difficult to pass an IESG review, I
>      > think!
>      > Any improvement suggestions from review also can't be applied, because that
>      > would lose backward-compatibility with the Thread-defined solution.
>      > Overall I'm not sure how we could successfully proceed with the Thread
>      > relaying solution in IETF.
>
> okay, so you think it's not a good idea.
> I agree.

Not a good idea it would seem, in IETF context.  What's still possible 
is to describe the Thread mechanism as informational RFC which has been 
done in the past for certain third-party protocols.
And then we could decide to drop the Constrained Join Proxy draft. But 
this would not provide a solution that's directly usable for the cBRSKI 
case...

Esko

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339