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

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Nov 2016 08:08:21 +0900

Brian E Carpenter <[email-masked]> wrote:
    > 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.)

I never proposed that the Proxy would learn of the registrar via mDNS, btw.

    > 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"

okay.  The problem in 6tisch for proxy<->registrar communication (admission
control) is the TCP stack required.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2016 13:06:33 +1300

> 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.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Nov 2016 16:18:02 +0900

Brian E Carpenter <[email-masked]> wrote:
    >> 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.

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

2) Join Assistant *discovery* of Registrar
   in 6tisch, omitted, will be provisioned
   in ANIMA, uses GRASP M_DISCOVERY

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

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Nov 2016 16:44:25 +0900

<#secure method=pgpmime mode=sign>

to add to my own message:

Michael Richardson <[email-masked]> wrote:
    mcr> BRSKI-CoAP lets us do the *ENROLLMENT* over CoAP, not the discovery.

    mcr> These are the interactions, and I will try to give some names to the various
    mcr> interactions in a future document, but suggestions most welcome.

...

    mcr> 4) pledge <-> Registrar.
    mcr> in ANIMA, this is pledge---TCP/HTTPS---> Registrar (RFC7030)

It is here that https://datatracker.ietf.org/doc/draft-pritikin-coap-bootstrap/
applies, letting us actually run EST(RFC7030) over CoAP. Calling it BRSKI
over CoAP is perhaps slightly misleading, and yet slightly more correct,
because the document isn't a general EST over CoAP, but BRSKI specific.

--
]               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: Tue, 15 Nov 2016 08:28:25 +1300

> 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.

>    Discovery of JA:   mDNS and/or M_FLOOD

Is Join Assistant the agreed terminology (instead of Proxy)?
>    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.)

>    in 6tisch-minimal-security, this is pledge-->CoAP/EDHOC--> Registrar

Thanks, a useful summary.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Nov 2016 10:02:49 +0900

> Is Join Assistant the agreed terminology (instead of Proxy)?

I prefer it, and it's the accepted 6tisch terminology, but I don't think that
ANIMA has agreed to use that term, and is using Proxy.

    > for on-link neighbors? (I can't see why not.)

Yes, these are roles, not machines.

    > Thanks, a useful summary.

I'd like to give a name to each exchange.  BRSKI is clearly covers #4, but
arguably, it covers all four interactions, and #4 is the BRSKI mode of EST.