Subject: [Anima-signaling] JSONizing GDNP

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Jun 2015 11:21:54 +1200

Hi,

OK, trying to discover if I actually understand JSON and CBOR, I got as far
as the attached. Basically it's a take on what GDNP messages would look like
if expressed in JSON instead of traditional binary TLVs. It's probably full
of misconceptions, despite some assistance in the background from Joe and Bing.
Please look at it critically. And comment. Otherwise I will be forced to scehdule
a conf call during NZ working hours, and do any of you really want that?

There are three things in the attached document:-

- some sample messages expressed as JSON objects (corresponding to the toy example
I used in my slides in Dallas);

- a loose ABNFish grammar for the JSON equivalents of messages and options in
the current GDNP draft;

- a brief note on serializing the JSON objects in CBOR.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jun 2015 11:14:35 -0400

> a conf call during NZ working hours, and do any of you really want

I suggest you number your line. I think you've used unique resp:/disc: ids.

#2 {resp: 121212, {v6a:"fe80000000000000c0daac175f6d8e76"},
#3              {trust_relay, null, "draft-pritikin"}}

I'm nut sure that I understand what:
    {trust_relay, null, "draft-pritikin"}

means. I suspect that it's valid JSON, and that I just don't know JSON as
well as perhaps I think I do.  I think that it is equivalent to:
    {trust_relay: null,
     null: null,
     "draft-pritikin": null}

I read the Grammar, and I don't think that your GDNP messages are
a superset of JSON.  I do accept that your encodings could fit into CBOR
just fine.

But I suspect that you meant to say:
    {trust_relay: null, "draft-pritikin":null}

Req: 54321 also looks weird with the $100 having no tag.

{end: 54321, true}

maybe is supposed to say:
{end: 54321, result: true}

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jun 2015 12:56:41 -0400

The bootstrap design team is still bootstrapping, but Max, Toerless and I
have had three 1hr phone conferences (May 29 meeting cancelled). They have
been Friday at 1700UTC, but are now Thursday at 1400UTC, and will occur
June 11 as well.  A doodle poll to confirm a regular time will go out next
week once the list of parties has been identified.
I think that the AD still has to approve things.

We started with a discussion of the charter for the DT, and how it relates to
the charter for the WG, and the result is at:
    https://tools.ietf.org/wg/anima/trac/wiki/Bootstrap

the places where it says "OWN" means, it's in scope for this DT, where it
says REQUIRE, means that we are assuming it as input, and where it says
PROVIDE, means that they are outputs.

We continued with a recap discussion and partial walkthrough of
    draft-pritikin-anima-bootstrapping-keyinfra-01

We have some ideas about terminology that we think might be useful
along the lines of ducking/imprinting (cf: Konrad Lorenz and
http://en.wikipedia.org/wiki/Imprinting_(psychology) ), but we also thought
of fraternities and pledges.  If you didn't grow up with
http://en.wikipedia.org/wiki/Animal_House, or
http://en.wikipedia.org/wiki/Revenge_of_the_Nerds, then let me provide some
explanation.  The idea that during the bootstrap process, there is a period
when the network (the ACP aka fraternity) and the new node (the peldge) check
each other out for fitness.  Wikipedia says this about fraternities:
   Requirements may be imposed on those wishing to pledge either by the
   school or the organization itself, often including a minimum grade point
   average, wearing a pledge pin, learning about the history and structure of
   the organization, and performing public service. When a school places an age
   or tenure requirement on joining, this is called "deferred recruitment", as
   joining is deferred for a semester or year. The pledgeship period also serves
   as a probationary period in which both the organization and the pledge decide
   if they are compatible and will have a fulfilling experience.

In today's telecon, we discussed some of the 6tisch specific requirements on
bootstrap, specifically:
  1) the "pledges" (or joining nodes) are constrained in CPU, code space, and
     energy (if battery powered, etc)
  2) more importantly, the network is very constrained, 250Kbit/s max, 127
     byte fraglets, and 6tisch likely would be configured to further
     restricts the bandwidth in the network available to joining nodes.
     Calculations suggest that just transmitting a DH pair and associated
     parts between adjacent nodes could take between 2 and 40s.
  3) most protocols will require an authorization protocol that will need to
     travel through the LLN mesh up to a non-constrained node. The
     convergence of many such setup processes may well overwhelm the parts of
     the network closer to the root of the tree.  Congestion is an issue,
     and retransmissions cost energy.

I explained some the ideas/conclusions from
  draft-richardson-6tisch-security-architecture-02
and draft-richardson-6tisch--security-6top-04, which were:
  a) using CBOR encoded YANG over CoAP/DTLS leverages 6tisch ("6top") plans
     for 6tisch node/PCE communication, maximizing code reuse.

  b) initiating the secure bootstrap process from the non-constrained side,
     and having the constrained nodes remain silent after an initial "hello"
     packet, allowed the network manager to protect, conserve and prioritize
     the join bandwidth.

  c) it turns out there is an additional benefit in making the constrained
     node the TLS "Server" -- side. Specifically, it means that the selection
     of crypto parameters is done by the more constrained device, and the
     Server sends it's certificate payload first.  The non-constrained node
     (or "JCE" == Join Coordination Entity) will receive that certificate,
     and can consult whatever network (or human) resources is needs to
     before responding with a Client Certificate that will satisfy the
     constrained node.  It can also know via Trusted CA extension what
     certificate chain (if any) it needs to provide.

