Re: [Anima] Result//RE: Adoption call for draft-vanderstok-anima-constrained-join-proxy-04, ends November 15th 2020

[Peter van der Stok <[e-mail]>]

Hi Esko,

thanks for the comments.
In the text of version 1 of the WG join-proxy draft (to be published,
once version 0 is approved by the chairs), the approach to stateless jp
is with an additional port. No parsing is needed. Indeed that was a
mistake.
The additional port does not need not need IANA registration.
(discussion is needed ?)
The stateful approach is described in version 1 as described by you. I
will check on misunderstandings.

BTW both solutions work in my implementation.

Please have a look to version 1, once it is published.

Peter

Esko Dijk schreef op 2020-11-30 13:50:

>> 

> 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: 
> 
> * 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.
> * 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. 
> 
> * 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: 
> 
> * 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.
> * 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: [e-mail] 
> 
> From: Anima <[e-mail]> On Behalf Of Sheng Jiang
> Sent: Friday, November 27, 2020 04:20
> To: Sheng Jiang <[e-mail]>; [e-mail]
> Cc: [e-mail]; Toerless Eckert <[e-mail]>
> 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:[e-mail]] On Behalf Of Sheng Jiang
> Sent: Monday, November 2, 2020 3:05 PM
> To: [e-mail]
> Cc: [e-mail]; Toerless Eckert <[e-mail]>
> 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