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

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.
> 
> "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.
> 
> [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]
> 
> 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.
> [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]
> 
> "EST Server" -> better replace with the introduced term "Registrar" to 
> keep consistency.
> [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:
> 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.
> 
> [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]
> 
> 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.)
> [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 ..."
> -> The discovery method for the Pledge is described in Section 4.1, not 
> 4.3.
> [pvds]
> sorry, did not follow the version progress.
> [sdvp]
> 
> "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.)
> [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]
> -> caption of the figure could add 'DTLS' here, so "... DTLS joining 
> message flow ..."
> [pvds]
> ok
> [sdvp]
> 
> Many thanks, certainly improves the draft.
> 
> Peter
> 
> Best regards
> Esko
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima