Subject: Re: [Anima] Review of draft-ietf-anima-constrained-join-proxy-02 (part 2/2)

From: Peter van der Stok <[email-masked]>
Date: Mon, 09 Aug 2021 12:22:15 +0200

HI Esko.

thanks again for the review.
My apologies for the late reaction, but many thinks happened around 
BRSKI, retaining my atention.

See below for the reactions.

Peter
Esko Dijk schreef op 2021-06-23 09:48:

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

Links:
------
[1] 
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 09 Aug 2021 12:26:32 +0200

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-masked]> On Behalf Of Esko Dijk
> Sent: Wednesday, June 23, 2021 09:48
> To: [email-masked]
> Subject: [Anima] Review of draft-ietf-anima-constrained-join-proxy-02 
> (part 2/2)
> 
> Hi Peter / all,
> 
> for CoAP resources or endpoints.
> 

Links:
------
[1]

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 09 Aug 2021 12:27:46 +0200

To remove confusion, Pledge is used throughout the document.

Peter
Michael Richardson schreef op 2021-06-23 22:15:

> Esko Dijk <[email-masked]> wrote:
> Hmm.
> It definitely the pledge until the voucher has been verified, and the
> provisional (D)TLS connection has been verified.  Probably until after 
> the
> voucher-status POST.
> 
> At which point, ... it's really a verified EST client, and since
> renew loops back to this point... calling it the EST client also makes 
> sense.
> 
> Maybe "EST pledge client" or some merging of terms?
> 
> I think another answer is because the server side won't be CoAP, it's 
> DTLS
> with a bit.

---

From: Esko Dijk <[email-masked]>
Date: Tue, 17 Aug 2021 13:43:24 +0000

Hi Peter,

You mention using Blockwise CoAP and no hiccups occur in your implementation. That’s good, but not the full story yet: to make sure the size of the DTLS handshake messages is also limited to something ‘well below 1280’ , blockwise CoAP doesn’t help.
This requires the DTLS message fragmentation feature of DTLS. This aspect may be overlooked by implementers because normally there will be no hiccups even if this feature is forgotten. For example if the size of certificate chains is not too large (say in the ~1100 bytes or lower range) then no issue will occur.  Issues could occur once the size of certificate chains in the handshake messages gets higher than this.

So my point was that the draft could mention this implementation aspect; preferably a DTLS client on the Pledge should use this; see the motivation in https://datatracker.ietf.org/doc/html/rfc7925#section-15 .
The extension/option itself is defined in https://datatracker.ietf.org/doc/html/rfc6066#section-4 .  A value 2^9 or 2^10 is a good choice for 6lowpan networks. If the client signals this, the Registrar knows the size of the fragments to use for the constrained network, even if it is located itself on a non-constrained network without those MTU constraints.

A pointer to RFC7925 section 15 may be sufficient for this. (I’d rather not bet on the fact that all implementers will already know RFC 7925 and RFC 6066 … if anyone disagrees let me know.)

Regards
Esko

From: Peter van der Stok <[email-masked]>
Sent: Monday, August 9, 2021 12:27
To: Esko Dijk <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] Review of draft-ietf-anima-constrained-join-proxy-02 (part 2/2)

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

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.

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-masked]<mailto:[email-masked]>> On Behalf Of Esko Dijk
Sent: Wednesday, June 23, 2021 09:48
To: [email-masked]<mailto:[email-masked]>
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 its DTLS messages to the Join Proxy"  (clarification - there are multiple in a DTLS session)

-> 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.

-> 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

->

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. )

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

"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.

Requirement is unclear:

"The Join Proxy and Registrar MUST show the extra join port number when reponding to the

•         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?

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

->

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 .

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

-> 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

-> 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"  ?

Section 9.1

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 link-local address stored in the CBOR array element 0 should start with "FE80" , or not?

Best regards

Esko

IoTconsultancy.nl  |  Email/Teams: [email-masked]<mailto:[email-masked]>    |   +31 6 2385 8339

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 18 Aug 2021 10:59:42 +0200

Hi Esko,

you are referring to the DTLS hello messages containing these large 
lists of certificates?
That sounds like a general coaps problem and nothing constrained voucher 
specific.

Peter
Esko Dijk schreef op 2021-08-17 15:43:

