[Anima] Review of draft-ietf-anima-constrained-join-proxy-02 (part 1)

[Esko Dijk <[e-mail]>]

Hello,

I'm doing a review of draft-ietf-anima-constrained-join-proxy-02; below part 1 of my review comments. The remainder will follow soon hopefully. 
Note that I did not make or work with an implementation of this draft but I have experience with similar proxy implementations: for example OpenThread (https://github.com/openthread/openthread) uses one.  And I've worked with an implementation that uses a proxy to a BRSKI Registrar (https://github.com/openthread/ot-registrar/).
So it is definitely a useful document and an essential component of any constrained BRSKI solution for wireless mesh networks.

General throughout text: 
The terms "Pledge" and "joining device" and ""joining" device" are all used - this could be harmonized to a single term to be sure what we're talking about. What about using "Pledge" for all?

Abstract
“replacing the Circuit-proxy by a stateless/stateful constrained (CoAP) Join Proxy. It transports join traffic from the pledge to the Registrar without requiring per-client state”
-> may be confusing; first it looks like we define both stateless and stateful versions. But the last sentence implies always stateless?
- the word "relay" may be useful to add somewhere in the abstract, as the proxy relays DTLS records between Pledge and Registrar.

1. Introduction
“The {I-D.ietf-anima-constrained-voucher} describes the BRSKI extensions to the Registrar.”
-> this should be updated to the latest scope of this referenced draft. It describes also Pledge behavior, not only Registrar. This is now called the Pledge - Registrar part of the protocol ("BRSKI-EST") . 
-> We could clarify here that in {I-D.ietf-anima-constrained-voucher} BRSKI is also being extended with CoAP and DTLS.
- the word "relay" may be useful to add somewhere in the introduction, as the proxy relays DTLS records between Pledge and Registrar.

"A new "joining" device can only initially use a link-local IPv6 address to communicate with a
   neighbour node using neighbour discovery [RFC6775] until it receives the necessary network configuration parameters. "
-> the part about "using neighbour discovery" I don't fully understand and is in general incorrect. The OpenThread implementation allows for example a Pledge to use Mesh Link Establishment (MLE, draft-ietf-6lo-mesh-link-establishment-00) communication to initiate discovery and linking with peer nodes.  There's no ND used. And with a link-local address the Pledge can also use other protocols like UDP or DTLS-over-UDP in principle, anything link-local would be possible. Most of this traffic of course won't be accepted by nodes in the mesh network due to security reasons. But a protocol may define some specific use cases where link-local UDP (or other protocols) are accepted without requiring the Pledge to use ND in any way. Again in OpenThread as an example, DTLS-over-UDP is used to do the handshake via the proxy/relay without ever using ND.

- Section 1 would need to have some text about the stateful/stateless solutions, too. I know this is said in Section 5 as well, but typically an introduction is meant to guide the reader into what can be expected in the rest of the document and this incurs some overlap of topics necessarily.

4. Join Proxy functionality

"assuming appropriate credentials are exchanged out-of-band, e.g. a hash of the Pledge (P)'s raw public
   key could be provided to the Registrar (R)."
-> I don't understand this, why is this assumption necessary? Can't we just assume the BRSKI case that P contains an IDevID and R may know nothing yet about P ?
(or, it may know a serial number of P but not yet the complete IDevID.) R learns the identity of P during the DTLS handshake that involves R learning about the IDevID.

Figure 1 and explanation -> we may also add that a Registrar can be located externally to the mesh. So, not necessarily on-mesh as the figure seems to suggest.

"EST Server" -> better replace with the introduced term "Registrar" to keep consistency.

This section defines the overall architecture and has the deployment diagram. So this would be a good section to consider the most common deployment cases, like:
A) Pledge -> stateful JP -> Registrar
B) Pledge -> stateless JP -> Registrar
C) Pledge -> stateless JP -> Registrar-Proxy -> Registrar
The latter C) I've added here to illustrate what could be deployed. Since the Registrar may be a "classic" Registrar per constrained-BRSKI that only serves DTLS on port 5684 and knows nothing about the JPY message format introduced in Section 5.2. In this case another proxy is required which I call "Registrar-Proxy" that translates JPY messages back to regular DTLS towards the existing/legacy Registrar.  Note that the Registrar-Proxy may reside at the same IP host as the Registrar, albeit at a different UDP port (not 5684) - this is then very similar to the case B).
It would be good to have some of these deployment considerations. The benefit of C) is that any 'stateful' operations are moved out of the mesh network to the Registrar-Proxy which resides typically on a powerful IP host outside the mesh.  Any constrained devices only implement stateless JP.

5. Join Proxy specification

Two modes are introduced here; it may be clarified that a Join Proxy MUST implement at least one of these two. (There may be implementations that can do both, or can switch to the right model to use based on some network configuration. But in typical cases a network standard only implements one of the two ways.)

5.1 Statefull Join Proxy

"The Join Proxy has has been enrolled via the Registrar and consequently knows the IP address and port of the Registrar.  "
-> this is not the case typically. The Join Proxy itself previously enrolled through another Join Proxy, without knowing the IP address of the Registrar!
There may be a mechanism to send the IP address of the Registrar to a Pledge after it has onboarded but we can't be sure that this is the case. It is not specified. And the way a Join Proxy learns about the Registrar's IP address (or hostname!) would be specific to the type/standard of 6lowpan network used. There are many flavours of it.

"The Pledge first discovers and selects the most appropriate Join Proxy.  (Discovery can be based upon [I-D.ietf-anima-bootstrapping-keyinfra] section 4.3 ..."
-> The discovery method for the Pledge is described in Section 4.1, not 4.3.

"The Join Proxy changes the IP packet (without modifying the DTLS message) by modifying both
   the source and destination addresses to forward the message to the intended Registrar."
-> The IP addresses of an IP packet should preferably not be changed in transit. A link-local destined packet from the Pledge also does not travel beyond the local link normally. 
Perhaps it is better described as the Proxy creating a new IP message, with new source/destination addresses. The new message then contains the relayed DTLS record.  This is conceptually more in line with the IPv6 addressing architecture. 
Whether we should call this NAT or not, is another question. For me personally I would just avoid calling it NAT. (E.g. I don't think any NAT would translate a link-local address to a global scope address.)

"Global IP address" -> used in the figure; it may be sufficiently clear already that this may be a ULA or GUA type address. Optionally this could be clarified in the Terms section what "global IP address" means, but if others disagree we don't need to add this.

Figure: the middle of the figure now has ":" characters, here we could add a generic statement like "<further DTLS messages>" or so.
-> caption of the figure could add 'DTLS' here, so "... DTLS joining message flow ..."


Best regards
Esko