Hello,
Esko Dijk<[email protected]> 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: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
