Hi authors / Peter, In addition to all comments in my previous email here is another comment / questions for Section 5.3: Since the Join Proxy J creates the message JPY which contains a CoAP content-format number ‘cf’ - how does J even know the content-format of the data carried? Since the data it receives from Pledge P is DTLS-encrypted without any indicator of content-format. The CoAP message itself including payload and its content-format indicator is inside the DTLS-encrypted record. The proxy J cannot look inside. Besides, for DTLS handshake messages there is not even a CoAP message nor CoAP content-format involved.
So the only sane thing the proxy J could do is just forward the DTLS record to the Registrar, whatever is inside. It doesn’t need to indicate a ‘cf’ because it doesn’t know that. The right information is all inside the DTLS encrypted record and Registrar can see this information anyway. So a more optimal CBOR payload would be simply a CBOR array of two elements without using core-multipart : [ <CBOR-header-structure> , <CBOR-byte-string with the DTLS record bytes> ] And the header structure could be what’s currently defined: [IP_p, p_P, ident] The overall structure can be extended in the future if needed by adding more elements. Best regards Esko From: Anima <[email protected]> On Behalf Of Esko Dijk Sent: Monday, November 30, 2020 13:51 To: Sheng Jiang <[email protected]>; [email protected]; [email protected] Cc: [email protected]; Toerless Eckert <[email protected]> Subject: Re: [Anima] Result//RE: Adoption call for draft-vanderstok-anima-constrained-join-proxy-04, ends November 15th 2020 Hello all, Sorry for the late notice – I also support adoption of a join proxy solution, which is a necessary component for constrained usage of BRSKI. I do believe the present document needs some work and maybe even reconsideration of solutions. Let me first provide a few high-level comments for discussion before doing a complete review of the document. 1. Stateful solution The proposed solution looks good; although I would do some minor reformulation of the text. Current text says that the Pledge P sends a link-local IPv6 packet to the Join Proxy J, where J then modifies the IPv6 packet and sends it onwards. This should be described more as follows to comply with IPv6 architecture: the Join Proxy creates a new IPv6 packet containing the exact DTLS message of the received link-local packet and sends the new IPv6 packet to the Registrar. This avoids tampering with IPv6 addresses; just describe it as a new packet. The Join Proxy then itself uses its own IPv6 address as source (typically an address that is non-link-local, selected to match the scope/prefix of the Registrar destination IPv6 address.) 2. Stateless solution The proposed stateless solution is also good to have – to lower the risk of certain resource exhaustion / buffer overflow attacks on the Join Proxy J. However, I see an issue in how it is currently defined: J creates a CBOR-formatted payload that is definitely not a DTLS record and then sends it to port 5684 (CoAP + DTLS) and expects the Registrar to parse it. This goes against RFC 7252 defined usage of the coaps port; you can’t send anything to there that’s not a DTLS message! Also in a typical Registrar implementation the DTLS stack that’s receiving the UDP messages on port 5684 would get really confused – and clearly dismiss the packet as an error. Surely we don’t want to meddle with the DTLS server stack of a Registrar to enable these join-proxied messages to be received? (There are some further reasons why we don’t want this – I can discuss more if needed) There are some solutions to this issue: 1. J sends the CBOR structure over UDP to a new UDP port <TBD>, which is IANA-registered as a port for a new protocol defined here (“constrained join proxy protocol” or so). This new protocol defines the CBOR data format to use. The expert reviewers may complain that this uses up valuable UDP port space; in which case option B below can be considered. 2. J sends a new Non-Confirmable CoAP request which is unprotected coap:// (just like the current CBOR defined payload is unprotected, too ) to port 5683 (the default port for unprotected coap:// ) , where the CoAP message payload carries the same CBOR structure. Internally, the Registrar then receives this CoAP request on port 5683 address to a defined well-known resource, unpacks the DTLS record from the CBOR payload, and sends that DTLS record to its DTLS server internally where it is processed as usual. For any DTLS message back to J again a new CoAP request to J can be used, using as destination UDP port the same port from which the first CoAP request was received. This has the advantage over A) that no new port needs to be IANA-registered – the existing CoAP port 5683 is re-used and only a new well-known resource needs to be defined as the “join-proxy relay resource”. Disadvantage is that the Join Proxy also has to act as CoAP server to be able to receive the DTLS records coming back from Registrar. 1. J sends the CBOR structure over UDP to a dynamic UDP port <dyn> whose value J needs to know in advance, for example by configuration (of mesh-network wide data) or by discovery (e.g. coap discovery, DNS-SD, etc.). The value <dyn> is different than 5684. The service at port <dyn> then internally forwards the DTLS record to port 5684 where it is processed as usual. Note that both above solutions have 2 additional / potential advantages from the current one in the draft: 1. the Registrar’s interface towards Join Proxies can be separated out as a separate component, so the existing Registrar code needs no modification. It just keeps listening to DTLS on port 5684 as usual; as if the Pledges are connecting directly. 2. the Registrar’s interface towards Join Proxies can be separated out to a different node altogether, which is useful in cases where say the Registrar is under control of another 3rd party and isn’t able to process join-proxy protocol traffic. Then the Registrar Interface component can be placed at another node e.g. at the customer’s domain, and any node J discovering for a Registrar will find the IP address of the Registrar Interface (RI). The latter then forwards the traffic as normal DTLS packets to Registrar. With the option B) above I have some implementation experience and I can say that it works :) A) and C) should work as well; note that these are most similar to the current draft’s solution. In case C) instead of discovering the address of a Registrar, the node J now needs to discover both address and port of the Registrar (Interface). All known discovery methods can also discover port so that should be fine. Best regards Esko IoTconsultancy.nl | Email/Teams: [email protected]<mailto:[email protected]> From: Anima <[email protected]<mailto:[email protected]>> On Behalf Of Sheng Jiang Sent: Friday, November 27, 2020 04:20 To: Sheng Jiang <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Toerless Eckert <[email protected]<mailto:[email protected]>> Subject: [Anima] Result//RE: Adoption call for draft-vanderstok-anima-constrained-join-proxy-04, ends November 15th 2020 Hi, ANIMAer, We have received supports for this adoption and has no objection. Consequently, the chairs consider the documents pass the adoption call. The authors shall resubmit this document with draft-ietf-anima-*, and the chairs shall approve it. However, The chairs do worry a little bit there is little discussion in the mail list to help the quality of this document. The authors please continue to refine the document and invoke WG discussion. Thanks and regards, Sheng From: Anima [mailto:[email protected]] On Behalf Of Sheng Jiang Sent: Monday, November 2, 2020 3:05 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Toerless Eckert <[email protected]<mailto:[email protected]>> Subject: [Anima] Adoption call for draft-vanderstok-anima-constrained-join-proxy-04, ends November 15th 2020 Hi, dear ANIMAer, This message starts a two-week adoption call, it ends on November 15th, 2020. draft-vanderstok-anima-constrained-join-proxy-04 has been presented to the WG for a long while and the WG showed good interest and had discussions. It was presented several times and had no opposition. The draft is clearly in scope of ANIMA charter and milestones. Giving the dependent BRSKI has passed the IESG evaluation, the chairs feel that it may be the right time to call the adoption. We therefore are asking the ANIMA working group for adoption of the following work: Title: Constrained Join Proxy for Bootstrapping Protocols Name: draft-vanderstok-anima-constrained-join-proxy-04 Authors: M. Richardson, P. van der Stok and P. Kampanakis URL: https://datatracker.ietf.org/doc/draft-vanderstok-anima-constrained-join-proxy/ This document is intended to become a standards track ANIMA WG document. Please express your support or rejection. If you think this document should _not_ be adopted, please also explicitly indicate the reasons. Regards, Sheng
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
