PS one further addition to my review; a consideration that should be
added somewhere:
Suppose that the Pledge creates a IPv6 UDP packet containing a DTLS
record of 1278 bytes; and the network is 6LoWPAN based (1280 byte MTU
limit). Then a stateless Join Proxy would have to create a
JPY_message by adding a few more bytes for the CBOR map, so the
overall new packet to be sent to the Registrar over the 6lowpan
network would exceed 1280 bytes so it cannot send it.
Consequence: the BRSKI protocol cannot proceed; failure.
So a Pledge that is configured to use a Join Proxy MUST limit the size
of its DTLS records to some value < 1280 such that when added to the
worst-case-length CBOR map added by a stateless Join Proxy, the total
does not exceed 1280 bytes; in case the Pledge is using 6lowpan
network interface. In general, also for other link types, the Pledge
should be some bytes under its current link MTU to the Join Proxy.
Because the Pledge doesn't know in advance whether the Join Proxy
operates stateful or stateless.
DTLS has a built-in mechanism to fragment handshake messages (e.g. to
1024 byte fragments) which can be used to stay below the limit. And
for CoAP-over-DTLS messages, blockwise transfer can be used to ensure
this.
Best regards
Esko
From: Anima <[email protected]> On Behalf Of Esko Dijk
Sent: Wednesday, June 23, 2021 09:48
To: [email protected]
Subject: [Anima] Review of draft-ietf-anima-constrained-join-proxy-02
(part 2/2)
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" ?
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)
"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.
"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.
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.
"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. ")
"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?
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?
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.
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.
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.
Section 7
BRSKI reference can now be updated to RFC 8995.
"The discovery follows two steps:" -> there are 3 steps numbered. And
the first 2 are not steps, but 2 different deployment cases.
"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.
the Registrar offer -> the Registrar offers
Requirement is unclear:
"The Join Proxy and Registrar MUST show the extra join port number
when reponding to the
.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"
· 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.
· 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.
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.
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?)
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.
"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?
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.
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.
Section 8
"receives a valid [RFC8366] voucher"
-> here, also a reference to constrained-voucher could be made in
addition?
"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" ?
In general can use "Join Proxy" here instead of "proxy", for clarity.
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 :)
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.
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.)
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?
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
