Subject: Re: [Anima] I-D Action: draft-vanderstok-constrained-anima-dtls-join-proxy-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Oct 2018 15:03:52 +1300

How does the constrained pledge discover the LL address of the constrained proxy?

Regards
   Brian Carpenter

On 2018-09-30 09:13, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Constrained Join Proxy for Bootstrapping Protocols
>         Authors         : Michael Richardson
>                           Peter van der Stok
>                           Panos Kampanakis
> 	Filename        : draft-vanderstok-constrained-anima-dtls-join-proxy-00.txt
> 	Pages           : 10
> 	Date            : 2018-09-29
> 
> Abstract:
>    This document defines a protocol to securely assign a pledge to an
>    owner, using an intermediary node between pledge and owner.  This
>    intermediary node is known as a "constrained-join-proxy".
> 
>    This document extends the work of
>    [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit-
>    proxy by a stateless constrained join-proxy, that uses IP
>    encapsulation.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-vanderstok-constrained-anima-dtls-join-proxy/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00
> https://datatracker.ietf.org/doc/html/draft-vanderstok-constrained-anima-dtls-join-proxy-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Peter van der Stok <[email-masked]>
Date: Fri, 05 Oct 2018 09:24:42 +0200

Hi Brian.

The answer consists of a selection of text of section 7 of the draft.
The discovery follows the standard coap discovery.
________________________________________________________________
The discovery of the Join-Proxy by the
   Pledge is an extension to the discovery described in section 4 of
   [I-D.ietf-anima-bootstrapping-keyinfra].  In particular this section
   replaces section 4.2 of [I-D.ietf-anima-bootstrapping-keyinfra].

   The Pledge can discover a Join-Proxy by sending a link-local
   multicast message to ALL CoAP Nodes with address FF01::FD.  Multiple
   or no nodes may respond.  The handling of multiple responses and the
   absence of responses follow section 4 of
   [I-D.ietf-anima-bootstrapping-keyinfra].

The presence and location of (path to) the join-proxy resource are
   discovered by sending a MC GET request to "/.well-known/core"
including
   a resource type (RT) parameter with the value "brski-proxy"
   [RFC6690].  Upon success, the return payload will contain the root
   resource of the Join-Proxy resources.

____________________________________________________________ Looking
forward to your comments and suggestions,

Peter
Brian E Carpenter schreef op 2018-10-05 04:03:

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Oct 2018 09:31:17 -0400

> How does the constrained pledge discover the LL address of the

Depends upon the target environment.

If ANIMA, then it would use GRASP, and probably we need to define an
extension to the AN_Proxy announcement as previously discussed.
I guess that extension could go into this document.

If 6tisch, then it would use enhanced beacons.
If something else, TBD.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Oct 2018 09:34:11 -0400

> [I-D.ietf-anima-bootstrapping-keyinfra].

That would be the all-CoAP solution where the pledge attracks attention to
iself.  I don't think it would be used in an ANIMA ACP situation, but I think
that Peter has some ideas where it would be useful.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Oct 2018 08:41:53 +1300

Peter,
> The answer consists of a selection of text of section 7 of the draft.

Huh? Section 7 is "security considerations" and the text you quote below
is nowhere in the draft. Maybe it's time for version -01 already?

Also, ff01::fd confuses me. It is not a link-local address - it is node-local.
I think you mean ff02::fd, which is link-local and belongs to COAP.

Regards
    Brian

---

From: Peter van der Stok <[email-masked]>
Date: Sat, 06 Oct 2018 11:46:44 +0200

Brian,

thanks,
A new version is in preparation, I forgot that it was not yet published.
The remark of Michael, that coap discovery is an extension to GRASP
discovery is also valid.
In the text, a mention about Grasp discovery will be inserted, and a
reference to constrained coap networks to motivate the coap discovery.
And indeed copying IP addresses is not my best side.

Greetings,

Peter