Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

From: Peter van der Stok <[email-masked]>
Date: Wed, 01 Dec 2021 10:13:38 +0100

HI Brian,

thanks, your remark is understood.
However, Esko made the right suggestion that a service name must be 
allocated for DNS-SD.
I think that is independent of your protocol draft.
This draft seems the best place to allocate the service names.

My intention is to write a phrase like:

For later discovery of Join Proxy and Registrar server to Join Proxy, 
using DNS-SD or mdns the service names are allocated in section x.x

section x.x

  Service Name: BRSKI-JP
  Transport Protocol(s): UDP
  Assignee: Peter van der Stok
  Contact: Peter van der Stok
  Description: service name of Join Proxy
  Reference [this document]
  Port Number: to be discovered.
  Known Unauthorized: Uses BRSKI porotocol

  Service Name: BRSKI-RJP
  Transport Protocol(s): UDP
  Assignee: Peter van der Stok
  Contact: Peter van der Stok
  Description: service name of Registrar server to Join Proxy
  Reference [this document]
  Port Number: to be discovered.
  Known Unauthorized: Uses BRSKI porotocol
  Agreed?

greetings,

Peter
Brian E Carpenter schreef op 2021-11-30 20:42:

> On 01-Dec-21 01:55, Esko Dijk 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.
>> 
>> But for DNS-SD discovery I believe a service name is needed; see RFC 
>> 6763 Section 7.  But there's no service name yet defined for a
> Join Proxy.
> 
>> Easiest solution would be to remove the entire DNS-SD sentence and 
>> reference.   I.e. defer this to a future document.
> 
> 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.
> 
> Brian
> 
>> If not removed, we probably need to add a service name registration 
>> for
> Constrained Join Proxy such that it can advertise its service and port 
> over DNS-SD/mDNS correctly.
> 
>> (Note: the above is unrelated to my earlier remark on requiring a 
>> service name for the Registrar's JPY protocol support. This could also
> be discovered over DNS-SD/mDNS but would need a separate service name.)
> 
>> Best regards
>> 
>> Esko
>> 
>> *IoTconsultancy.nl*  |  Email/Teams: [email-masked] 
>> <mailto:[email-masked]>    |
> +31 6 2385 8339
> 
>> _______________________________________________
>> Anima mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/anima
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Esko Dijk <[email-masked]>
Date: Wed, 1 Dec 2021 13:05:24 +0000

Hi Peter,

For me ok to include as well. (If registration is not included, we shouldn’t mention DNS-SD discovery, otherwise.)

You can take a look into https://datatracker.ietf.org/doc/html/rfc8995#section-8.6  which is a good template how the section should be formatted. (E.g. use lowercase, don’t include any optional fields, assignee and contact is IESG, etc.)

Esko

From: Anima <[email-masked]> On Behalf Of Peter van der Stok
Sent: Wednesday, December 1, 2021 10:14
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

HI Brian,

thanks, your remark is understood.
However, Esko made the right suggestion that a service name must be allocated for DNS-SD.
I think that is independent of your protocol draft.
This draft seems the best place to allocate the service names.

For later discovery of Join Proxy and Registrar server to Join Proxy, using DNS-SD or mdns the service names are allocated in section x.x

section x.x

 Service Name: BRSKI-JP

 Service Name: BRSKI-RJP

greetings,

Peter

Brian E Carpenter schreef op 2021-11-30 20:42:
On 01-Dec-21 01:55, Esko Dijk 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.

But for DNS-SD discovery I believe a service name is needed; see RFC 6763 Section 7.  But there’s no service name yet defined for a
Join Proxy.

Easiest solution would be to remove the entire DNS-SD sentence and reference.   I.e. defer this to a future document.

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.

    Brian

If not removed, we probably need to add a service name registration for
Constrained Join Proxy such that it can advertise its service and port over DNS-SD/mDNS correctly.

(Note: the above is unrelated to my earlier remark on requiring a service name for the Registrar’s JPY protocol support. This could also
be discovered over DNS-SD/mDNS but would need a separate service name.)

Best regards

Esko

*IoTconsultancy.nl*  |  Email/Teams: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>    |
+31 6 2385 8339

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Dec 2021 08:43:11 +1300

> I think that is independent of your protocol draft.

Well, I would like to hear that from Toerless, who wrote the DNS-SD draft. I agree that it seems to be orthogonal, but I'd like to be certain.

I agree with Esko's comments about the format. Lower case seems to be the 
de facto rule at https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=iesg&page=2

     Brian

>>> *IoTconsultancy.nl*  |  Email/Teams: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>    | 
>> +31 6 2385 8339
>>>
>>>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>
>>>
>>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Dec 2021 13:01:14 -0500

* 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-masked]> 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.

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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 3 Dec 2021 08:22:31 +1300

> 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

---

From: Esko Dijk <[email-masked]>
Date: Fri, 3 Dec 2021 13:54:33 +0000

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-masked]> On Behalf Of Brian E Carpenter
Sent: Thursday, December 2, 2021 20:23
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 4 Dec 2021 08:32:22 +1300

> Maybe good to know why mDNS/DNS-SD discovery is a bad idea on the unprotected side?

I think Michael's point was that *mixing* solutions while running insecurely
is a bad idea, since it increases the attack surface. (That's also why DULL
itself only allows a small subset of GRASP operations.)

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Dec 2021 17:26:43 -0500

> Since we also do e.g. CoAP discovery on the unprotected side. (Is that

It's not terrible, it's just that connecting the two sides makes no
(security) sense.

Also, in general, I'd rather we had fewer discovery methods on the
unprotected side.
(I also dislike "unprotected" to describe it.
This goes back decades as to whether the Internet or the LAN side of a
firewall is "red"...)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Esko Dijk <[email-masked]>
Date: Mon, 6 Dec 2021 11:20:36 +0000

> itself only allows a small subset of GRASP operations.)

Ok, agreed. Indeed I was thinking of deployments without DULL/GRASP where constrained-BRSKI is used. Then there are other methods of Join Proxy discovery as indicated in the join-proxy draft, e.g. by 15.4 beacons or MLE messages which I'm most familiar with. 
But CoAP discovery or DNS-SD could be used there in case there's no DULL/GRASP support intended. 

The Registrar can be discovered by the Join Proxy in different ways and one of these ways may be DNS-SD.

Esko

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Friday, December 3, 2021 20:32
To: Esko Dijk <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Anima] Constrained-join-proxy: use of DNS-SD discovery of a Join Proxy

    Brian