Subject: [Anima] draft-vanderstok-anima-constrained-join-proxy-04: how can J know the content-format cf

From: Esko Dijk <[email-masked]>
Date: Mon, 30 Nov 2020 13:01:07 +0000

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-masked]> On Behalf Of Esko Dijk
Sent: Monday, November 30, 2020 13:51
To: Sheng Jiang <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; Toerless Eckert <[email-masked]>
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-masked]<mailto:[email-masked]>

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 30 Nov 2020 14:12:27 +0100

On 2020-11-30, at 14:01, Esko Dijk <[email-masked]> wrote:
> 
> without using core-multipart

Why not?

Grüße, Carsten

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 30 Nov 2020 14:22:07 +0100

Yes, why not.

For the moment, in the invisible version 1, two content-formats are
transported:

1) application cbor describing the header of the JPY message
2) application cbor, a cbor byte string containing the DTLS

This clearly sits between two approaches.
1) replace with application/cbor for the whole
or 2) remove the cbor byte string from the DTLS payload

BTW, as these messages are not accompanied by a coap header , it is may
be better to completely forget about content formats.

Additional suggestions are really welcome.

Peter

---

From: Esko Dijk <[email-masked]>
Date: Mon, 30 Nov 2020 13:28:06 +0000

> Why not?
One reason not to use multipart might be because the CBOR data transports not multiple content-formats - but just one content-format. (It is CBOR (60).  Or if we want to make it more specific, it is 'join-proxy-protocol-format' which is a specific structure encoded in CBOR). But that's just a viewpoint maybe, I can imagine we can also view this as two parts: one part is CBOR 'state' from the Join Proxy and another part is opaque 'DTLS record' binary data.   Both would be feasible.

Another reason to say this was that the content-format of what's inside the opaque DTLS data isn't known by the Join Proxy, so it can't attach a numeric 'cf' type to that.   Peter mailed me privately that this could be resolved by defining a CoAP content-format for "DTLS-record data".  As alternative for this new Content-Format one could also define multipart as follows:

   [ 60 , <cbor-state-data> , 42 , <DTLS-record-data> ]

So the DTLS data is labelled as application/octet-stream.

Noting that the above CBOR is 4 bytes longer than
   [<cbor-state-data> , <DTLS-record-data> ]

To consider: what advantage would we get from using the 4-byte-longer variant? Both are extendible in multiple ways ~ about roughly the same level of extendibility.

Esko

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Monday, November 30, 2020 14:12
To: Esko Dijk <[email-masked]>
Cc: [email-masked]; peter van der Stok <[email-masked]>
Subject: Re: [Anima] draft-vanderstok-anima-constrained-join-proxy-04: how can J know the content-format cf

Why not?

Grüße, Carsten

---

From: Esko Dijk <[email-masked]>
Date: Mon, 30 Nov 2020 14:27:22 +0000

> BTW, as these messages are not accompanied by a coap header , it is may be better to completely forget about content formats.

For the latter approach see my recent email: leaving out the not-that-useful content-format numbers saves 4 bytes in the resulting CBOR.
Open question is now: when/why would including such numbers be useful and worth the bytes?  Given that the current CBOR structure is not sent over CoAP but over UDP.

(For the over-CoAP option see my very first email, option B) – this can work as well but uses even more bytes, for the CoAP header…).

Esko

From: Peter van der Stok <[email-masked]>
Sent: Monday, November 30, 2020 14:22
To: Carsten Bormann <[email-masked]>
Cc: Esko Dijk <[email-masked]>; [email-masked]; peter van der Stok <[email-masked]>
Subject: Re: [Anima] draft-vanderstok-anima-constrained-join-proxy-04: how can J know the content-format cf

Yes, why not.

For the moment, in the invisible version 1, two content-formats are transported:

BTW, as these messages are not accompanied by a coap header , it is may be better to completely forget about content formats.

Peter

Carsten Bormann schreef op 2020-11-30 14:12:
On 2020-11-30, at 14:01, Esko Dijk <[email-masked]<mailto:[email-masked]>> wrote:

Why not?

Grüße, Carsten