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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