> Hi Peter,
> 
> You mention using Blockwise CoAP and no hiccups occur in your 
> implementation. That's good, but not the full story yet: to make sure 
> the size of the DTLS handshake messages is also limited to something 
> 'well below 1280' , blockwise CoAP doesn't help.
> 
> This requires the DTLS message fragmentation feature of DTLS. This 
> aspect may be overlooked by implementers because normally there will be 
> no hiccups even if this feature is forgotten. For example if the size 
> of certificate chains is not too large (say in the ~1100 bytes or lower 
> range) then no issue will occur.  Issues could occur once the size of 
> certificate chains in the handshake messages gets higher than this.
> 
> So my point was that the draft could mention this implementation 
> aspect; preferably a DTLS client on the Pledge should use this; see the 
> motivation in https://datatracker.ietf.org/doc/html/rfc7925#section-15 
> .
> 
> The extension/option itself is defined in 
> https://datatracker.ietf.org/doc/html/rfc6066#section-4 [2] .  A value 
> 2^9 or 2^10 is a good choice for 6lowpan networks. If the client 
> signals this, the Registrar knows the size of the fragments to use for 
> the constrained network, even if it is located itself on a 
> non-constrained network without those MTU constraints.
> 
> A pointer to RFC7925 section 15 may be sufficient for this. (I'd rather 
> not bet on the fact that all implementers will already know RFC 7925 
> and RFC 6066 ... if anyone disagrees let me know.)
> 
> Regards
> 
> Esko
> 
> Subject: Re: [Anima] Review of 
> draft-ietf-anima-constrained-join-proxy-02 (part 2/2)
> 
> Hi Esko,
> 
>> 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.
>> 
>> 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.
>> 
>> 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
>> 
>> 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.
>> 
>> 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
>> 
>> implements the Registrar, or the Registrar could reside on another 
>> host even.
>> 
>> 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
>> 
>> service name can make the service and its port discoverable through 
>> any IETF defined means like DNS-SD, mDNS.  CoAP discovery doesn't seem 
>> Registrar's "join-proxy resource" would have to be discovered also, 
>> not just the port. )
>> 
>> (for the outbound DTLS packet from Join-Proxy to Pledge) so best not 
>> to mention source/destination here maybe.
>> 
>> 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
>> 
>> {I-D.ietf-ace-coap-est}" -> the BRSKI process using coaps is defined 
>> in  draft-ietf-anima-constrained-voucher.
>> 
>> ·         "reponding to the .well-known/core request" -> "responding 
>> to a /.well-known/core discovery request"
>> 
>> 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?
>> 
>> 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?
>> 
>> 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.
>> 

Links:
------
[1] 
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
[2] https://datatracker.ietf.org/doc/html/rfc6066#section-4

---

From: Esko Dijk <[email-masked]>
Date: Thu, 19 Aug 2021 14:52:50 +0000

Hi Peter,

I would rather say this is a problem specific to the join-proxy. Since the join-proxy must transport DTLS handshake messages; specifically ‘certificate’ DTLS handshake messages that contain a client or server certificate chain; these come after the hello messages and can be of large size potentially.
This is also not CoAPs-specific, it would also be an issue for any other protocol being relayed in the manner as described for stateless join-proxy.

Normally a 1280-byte handshake message (single UDP datagram) can pass from source to destination without problem. But when a join-proxy is placed in-between source and destination and it adds a (CBOR) header of a few bytes, such an UDP transmission from source (Pledge) to dest (Registrar) will fail because the UDP packet exceeds the 1280 byte limit in the leg between the join-proxy and the Registrar. Assuming that the join-proxy itself resides on the constrained (mesh) network, typically it is a direct link-local neighbor of the Pledge. Likewise if the Registrar DTLS stack generates a 1280-byte UDP packet with a DTLS handshake message, which is normally just fine, for any IPv6 MTU value, then in the case that the stateless join-proxy protocol is used so there is a Registrar-Proxy component (which may be integrated into the Registrar – it’s still there) that needs to append a CBOR header of a few bytes to it which increases the UDP packet to a size >1280 bytes. Then such UDP packet cannot enter onto the 6LoWPAN (constrained) network anymore and the packet will be dropped at the Border Router.

These issues can be resolved if the Pledge in the handshake process sends the Maximum Fragment Length (MFL) DTLS extension with either a 2^9 or 2^10 value; and fragments its own outgoing traffic accordingly also.

