Hi all,
During the IETF 124 ANIMA session we discussed whether it's possible to
re-use the existing constrained Join Proxy solution defined by Thread
(wireless 6LoWPAN mesh networking protocol). A comparison between the
Thread solution and the ANIMA defined solution in
draft-ietf-anima-constrained-join-proxy was not immediately possible
because the Thread solution is not publicly described.
Nevertheless, there's an open source implementation (OpenThread) on
Github 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.
Key part of the code for the "Join Proxy" called Joiner Router is here:
https://github.com/openthread/openthread/blob/9a10e22e91405f585144a175da1bdd7dd093b3c6/src/core/meshcop/joiner_router.cpp#L117-L194
Also there's an autogenerated Wiki based on the code available here:
https://deepwiki.com/search/document-the-meshcop-relay-mec_dd034288-5723-41d6-ba7e-4b19e9654457?mode=fast
The wiki explains more and also includes a diagram.
Some key elements to learn from the code are:
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.
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.
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.
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.
Re-using Thread relaying for an IETF spec would have a few important
implications:
- Use the CoAP protocol which we removed in constrained Join Proxy (a
while ago)
- Use fixed CoAP URI paths that are not in the ".well-known" namespace.
- Use a fixed port (61631) for CoAP
- No encryption for the JPY message - transmitted plain and modifyable
within the mesh network
- JPY message can't be sent outside of the bounds of the single mesh
network - it stops at the boundary (Border Agent / 6LBR). So it can't
reach a Registrar directly; another relay step is needed.
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.
best regards
Esko
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
