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