Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy

From: Toerless Eckert <[email-masked]>
Date: Sat, 8 Jul 2017 02:39:10 +0200

Seems i dropped the ball on these:

I am not sure i see the crucial need to be able to optimize the number of packets of periodic ACP and BRSKI announcements. 

Assume BRSKI, ACP and GRASP are diferent ASAs. We'd need a GRASP API feature to request coalescion of announcement. How would you define that API feature...

The idea was to use M_FLOOD for BRSKI because that would allow the pledge to be quiet. Which is more secure because pledge is potentially easy to attack.

For ACP i also have M_FLOOD in the text because thats the solution with just one message. No need for two-way handshake. 

Check out brians ani-objective. The alternative to M_FLOOD he lines out are more complicated.

Cheers
    Toerless

On Mon, Jun 19, 2017 at 09:36:04AM -0400, Michael Richardson wrote:
> 
> Brian E Carpenter <[email-masked]> wrote:
>     >> If a node doesn't want to announce itself as a proxy, it would omit that
>     >> objective.
>     >>
>     >> As for implementation, I've done it. It's a question of about a page
>     >> of C
>     >> code (given a cbor library), or about ten lines of ruby. Probably a
>     >> similar
>     >> number of lines of python.
> 
>     > I'm thinking that if we want to make a tiny extension to GRASP syntax for
>     > this special purpose, we can do so in the BRSKI document. That's yet
>     > another benefit of using CBOR.
> 
>      flood-message = [M_FLOOD, session-id, initiator, ttl,
>                      +[objective, (locator-option / [])]]
> 
> You added the +[] there so that we can announce multiple objectives.
> I don't think that there is anything more to do in GRASP.
> 
> All we need to do is define the AN_Proxy objective, and ACP has to
> define the AN_ACP objective.  I just don't see any problem here.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Jul 2017 13:48:16 +1200

> I am not sure i see the crucial need to be able to optimize the number of packets of periodic ACP and BRSKI announcements. 

Sure, unless we plan to flood these at a high rate, it isn't important; but
it's an option that GRASP provides.

> Assume BRSKI, ACP and GRASP are diferent ASAs. We'd need a GRASP API feature to request coalescion of announcement. How would you define that API feature...

If you had a monolithic implementation, it wouldn't be using the API. I think that
was Michael R's model. (Or you could roll up the proxy and the acp logic in a single
ASA, I guess. But I don't think it is a particularly good idea.)

> Check out brians ani-objective. The alternative to M_FLOOD he lines out are more complicated.

Actually I took them out of the latest (02) version, I think. Just flooding
for ACP and Proxy, and Synchronization for the Registrar. If you want the
Registrar to flood as well, that's easy too. Just tell me.

I'm updating my demo code too, but I was hoping to get the IPIP stuff clarified
first.

    Brian