Hi Peter / all,
This is the final part 2 of my review of
draft-ietf-anima-constrained-join-proxy-02. Some issues identified may
have been already solved due to the Github updates in response to the
part 1 review; I didn't check for that yet.
General / all sections
There could be an interpretation issue with the term "DTLS message"
that is used. In the Join Proxy (JP) draft, a "DTLS message" is the
payload of the UDP packet that the Pledge sends to the JP. This may
consist of one or more DTLS records (see Section 4.1.1 of RFC 6347).
Each DTLS record in turn may contain a "DTLS message" (using RFC 6347
terminology) or a fragment of such "DTLS message".
The trouble is that both things are called "DTLS message". We could add
a note in the terminology section that the "DTLS message" in this draft
is the full payload of the DTLS UDP packet.
Alternatively, we may call it "DTLS packet" but this is a slight
misnomer because it is not about the full UDP DTLS packet but only its
payload (one or more records) that are being sent to the Registrar. Any
ideas to solve this? Maybe call it "DTLS payload" or "DTLS data" ?
<pvds>
A bit complex to solve. t many places I have left DTSL messages, as
this was the correct term.
At some points when discussing the Join-Proxy oration the term DTLS
payload was introduced to copy the DTLS message to the new Jpy message.
</pvds>
Section 5.2
"it sends the DTLS message to the Join Proxy"
->"it sends its DTLS messages to the Join Proxy" (clarification -
there are multiple in a DTLS session)
<pvds> done </pvds>
"The Join Proxy extends this message into a new type of message called
Join ProxY (JPY) message and sends it on to the Registrar"
-> It would be simpler and clearer to say that the Join Proxy sends a
*new* JPY message which includes the DTLS data as part of the payload.
<pvds> done </pvds>
"On receiving the JPY message, the Registrar retrieves the two parts."
(and the paragraphs below it)
-> It could also be received by a Registrary-Proxy process, not by a
Registrar. See my review part 1 comments on Section 4.
The Registrar-Proxy could be offered by the same application code that
implements the Registrar, or the Registrar could reside on another host
even.
<pvds> added "or a Registrar-proxy"</pvds>
Figure 3: "EST client" -> this should be the Pledge. Which does BRSKI
bootstrap first, and then EST. Naming it only "EST client" sounds too
narrow.
<pvds> This is an oversight was changed to Pledge already earlier
</pvds>
"Global IP address" -> see part 1 comments on this and the reply from
Brian Carpenter on this. ("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. ")
<pvds> used the term routeable; indeed always tricky to get this right
</pvds>
"In this scenario, both the Registrar and the Join Proxy use
discoverable "Join" ports."
-> In typical cases the Registrar's "Join" port is the default coaps
port 5684. Not sure if this case should be mentioned also?
<pvds> made text include the default port </pvds>
For example there may be a mechanism defined in a mesh network to
disseminate the Registrar address to all nodes so the JP learns it this
way. And if the port number is not disseminated (e.g. to save space)
then JP can assume the default port 5684.
Section 5.3
"The JPY message is constructed as a payload with media-type
aplication/cbor
Header and Contents fields togther are one cbor array of 5 elements:"
->
So it looks like this message type is a newly defined protocol format
over UDP, not a CoAP message as I initially expected. It should be
stated explicitly that this is a new protocol ; also e.g. this draft
could register a new protocol into IANA "Service Name and Transport
Protocol Port Number Registry" with a name and without a default port
number (there are many registered protocols there that do this). The
service name can make the service and its port discoverable through any
IETF defined means like DNS-SD, mDNS. CoAP discovery doesn't seem
useful here because the new-protocol isn't CoAP.
For WG discussion: why isn't CoAP re-used to transport this CBOR
payload to the Registrar without having to define a new protocol?
(One answer could be that using CoAP will add much more bytes as
overhead, e.g. to encode a URI path. And the URI path of the
Registrar's "join-proxy resource" would have to be discovered also, not
just the port. )
Or, do I have it wrong and was CoAP intended after all?
<pvds>
Right, a problem here.
In principle, the Join-Proxy extends the possibilities to invoke the
coap resource when not routeable directly.
As such the implied resource on both Registrar and Join-Proxy can
clarify the port to use.
Therefore, the coap discovery has been used with a special rt that has
the appropriate meaning.
Preparing a coap resource on the Join-Proxy was the original idea, but
abandoned due to the enormous overhead that was incurred
and the misunderstaning provoked by the Join-Proxy acting as Join-Proxy
but also as server for these resources.
Defining a new protocol without port is a possibility but not yet
specified in the document.
</pvds>
In this section also a CBOR representation of an IPv4 or IPv6 address
is defined. I recall there are already efforts being made to
standardize a way of encoding an IP address as CBOR, which we could
re-used here if applicable, in favor of using a custom encoding. For
example see draft-ietf-cbor-network-addresses that defines CBOR tags.
<pvds> the assumed representation is the representation transported in
the IP header
going to CBOR tag might work, but without CBOR tag it is just a simple
copy from IP header to JPY header and v.v.
</pvds>
How are the address family integer numbers defined? The Appendix A
shows '10' for IPv6. If I look into this IANA registry
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
[1] then IPv6 is number 2. One could also think '4' for IPv4 and '6'
for IPv6.
Section 6
In the table: "it includes additional source and destination
addresses". It includes only one IP address. This is both source (of
the inbound DTLS IP packet of Pledge to Join-Proxy) and destination
(for the outbound DTLS packet from Join-Proxy to Pledge) so best not to
mention source/destination here maybe.
<pvds> made text less specific</pvds>
In the table: "and modify the source and destination addresses of the
DTLS handshake messages" ->
see previous comments, this looks incorrect. The Join-Proxy effectively
creates a new IP packet with the DTLS data inside, both handshake
records and data records are treated equally i.e. it does not
distinguish.
<pvds>changed accordingly </pvds>
Section 7
BRSKI reference can now be updated to RFC 8995.
<pvds> done </pvds>
"The discovery follows two steps:" -> there are 3 steps numbered. And
the first 2 are not steps, but 2 different deployment cases.
<pvds> An enormous struggle with markdown editor with an unsatisfactory
result</pvds>
"From then on, it follows the BRSKI process as described in
{I-D.ietf-ace-coap-est}" -> the BRSKI process using coaps is defined in
draft-ietf-anima-constrained-voucher.
<pvds> added </pvds>
the Registrar offer -> the Registrar offers
<pvds>done </pvds>
Requirement is unclear:
"The Join Proxy and Registrar MUST show the extra join port number when
reponding to the
<pvds>removed MUST and adapted text</pvds>
.well-known/core request addressed to the standard coap/coaps port."
· In case the Registrar does not include a "Registrary-Proxy"
function i.e. it does not implement the join-port with the JPY_message
protocol, it does not have to show the extra join port - there is none.
· "reponding to the .well-known/core request" -> "responding to
a /.well-known/core discovery request"
<pvds> changed </pvds>
· How can a Registrar show a join port number of a protocol
(JPY_message protocol) that isn't CoAP ? CoAP discovery only works
for CoAP resources or endpoints. <pvds>see above </pvds>
· Similar question for Join-Proxy.
· In case the requirement of "MUST show the extra join port
number" is detailed in another section later on, this requirement
should make perhaps a forward reference to that section.
Section 7.1
note that 7.1.1 talks about discovery by the Join-Proxy, while title of
7.1 suggests only discovery by Pledge of the Registrar is in scope. I
assume it is 7.1.1 that needs an update?
"The Pledge and Join Proxy are assumed to communicate via Link-Local
addresses."
-> "In the below subsections, the Pledge and Registrar are assumed to
communicate via Link-Local addresses."
To make it more clear that this isn't always the case and that section
7.1 only covers the case of direct link-local communication.
<pvds> Tried to make text structure clearer </pvds>
Section 7.1.1
I assume this needs to say that it is discovery "by the Pledge" ? And
the following text
"The extension to discover the additional port needed by the stateless
proxy is described in Section 7.2.2."
seems out of place because for direct link-local discovery of a
Registrar, which is in section 7.1 scope, you don't need a Join Proxy
right?
If not I'm really confused about the sections 7.1/7.2/7.3 intentions.
<pvds> So was I, apologies </pvds>
Section 7.2
In this section, 6tisch is not mentioned. How would 6tisch Pledge
discover a Join-Proxy? In case 6tisch uses a Join-Proxy potentially:
add subsection on this case. (In case there is no Join-Proxy used in
6tisch: why is 6tisch mentioned at all in this document then?)
<pvds> for completeness sake; can be removed </pvds>
Section 7.2.2
"resource type (rt) parameter with the value "brski-proxy" [RFC6690]."
->
This suggests that RFC6690 has the details about the "brski-proxy"
resource type, which is not the case. Maybe rephrase as below. Also I
propose another name that is more in line with the definitions for the
"brski.*" resource type attribute like in
draft-ietf-anima-constrained-voucher-11 Section 12.1 .
"resource type (rt) attribute [RFC6690] with the value "brski.jp"."
The dot "." is used as a hierarchical delimiter and the name following
the dot is made as short as possible.
<pvds> Left as is, need some more input here </pvds>
"Discoverable port numbers are usually returned for Join Proxy
resources in the <href> of the payload (see
section 5.1 of [I-D.ietf-ace-coap-est])."
-> the "<href>" part isn't mention in the ace-coap-est reference. So
this probably needs some more explanation?
In RFC 6690 the URI part between the pointy brackets in the Link-Format
document is called the "URI-Reference". Maybe this part is meant?
<pvds> Don't understand, by writing <uri> the href is mentioned, OK?
</pvds>
It could also be added to the text in this section that the
"[IP_address]" in the discovery response MUST be a link-local address.
(Otherwise, a thoughtless implementation could return another type of
address i.e. routable address, which may not be accessible to the
Pledge in some cases e.g. when a security-aware intelligent ethernet
switch blocks any non-link-local traffic of a Pledge.
<pvds> left this open untill the future has become better known</pvds>
Also this section could propose to discover any BRSKI resources so
query "brski*" or "brski.*" so that
1. if only a Join Proxy for BRSKI exists, it would return
brski.jp - and the Pledge knows to use that Proxy
2. if also a Registrar for BRSKI exists, it would return its
resources like rt=brski and so on. So then the Pledge knows to use
direct communication to Registrar and not the Join Proxy.
<pvds> wait for more discussion </pvds>
Section 8
"receives a valid [RFC8366] voucher"
-> here, also a reference to constrained-voucher could be made in
addition?
<pvds done </pvds>
"If the proxy/Registrar was not over a secure network" -> what is meant
here? E.g.
"If the Join-Proxy to Registrar communication was not over a secure
network" ?
<pvds> changed </pvds>
In general can use "Join Proxy" here instead of "proxy", for clarity.
<pvds> done </pvds>
Section 9.1
see my above proposal for naming "brski.jp".
The rt name rt="join-proxy" to indicate support of the JPY_message
protocol on the Registrar is not the best name I think.
At least to me it makes sense if the join-proxy announces its
functionality as "brski.jp" which effectively announces CoAP-over-DTLS
(coaps://) support on the given port, with relay to a Registrar, for
all CoAPS resources.
Then for the "Registrar-Proxy" side of things it could be "brski.rp"
for example. But only if the concept of a "Registrar-Proxy" is
introduced in the draft, and that would depend on how my comments are
handled :)
<pvds> the concept of a registrar-proxy is not clear to me; what is its
functions next to the join-proxy ? </pvds>
Ideally the new "JPY_message protocol" would be given a proper protocol
name (as it is not CoAP) and then the support for this protocol on the
given port can be announced with rt="brski.jpy" for example, if the
name is going to be "JPY protocol" or so.
<pvds> posibly </pvds>
One issue is that the JPY protocol being discovered is not CoAP (see
section 5.3 comments), and now we discover it as if it were a CoAP
resource. That seems strange but at the same time re-using CoAP
discovery for this is great and avoids having to do other discovery
means again which the constrained Join Proxy device would likely not
implement or would not be practical.
Maybe we could poll the CoRE WG for this idea of CoAP discovery of
non-CoAP protocols!
(In our case, the JPY protocol wraps CoAP-over-DTLS so you can argue
that it is a sort of CoAP after all.)
<pvds> Indeed, see above </pvds>
Appendix A
The examples show the get coaps://[192.168.1.200]:5965/est/crts
-> to remove square brackets for IPv4 address
-> "get" -> "request GET"
"client" -> maybe just say "Join Proxy"?
The link-local address stored in the CBOR array element 0 should start
with "FE80" , or not?
<pvds> changed </pvds>
Best regards
Esko
IoTconsultancy.nl | Email/Teams: [email protected] |
+31 6 2385 8339
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
