search

anima-wg / constrained-voucher

This is a repo for the IETF Internet Draft about constrained vouchers in CBOR
2 stars 4 forks source link

clarify section 5.2 that RD is not forbidden (in general) #109

Closed mcr closed 3 years ago

mcr commented 3 years ago

But that for the case where we have discovered the Registry end-point and already have DTLS, then we do not need more discovery.

But, in the generic RPL case, then we might do RD to find the Join Proxy.

EskoDijk commented 3 years ago

Update to above text: instead of "RD" it should read "CoAP discovery". (RD isn't accessible yet for the Pledge, only link local CoAP discovery by unicast or multicast)

Clarification of this issue: the point of the Section 5.2 text was that discovery for EST resources /.well-known/est of the Registrar is not needed anymore once the DTLS connection to the Registrar is already established. Also discovery of BRSKI resources /.well-known/brski is not needed once the DTLS connection is established. This all assumes the Pledge knows a single bootstrap method (BRSKI) and a single enrollment method (EST) so discovery wouldn't help the Pledge in any way.

One additional thought: to be able to reap the code size benefits of this (i.e. no more CoAP discovery code and parsing of link format code!) it is REQUIRED that the Registrar offers the EST resources at their "well-known" locations. Otherwise a Pledge without this discovery code might get stuck onboarding to a particular Registrar. (So a "SHOULD offer the well-known EST resources at the same port/DTLS-connection" is not strong enough - a MUST is required here for interoperability.)

Important in this is that the destination port of that DTLS connection could be a non-standard port as Peter mentioned earlier. This implies that the well-known/est resources are offered also at this non-standard port, which is noteworthy as the support for well-known resources by default assumes only the default scheme ports are supported. In our constrained-voucher draft we thus make an additional assumption on this.

petervanderstok commented 3 years ago

Hi Esko,

especially the condition "Once DTLS connection is established" is essential and well hidden in the text.

Concerning non-standard ports. For the moment I discover all non-standard ports via a get to /.well-known/core on th standard port. That is also explained in est-coaps draft. (much commented upon during IESG review).

Cheerio,

peter Esko Dijk schreef op 2021-04-26 09:30:

Update to above text: instead of "RD" it should read "CoAP discovery". (RD isn't accessible yet for the Pledge, only link local CoAP discovery by unicast or multicast)

Clarification of this issue: the point of the Section 5.2 text was that discovery for EST resources /.well-known/est of the Registrar is not needed anymore once the DTLS connection to the Registrar is already established. Also discovery of BRSKI resources /.well-known/brski is not needed once the DTLS connection is established. This all assumes the Pledge knows a single bootstrap method (BRSKI) and a single enrollment method (EST) so discovery wouldn't help the Pledge in any way.

One additional thought: to be able to reap the code size benefits of this (i.e. no more CoAP discovery code and parsing of link format code!) it is REQUIRED that the Registrar offers the EST resources at their "well-known" locations. Otherwise a Pledge without this discovery code might get stuck onboarding to a particular Registrar. (So a "SHOULD offer the well-known EST resources at the same port/DTLS-connection" is not strong enough - a MUST is required here for interoperability.)

Important in this is that the destination port of that DTLS connection could be a non-standard port as Peter mentioned earlier. This implies that the well-known/est resources are offered also at this non-standard port, which is noteworthy as the support for well-known resources by default assumes only the default scheme ports are supported. In our constrained-voucher draft we thus make an additional assumption on this.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links:

[1] https://github.com/anima-wg/constrained-voucher/issues/109#issuecomment-826582556 [2] https://github.com/notifications/unsubscribe-auth/ADCZGQJPLBXYA6KMQ2UAMMLTKUJAHANCNFSM43MKE6SQ