It is observed that point (c) is not essential; that a similiar thing can be
accomplished with less grace using SNI (RFC6066) and some other extensions.

Note that while 6tisch is/plans-to specify that 6top is the protocol that
runs over the resulting CoAP/DTLS channel, and that secure join to 6tisch
consists of provisioning certain identities and parameters through that
channel,  the resulting channel could be used for anything.

We also noted that in the context of two routers plugged in together on
a lonesome grassy knoll would need to form a secure connection; that one
needs to be the initiator ("client") and the other the responder ("server")
is obvious, but whether both systems need to always support both roles is
open for discussion.  Perhaps in the constrained case, it is acceptable that
constrained devices can always be responders, and in the non-constrained
case, they assume both roles.

I also note, recalling I was told that one implementation of the ACP consists
of IKEv2 initiated channels over IPv6-link-local addresses, that the
essential properties the bootstrap design team intends to provide work just
fine for IKEv2 as they do for DTLS.

I don't know if the ANIMA signaling protocol should occur before such a
channel is established, or inside of this (provisional) channel, or whether
it should instead run inside IKEv2 (maybe inside EAP).

I note that 6tisch has a few potential, "I am here" messages, with RPL
DAOs and Efficient-ND (E)AROs being the two ones.  GDNP or HNCP or just
IKE-port-500 messages are in my opinion also possibilities.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 4 Jun 2015 18:06:44 +0000

>    {trust_relay: null, "draft-pritikin":null}

Yes.  Either:

    ["trust_relay", null, "draft-pritikin"]

(where position in the list gives a semantic) or:

    { "trust_relay": null, "draft-pritikin": null }

in JSON, keys MUST be strings (e.g. not null), and must be quoted.

>{end: 54321, result: true}

Another thing to keep in mind with JSON (but not as much with CBOR) is that 54321 isn't actually a 64-bit integer in many implementations.  When that number goes over 2^53, it's going to start behaving more like a float, which has lead to real-world interop issues (e.g. when the 2^53+1'th tweet got tweeted, everyone's JavaScript Twitter client broke).

If you mean that to be a long-lasting identifier, make 54321 a string, at which point it may as well be hex or something.

-- 
Joe Hildebrand

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 4 Jun 2015 11:24:13 -0700

> in JSON, keys MUST be strings (e.g. not null), and must be quoted.

And then for JSON CBOR encoding we could convert keys to numeric or string
and assign numeric values for registered key values (right ?!).

Cheers
    Toerless

> -- 
> Joe Hildebrand
> 
> 
> 
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling

-- 
---
Toerless Eckert, [email-masked]

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 4 Jun 2015 18:27:14 +0000

>and assign numeric values for registered key values (right ?!).

Correct.  It's probably not worth doing interesting compression tricks in JSON; it's better to optimize for programmer discoverability and ensure your transport handles doc sizes > 1 MTU.  In CBOR, every byte often counts, balanced against code size.

-- 
Joe Hildebrand

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Jun 2015 14:15:02 +1200

Thanks for the various comments. I will have another bash at my document
as a result.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Jun 2015 14:32:11 +1200

Michael,

Thanks much for the summary. Let me grab at some low hanging targets...
On 05/06/2015 04:56, Michael Richardson wrote:
...

>> 1. Define the scope of "zero touch bootstrapping". 

This is critical. Anima signaling deals with the needs of Autonomic Service Agents,
not with the devices that they manage in a use-case specific way. So if the scope
of your effort is wider than just the devices capable of containing ASAs, the
constraints may change considerably.

...
> The idea that during the bootstrap process, there is a period
> each other out for fitness.  

We also need to support the case where there is no ACP, just some sort of CA,
so that we can use vanilla TLS (or maybe DTLS).

...
> it should instead run inside IKEv2 (maybe inside EAP).

The current assumption is that discovery of the nearest trust relay has to
take place in the clear (and that draft-pritikin may not be the only
method available, going forward). That would mean one cleartext multicast
and one cleartext unicast response via GDNP. If that response was forged,
the bootstrap process needs to fail.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Jun 2015 13:38:18 +1200

>     {trust_relay, null, "draft-pritikin"}

It's wrong. It should be
 {trust_relay: [null, "draft-pritikin"]}

i.e. a JSON object with a name and array of two values. I've missed out the
array brackets pretty much everywhere. Reset...

> well as perhaps I think I do.  I think that it is equivalent to:

No, "draft-pritikin" is just the second value in the trust_relay object;
it doesn't need to be an object in itself. If the bootstrap procedure
supported was different, it would be a different value.

> a superset of JSON.  

They aren't meant to be a superset; they are just meant to be valid
JSON text. But actually it was all broken...

> I do accept that your encodings could fit into CBOR
> just fine.
> 

That would need to be {end: [54321, {result: true}]}.
But {end: [54321, true]} is what I really meant.

Oops. The next version *will* validate at http://jsonlint.com/. Promise.

> If you mean that to be a long-lasting identifier, make 54321 a string, at which point it may as well be hex or something.

Got it. I'll leave it as an int for now, but this needs to be taken care of
if we switch to a JSON model.

> and assign numeric values for registered key values (right ?!).

Why is that less annoying than a TLV IANA registry? I'd prefer an algorithmic
encoding even if it costs a few bytes on the wire.

     Brian