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

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Oct 2016 09:51:11 -0400

https://tools.ietf.org/html/draft-richardson-6tisch-dtsecurity-secure-join-01

This has a far more extensive section 2 -- Protocol Description.
Aside from many many details that need to be made more precise, there are
quite a number of major things missing:
  1) reference to draft-ietf-netconf-system-keychain-00, mapped to CBOR,
     along with some additions.
  2) EDHOC/DTLS considerations
  3) reference to ANIMA onwership voucher
  4) references to ANIMA Bootstrap certificate stuff.

In the process of creating this document, I created two other documents.
a) https://datatracker.ietf.org/doc/draft-richardson-6lo-ra-in-ie/
   This describes putting Router Advertisements in 802.15.4 Information Elements.
   Your comments in 6lo and 6tisch ML would be appreciated, and some
   discussion as to if and where this document goes.

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.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Oct 2016 08:38:54 +1300

On 21/10/2016 02:51, Michael Richardson wrote:
...
>    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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Oct 2016 14:00:44 +1300

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