Subject: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy

From: Toerless Eckert <[email-masked]>
Date: Tue, 21 Feb 2017 16:50:02 +0100

Hi Brian

In the anima bootstrap meeting we tried to figure out the necessary
GRASP message elements for discovery of registrars by proxies. And make
it extensible.

If you check:

http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true
578 - 608

We may have a bunch of different possible proxy behaviors:

  - TCP circuit proxy in conjunction with HTTPs
  - UDP proxy in conjunction with CoAP
  - IPinIP proxy in conjunction with either HTTPs or CoAP

MichaelR's text was currently suggesting to indicate in the GRASP message
what the registrar supports via the locators:

    locator1  = [O_IPv6_LOCATOR, fe80::1234, 6,  <any,eg:443>]
    locator2  = [O_IPv6_LOCATOR, fe80::1234, 17, <any,eg:5683>]
    locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]

The first line would indicate TCP circuit proxy, the second UDP proxy,
the third one IPinIP proxy.

I am quite uncomfortable to indicate the desired proxy behavior
purely via the IP protocol field in a locator (6, 17, 41). It already
is IMHO underspecified, eg: unclear why the UDP proxy would (only) support
CoAP, and what actually the IPinIP stack supports (CoAP, HTTPs, ...).

So, how/where would we most easily indicate the stack in the GRASP
response ? For example:

    locator1  = [O_IPv6_LOCATOR, fe80::1234, 6,  <any,eg:443>, tcp-circuit]
    locator2  = [O_IPv6_LOCATOR, fe80::1234, 17, <any,eg:5683>, coap-udp]
    locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil, tcp-ip-in-ip]
    locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil, coap-ip-in-ip]

Thanks!
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Feb 2017 08:44:49 +1300

Hi Toerless,

First of all, did you look at draft-carpenter-anima-ani-objectives-01
and https://www.cs.auckland.ac.nz/~brian/graspy/brski/ ?

I am not defending the details in those but they do indicate what's
possible with GRASP, and how I think this could be solved.

More below:

> http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true

That seems to go back to using discover/response. Wrong answer, IMHO; flooding
is simpler: fewer messages and richer semantics. I'm going to assume that below. 

>   - IPinIP proxy in conjunction with either HTTPs or CoAP

Sure. In the above, these are what I call the "method" amd they would be
defined by a text string name, which makes it easy to add new ones.
They could be anything; in my examples I used "BRSKI-TLS" and "BRSKI-COAP"
but "tcp-circuit" etc would work fine too. Whatever you want.
 
> CoAP, and what actually the IPinIP stack supports (CoAP, HTTPs, ...).

Correct. It's insufficient because it cannot separate the upper layer cases.

(Also, using link-local examples is an oversight, surely: this should
be an ACP address, e.g. fdab:dead:beef::1234, I think.)

>     locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil, coap-ip-in-ip]

No, that would be a protocol change by adding an extra field to the locator
syntax. However, this is already covered by a feature of the Flood message
which we added a while back. Each item in a flood message is optionally associated
with its own locator:

flood-message = [M_FLOOD, session-id, initiator, ttl, 
                 +[objective, (locator-option / [])]]

so we'd send several copies of the objective, each with its own "method"
and locator.

So for example we'd flood 
the objective ["AN_join_registrar", F_NEG, 6, ["tcp-circuit"]]
with locator  [O_IPv6_LOCATOR, fdab:dead:beef::1234, 6, 443]
and an objective ["AN_join_registrar", F_NEG, 6, ["coap-udp"]]
with the locator [O_IPv6_LOCATOR, fdab:dead:beef::1234, 17, 5683]

The could be sent all in one Flood message, or in separate ones,
possible from different sources if there were actually two registrars,

Truly, if you read the draft and eyeball the Python, you can see how it
works.

If you really don't want to use flooding, it gets more tricky. Discovery
alone won't do the trick in a simple way. I know how to do it but it will
involve more messages.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Feb 2017 11:08:02 -0500

Brian E Carpenter <[email-masked]> wrote:
    > That seems to go back to using discover/response. Wrong answer, IMHO;
    > flooding is simpler: fewer messages and richer semantics. I'm going to
    > assume that below.

What if the Registrar needs to be aware of the Join Proxy (prior to it making
use of it), and may need to do some (local) configuration or load balancing
in the decision to provide service to that proxy.

This seems to be a clear case where discovery ought to be used.

    > be an ACP address, e.g. fdab:dead:beef::1234, I think.)

Yes, exactly. It should be an ACP address.

    > possible from different sources if there were actually two registrars,

It seems like Flood responses and Responses ought to be interchangeable.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Feb 2017 08:15:14 +1300

> It seems like Flood responses and Responses ought to be interchangeable.

They are similar. But from my prototyping, I found Flood to be a more natural
semantic than Discovery/Response.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Feb 2017 08:19:15 +1300

Forgot something...

> in the decision to provide service to that proxy.

That seems a bit disjoint from "proxy needs to find registrar". And it definitely
sounds like a two-way conversation, which would more naturally be modelled as
a negotiation. Can you change that from a "what if?" to a more specific
requirement that we can model?

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 27 Feb 2017 19:29:44 +0100

> requirement that we can model?

+1. would like to see an exaple use-case requirement for this. If there is one, it would
make discovery procedures more complex because so far we are assuming that the easiest
scalable solution is for (large number of) proxies to discovery (few) registrars.

Toerless

-- 
---
[email-masked]