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