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

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

On 14/11/2016 20:18, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>     >> > 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"
>     >>
>     >> okay.  The problem in 6tisch for proxy<->registrar communication
>     >> (admission control) is the TCP stack required.
> 
>     > Right. I've been assuming that a "BRSKI-COAP" method is available, and
>     > if we use GRASP Flood, no TCP is needed at the pledge side.
> 
> BRSKI-CoAP lets us do the *ENROLLMENT* over CoAP, not the discovery.

Yes, understood, my point was that since Flood is UDP, the pledge doesn't
need to do anything but listen for LL multicasts - no actual discovery
is neeeded. That seems like a bonus for pledges.

> These are the interactions, and I will try to give some names to the various
> interactions in a future document, but suggestions most welcome.
> 
> 1) pledge <-> Join Assistant (JA)
>    Discovery of JA:   mDNS and/or M_FLOOD

Is Join Assistant the agreed terminology (instead of Proxy)?
> 
> 2) Join Assistant *discovery* of Registrar
>    in 6tisch, omitted, will be provisioned
>    in ANIMA, uses GRASP M_DISCOVERY

Is it permissible for the Registrar to act as its own Join Assistant
for on-link neighbors? (I can't see why not.)

> 
> 3) Join Assistant tentative admission control (used in 6tisch, to provide
>    {optional?} "move along" feedback.).
>    6tisch, currently M_REQ_NEG/M_END over *TCP*, need to be fixed.
> 
> 4) pledge <-> Registrar.
>    in ANIMA, this is pledge---TCP/HTTPS---> Registrar (RFC7030)
>    in 6tisch-zero-touch, this is Registrar ---CoAP/DTLS--> pledge [maybe EDHOC]
>                    (CoMI: draft-ietf-netconf-keystore-00 )
>    in 6tisch-minimal-security, this is pledge-->CoAP/EDHOC--> Registrar
> 

Thanks, a useful summary.

   Brian