Re: [Anima-bootstrap] 6tisch join -01 documented posted

[Brian E Carpenter <[e-mail]>]

Hi Michael,

I said: TL;DR;WRL (will read later)

Well, now is "later". Two comments:

1. I seemed to recall from various corridor discussions in Berlin that
the anima-bootstrap preference was for a GRASP flooding model. However,
I have no strong preference; and in fact your approach could make more use
of GRASP than the flooding approach. But for discussion, here's the way
a flooded objective would look (i.e. the registrar floods it out to all
potential proxies (= Join Assistants).

objective = ["AN_Registrar", objective-flags, loop-count, [radius, priority, weight, method]]

method /= "BRSKI_TLS"
method /= "BRSKI_COAP"

radius = 0..255 ; the initial loop-count, so that the recipient can calculate
                ; the distance by subtraction

priority =      ; same semantics as mDNS priority
weight =        ; same semantics as mDNS weight

The IP address, protocol and port are supplied as part of the M_FLOOD message
(sorry, people who aren't familiar with draft-ietf-anima-grasp-07
won't get that).

My model was that the proxy would get all the floods available and choose
the one it liked best, based on the available method and distance, using the
weight and priority as for mDNS. (Personally I think the mDNS stuff is overkill,
but Toerless suggested we should be feature-equivalent.)

That's what is coded in Python at https://www.cs.auckland.ac.nz/~brian/graspy/brski/

Of course, since it's flooded there is no response, so I was assuming that
the pledge's IID would be part of the first actual BRSKI message.

2. Your CDDL looks OK to me. The format and semantics of the value field of
a GRASP objective are completely flexible, so I don't see a problem with
the first "request" to the Registrar being [IID, join-method]. The reply
from the registrar could be [IID, another-join-method] if it didn't like
the first one proposed. Once either side receives a join-method it likes,
it would send [M_END,,[O_ACCEPT]] and we're done.

3. Mini-question, is this really IPv6-specific? If not I'd prefer a name
that flags it as an AN infrastructure objective, e.g. "AN_Join"

Regards
   Brian

On 21/10/2016 08:38, Brian E Carpenter wrote:
> On 21/10/2016 02:51, Michael Richardson wrote:
> ...
>> b) https://datatracker.ietf.org/doc/draft-richardson-anima-6join-discovery/
>>    I wrote this document to reference from secure-join to explain the GRASP
>>    query that the Join Assistant will do to inform the Registrar about a new
>>    pledge.
>>
>>    I think that this document goes into draft-ietf-anima-bootstrapping-keyinfra.
>>
>>    Based upon some feedback on the anima list about how M_NEGOTIATE works,
>>    there are some major things wrong in this document when it comes to how an
>>    ANIMA Join Assistant would discover the *EST* port of the Registrar.
> 
> TL;DR;WRL (will read later)
> 
> I think you could look at my BRSKI toys (in Python) without needing to look at
> my actual GRASP code. They express my understanding of the options.
> 
> https://www.cs.auckland.ac.nz/~brian/graspy/brski/
> start with the README
> 
> Regards
>    Brian
>