Hi Esko,
I see your point but do not share it , I believe.
In my case, coap block is used and multiple DTLS records are sent over
by the Join-Proxy without hiccups.
The same problem comes up for communication between Registrar and MASA
using https, but again mutiple DTLS messages can be transmitted.
Peter
Esko Dijk schreef op 2021-06-23 12:10:
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
Links:
------
[1]
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