So the problem described is not ‘large certificate lists that exceed 1280 bytes’, which is a more obvious problem. Rather the problem here is ‘large certificates/lists that get close to 1280 bytes but for which the sender thinks that it will still fit because the sender doesn’t consider a join-proxy’.

Regards
Esko

From: Peter van der Stok <[email-masked]>
Sent: Wednesday, August 18, 2021 11:00
To: Esko Dijk <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] Review of draft-ietf-anima-constrained-join-proxy-02 (part 2/2)

Hi Esko,

you are referring to the DTLS hello messages containing these large lists of certificates?
That sounds like a general coaps problem and nothing constrained voucher specific.

Peter

Hi Peter,

You mention using Blockwise CoAP and no hiccups occur in your implementation. That's good, but not the full story yet: to make sure the size of the DTLS handshake messages is also limited to something 'well below 1280' , blockwise CoAP doesn't help.

A pointer to RFC7925 section 15 may be sufficient for this. (I'd rather not bet on the fact that all implementers will already know RFC 7925 and RFC 6066 ... if anyone disagrees let me know.)

Regards

Esko

From: Peter van der Stok <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 9, 2021 12:27
To: Esko Dijk <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] Review of draft-ietf-anima-constrained-join-proxy-02 (part 2/2)

Hi Esko,

Peter

Best regards

Esko

Hi Peter / all,

General / all sections

Section 5.2

Section 5.3

->

Section 6

Section 7

Requirement is unclear:

Section 7.1

Section 7.1.1

Section 7.2

Section 7.2.2

->

Section 8

Section 9.1

Appendix A

Best regards

Esko

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Aug 2021 16:49:55 -0400

Esko Dijk <[email-masked]> wrote:
    > .  The extension/option itself is defined in
    > https://datatracker.ietf.org/doc/html/rfc6066#section-4 .  A value 2^9
    > or 2^10 is a good choice for 6lowpan networks. If the client signals
    > this, the Registrar knows the size of the fragments to use for the
    > constrained network, even if it is located itself on a non-constrained
    > network without those MTU constraints.

So, I think you are saying that we need to say something about keeping the
DTLS handshake fragmentation size small enough that we can add the join-proxy
overhead.

Would a section 5.4: DTLS Considerations make sense?

   5.  BRSKI-EST Protocol  . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Discovery, URIs and Content Formats . . . . . . . . . . .   6
     5.2.  Extensions to BRSKI . . . . . . . . . . . . . . . . . . .   8
     5.3.  Extensions to EST-coaps . . . . . . . . . . . . . . . . .   9
       5.3.1.  Pledge Extensions . . . . . . . . . . . . . . . . . .   9
       5.3.2.  Registrar Extensions  . . . . . . . . . . . . . . . .  10
**   5.4   DTLS Considerations

Peter, we can't use Blockwise on the DTLS handshake, because that part is
outside of the CoAP header.  We can only blockwise on the CoAP Payload.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Peter van der Stok <[email-masked]>
Date: Fri, 20 Aug 2021 12:26:15 +0200

Hi Michael,

see below
Michael Richardson schreef op 2021-08-19 22:49:

> -->pvds  makes sense to me.
> 
> -->pvds agreed, but
> -->any DTLS coap implementation suffers from the same problem, 
> according to me.
> --> For a section 5.4, please go ahead; but it needs explaining why 
> join-proxy is so special.
> 
> Peter
> 
> --

---

From: Esko Dijk <[email-masked]>
Date: Fri, 20 Aug 2021 15:06:56 +0000

Hi Michael,

So you're proposing to add these DTLS considerations into draft-constrained-voucher, since the (constrained) Pledge has to do something additional (i.e. use the MFL option in DTLS) with respect to a regular BRSKI TLS Pledge?
That sounds good to me. This even seems relevant if there is no Join Proxy in the middle: for cases that an unaware Registrar would construct a >1280 byte UDP datagram for example.    
In this case, path MTU discovery could make the Registrar learn to not exceed 1280 bytes, but the explicit signaling of MFL by the client is more efficient and also solves the case of "Join Proxy in the middle".

Instead of a section 5.4, a subsection in Section 9 is also possible, but I don't have a preference.

The Join-Proxy draft might then refer to that DTLS considerations section in draft-constrained-voucher. The "special case" that join-proxy presents (as Peter commented on) could be explained best in the Join Proxy document.

Esko