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

[Esko Dijk <[e-mail]>]

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: [e-mail] | +31 6 
2385 8339