Esko Dijk <[email protected]> wrote: >> > 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.
So how does the joining node know the link-layer encryption key?
(I understand the proxy->6LBR hop is encrypted)
>> > 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.
So "each" end sends the packets to each other?
Does the 6LBR post to the join proxy, who posts to the pledge?
> 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.
Got it.
>> > 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...
Agreed.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
