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

From: Esko Dijk <[email-masked]>
Date: Wed, 24 Mar 2021 09:22:34 +0000

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Mar 2021 07:52:49 +1300

Esko,

> "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 a…

This terminology recently led to a bit of a mailstorm over in IPv6 land. The details are tedious**, but the safest way to avoid it is simply to say "Routeable address" (i.e. not link-local), which I think is the point. 

Regards
   Brian Carpenter

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 30 Mar 2021 10:00:10 +0200

HI Esko,

many thanks for the review.
Below some reactions.
Esko Dijk schreef op 2021-03-24 10:22:

> 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?
> 
> [pvds]
> Using the same term everywhere is good advice.
> Pledge is shortest and chosen.
> [sdvp]
> 
> 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"
> [pvds]
> OK; will remove "without requiring per-client state".
> [sdvp]
> -> 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.
> [pvds]
> "relay" instead of "transport" sounds reasonable to use.
> [svdp]
> 
> 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.
> [pvds]
> I will rephrase by referring to the addition of coaps to BRSKI.
> [sdvp]
> - the word "relay" may be useful to add somewhere in the introduction, 
> as the proxy relays DTLS records between Pledge and Registrar.
> 
> 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.
> 
> [pvds]
> Indeed, neighbour discovery is the wrong term.
> Discovery restricted to link-local addresses was meant.
> I will add "to use for exmple coap discovery", leaving the way open to 
> other discovery mechanisms
> [sdvp]
> 
> - 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.
> 
> [pvds]
> Yep, a few words may help
> [sdvp]
> 
> -> 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.
> [pvds]
> I think this phrase was borrowed/adapted from an early BRSKI document 
> version.
> Will think about rewording.
> [sdvp]
> 
> 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.
> [pvds]
> This is a can of worms. How will the first pledge (later join proxy) 
> ever discover the registrar using link-local addresses?
> I think the figure is correct.
> [sdvp]
> 
> [pvds]
> This is an oversight , thanks.
> [sdvp]
> 
> 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:
> 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.
> 
> [pvds]
> Case C is an interesting suggestion, but has the same problems about 
> using link-local addresses only;
> The Registrar-proxy needs quite a lot of text to be understood 
> correctly.
> I prefer to keep it out, unless there is convincing evidence that is a 
> necessary part of any installation.
> Actually your stateles JP and registrar-proxy comes close to the 
> statefull JP.
> [sdvp]
> 
> 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.)
> [pvds]
> Absolutely right. Will be clarified
> [sdvp]
> 
> 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.
> [pvds]
> My model of the installation seems to be different from yours.
> Mine is based on the onion layer model.
> The pledge close enough to the Registrar discovers the link-local 
> address of the Registrar and enrolls;
> After enrollment the pledge can dicover the network-wide address and 
> becomes a join proxy.
> The pledge that is too far from the Registrar will discover the 
> link-local address of a join-proxy.
> After enrollment it can discover the network-wide address of the 
> Rgistrar.
> 
> This process can be worked out as an example in the text (any 
> suggestions ?)
> [sdvp]
> 
> "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 ..."
> [pvds]
> sorry, did not follow the version progress.
> [sdvp]
> 
> -> 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.)
> [pvds]
> Good suggestions, but I will leave the term NAT out; the interested 
> reader may think about it though.
> [sdvp]
> 
> "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.
> [pvds]
> I have been wrestling with terminology here (And I am not the only 
> one.......)
> My suggestion is to introduce a term "installation network" and use 
> that.
> [sdvp]
> 
> Figure: the middle of the figure now has ":" characters, here we could 
> add a generic statement like "<further DTLS messages>" or so.
> [pvds]
> OK
> [sdvp]
> [pvds]
> ok
> [sdvp]
> Many thanks, certainly improves the draft.
> 
> Peter
> 
> Best regards
> Esko
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima