Since the Join Proxy is typically just a lightweight forwarder of DTLS packets to/from the Registrar, it may not always have a way to authenticate the Registrar at the time that it is forwarding these packets.
The Join Proxy might just have discovered a Registrar to forward to using mDNS, DNS-SD, CoAP, Core-RD, or some other method in a non-secured way. In that case, an attacker that is inside the domain (e.g. desktop PC with malicious process running on it) could just pose as a "Registrar" and attract all the traffic of Join Proxies.
This could be stated as security consideration.
We could also say there a Join Proxy MAY verify the Registrar it discovered by doing a DTLS session to it, by itself. (Doing the handshake is enough. This follows the Registrar authentication by the "RA" field per constrained-voucher section 6.6.2)
That is for extra security to avoid DoS in such cases.
Based on email discussion: https://mailarchive.ietf.org/arch/msg/anima/VN8D3T_LBMz6LDCLo7T2mv5NNNc/
Since the Join Proxy is typically just a lightweight forwarder of DTLS packets to/from the Registrar, it may not always have a way to authenticate the Registrar at the time that it is forwarding these packets.
The Join Proxy might just have discovered a Registrar to forward to using mDNS, DNS-SD, CoAP, Core-RD, or some other method in a non-secured way. In that case, an attacker that is inside the domain (e.g. desktop PC with malicious process running on it) could just pose as a "Registrar" and attract all the traffic of Join Proxies.
This could be stated as security consideration. We could also say there a Join Proxy MAY verify the Registrar it discovered by doing a DTLS session to it, by itself. (Doing the handshake is enough. This follows the Registrar authentication by the "RA" field per constrained-voucher section 6.6.2) That is for extra security to avoid DoS in such cases.