Thanks for the input. In constrained-join-proxy-06 both discovery types are mentioned in section 5.1 and the sentence on DNS-SD actually refers to service discovery in general (of either a Join Proxy or a Registrar's join-port for JPY protocol). So an implementation could still decide to only allow discovery of the Registrar's join-port and not discovery of the Join Proxy (unprotected/"DULL" side).
Maybe good to know why mDNS/DNS-SD discovery is a bad idea on the unprotected side? Since we also do e.g. CoAP discovery on the unprotected side. (Is that a bad idea as well?) Regards Esko -----Original Message----- From: Anima <[email protected]> On Behalf Of Brian E Carpenter Sent: Thursday, December 2, 2021 20:23 To: Michael Richardson <[email protected]> Cc: [email protected] Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy On 03-Dec-21 07:01, Michael Richardson wrote: > > * While reviewing latest updates; one other issue came up: the draft (re > * latest in Github) currently mentions DNS-SD as a means for a Pledge to > * discover a Join Proxy. > > please note that this discovery occurs on the untrusted ("DULL") side. > > Brian E Carpenter <[email protected]> wrote: >> I think there's another reason for deferring it. We have a pending proposal >> in draft-eckert-anima-grasp-dnssd for how DNS-SD will integrate in an >> autonomic environment. It seems wise to have more clarity about that before >> defining how DNS-SD works for a Join Proxy. The two things may be >> completely orthogonal, but that requires a little thought. > > I don't think we can assume any GRASP or DNS-SD interoperation on the > untrusted side. It's just a bad idea. Yes. Probably that merits a MUST NOT in the Security Considerations of draft-eckert-anima-grasp-dnssd. Brian > > As for the Join Proxy discovering the Registrar, that's a different question. > We defined GRASP already for that. If we have a DNS-SD method as well, then > that would just be an additional method inside an ACP. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
