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 :-(
> Some key elements to learn from the code are:
Thank you for the summary.
> 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?
> 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?
> 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?
> These differ from the constrained Join Proxy draft in the following ways:
> 1. No CoAP is used, but rather the "JPY protocol" - optimized to be as
> compact as possible. E.g. JPY doesn't need URI paths.
> 2. (Same - JPY messages in a mesh network would also be link-layer
secured)
> 3. UDP destination port for JPY messages can be discovered (using CoAP) or
> configured (by some out of scope means) but is not a fixed value.
> 4. JPY message avoids using URI paths - not CoAP.
> 5. Relay messages contain the state in encrypted form in CBOR.
> 6. Similar data in the JPY message: source port of Joiner, link-local
address
> IID of Joiner, DTLS payload; encoded in CBOR.
> 7. Relay messages are sent to discovered or configured address of the
> Registrar. If configured, it may be based on network-wide data.
Yes.
> - JPY message can't be sent outside of the bounds of the single mesh
network
Why can't we sent them further?
> - 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.
> 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.
--
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]
