Subject: [Anima] M_FLOOD vs M_DISCOVERY

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Jan 2017 12:27:30 -0500

We want to use GRASP to permit the bootstrap proxy to discover where the
Registrar(s) are.  As far as I can see there are really two options, and they
might not be mutually exclusive.

a) start a multicast M_DISCOVERY which will be propagated forward and can be
   answered from caches.
b) listen for an M_FLOOD.

As I see it there are advantages and disadvantages to each.

My take before was that M_DISCOVERY was to be preferred in most cases.
I'm really just writing to confirm this belief.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Jan 2017 08:19:56 +1300

> I'm really just writing to confirm this belief.

As always, it's a tradeoff. My impression after discussions some months ago
was the the BRSKI team preferred M_FLOOD, but I have no strong opinion.

Firstly, I assume that the registrar/proxy hookup can take place over the ACP,
because the nodes involved already have certificates and the ACP has formed itself.
(This will occur as an expanding circle around the registrar, which will proxy
for itself on its own link-local interfaces.) So from a security viewpoint,
there isn't much difference.

Secondly, the methods aren't mutually exclusive. If the "normal" method is
flooding an objective that I've called "AN_registrar" in my toy code,
nothing prevents discovery/synchronize being used as a backup.

That said, it seems that once a proxy has found a registrar, there's no
need for a regular refresh, so discovery seems appropriate. (Don't forget
that the discovery cache will time out, but that's standard.)

Send comments on https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives
We assumed the flooding model for registrar/proxy there, but described both models for
the pledge/proxy hookup.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Jan 2017 19:57:37 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> We want to use GRASP to permit the bootstrap proxy to discover where
    >> the Registrar(s) are.  As far as I can see there are really two
    >> options, and they might not be mutually exclusive.
    >>
    >> a) start a multicast M_DISCOVERY which will be propagated forward and
    >> can be answered from caches.  b) listen for an M_FLOOD.
    >>

    > As always, it's a tradeoff. My impression after discussions some months
    > ago was the the BRSKI team preferred M_FLOOD, but I have no strong
    > opinion.

We want M_FLOOD for discovery *OF* the proxy.
I'm asking about discovery *BY* the proxy *OF* the registrar.

    > Firstly, I assume that the registrar/proxy hookup can take place over
    > the ACP, because the nodes involved already have certificates and the
    > ACP has formed itself.  (This will occur as an expanding circle around
    > the registrar, which will proxy for itself on its own link-local
    > interfaces.) So from a security viewpoint, there isn't much difference.

Agreed.

    > Secondly, the methods aren't mutually exclusive. If the "normal" method
    > is flooding an objective that I've called "AN_registrar" in my toy
    > code, nothing prevents discovery/synchronize being used as a backup.

Question:  should all the internal objectives be AN_ ??

    > need for a regular refresh, so discovery seems appropriate. (Don't
    > forget that the discovery cache will time out, but that's standard.)

    > Send comments on
    > https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives We
    > assumed the flooding model for registrar/proxy there, but described
    > both models for the pledge/proxy hookup.

I intend to contribute to it this week.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Jan 2017 20:40:55 -0500

Michael Richardson <[email-masked]> wrote:
    bc> Secondly, the methods aren't mutually exclusive. If the "normal"
    bc> method is flooding an objective that I've called "AN_registrar" in my
    bc> toy code, nothing prevents discovery/synchronize being used as a
    bc> backup.

    > Question: should all the internal objectives be AN_ ??

https://github.com/anima-wg/anima-bootstrap/commit/853dc9334c6dcb0e6a9b199b846960be18a0504c

I will add this to the other document, and maybe I can learn how to better present
it.

This is the latest text I just wrote:

    <section anchor="discovery" title="Registrar Discovery Protocol Details">
      <t>
        The registrar responds to discovery messages from the proxy
        (or GRASP caches between them) as follows:
        <figure>
          <artwork><![CDATA[
objective         = ["AN_registrar", F_DISC, 255 ]
discovery-message = [M_DISCOVERY, session-id, initiator, objective]]]></artwork>

          <postamble>Figure 6: Registrar Discovery</postamble>
        </figure>
      </t>

      <t>
        The response from the registrar (or cache) will be a M_RESPONSE with the
        following parameters:<figure>
        <artwork><![CDATA[
response-message = [M_RESPONSE, session-id, initiator, ttl,
                   (+locator-option // divert-option), ?objective)]
initiator = ACP address of Registrar
locator1  = [O_IPv6_LOCATOR, fe80::1234, 6,  443]
locator2  = [O_IPv6_LOCATOR, fe80::1234, 17, 5683]
locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>

        <postamble>Figure 7: Registrar Response</postamble>
      </figure>
      </t>
    </section>

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Jan 2017 16:01:45 +1300

Regards
   Brian Carpenter

> I'm asking about discovery *BY* the proxy *OF* the registrar.

Understood (now, but not when I wrote my toy code or the draft).

> Question:  should all the internal objectives be AN_ ??

Personally I think that would be a helpful convention, but I'm not sure
we should have a *rule*.

> I intend to contribute to it this week.

Great. And where the assumptions are false, don't hesitate to say so.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Jan 2017 16:59:42 +1300

Two minor things:

[O_IPv6_LOCATOR, fe80::1234, 41, nil]

The address is represented as 128 bit quantity, bytes .size 16 in CDDL, so
it will actually just be an in6_addr in C terms. If you really want
to write it down, 0xfe800000000000000000000000001234

nil is a valid element in CDDL, but is there any reason not to use port 0?
It's explicitly reserved by IANA and it will avoid any type issues.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jan 2017 11:08:51 +1300

Michael,

You show the objective as ["AN_registrar", F_DISC, 255 ]
i.e. with a null value. SHouldn't it include a value field that indicates
the supported method(s)? I've been using values like "BRSKI-COAP" and
"BRSKI-TLS". Just relying on the port numbers seems a bit schlonky.

Regards
   Brian