Subject: [Anima-bootstrap] IoT and scope of bootstrap

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Nov 2015 09:54:45 -0500

I wrote some text this morning to clarify how IoT is included/excluded.
see: https://github.com/ietf-roll/anima-bootstrap/commits/master
(maybe would have been cleaner had I made it a pull request).

I also added a note about ACE, which I'll put in another email.

+      <section title="Scope of solution">
+        <t>
+          Questions have been posed as to whether this solution is suitable
+          in general for Internet of Things (IoT) networks.  In general the
+          answer is no, but the terminology of <xref target="RFC7228" /> is
+          best used to describe the boundaries.
+        </t>
+        <t>
+          The entire solution described in this document is aimed in general
+          at non-constrained (i.e. class 2+) devices  operating on a
+          non-Challenged network.
+          The entire solution described here is not intended to be useable
as-is
+          by constrained devices operating on challenged networks (such as
+          802.15.4 LLNs).
+        </t>
+        <t>
+          In many target applications, the systems
+          involved are large router platforms with multi-gigabit
+          inter-connections, mounted in controlled access data centers.  But
+          this solution is not exclusive to the large, it is intended to
+          scale to thousands of devices located in hostile environments,
such
+          as ISP provided CPE devices which are drop-shipped to the end
user.
+          The situation where an order is fulfilled from distributed
+          warehouse from a common stock and shipped directly to the target
+          location at the request of the domain owner is explicitely
+          supported.  That stock ("SKU") could be provided to a number of
+          potential domain owners, and the eventual domain owner will not
+          know a-priori which device will go to which location.
+        </t>
+        <t>
+          Specifically, there are protocol aspects described here which
might
+          result in congestion collapse or energy-exhaustion of intermediate
+          battery powered routers in an LLN.  Those types of networks SHOULD
+          NOT use this solution.
+        </t>
+        <t>
+          The imprint protocol described here could, however, be used by
+          non-energy constrained devices joining a non-constrained network
+          (for instance, smart light bulbs are usually mains powered, and
+          speak 802.11).  It could also be used by non-constrained devices
+          across a non-energy constrained, but challenged network (such as
+          802.15.4).
+        </t>
+        <t>
+          Some aspects are in scope for constrained devices on challenged
+          networks: the certificate contents, and the process by which the
+          four questions above are resolved is in scope.  It is simply the
+          actual on-the-wire imprint protocol which is likely inappropriate.
+        </t>
+      </section>

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Nov 2015 10:14:57 -0500

I wrote this to deal with any overlap with ACE.
ACE's charter specifically has the bootstrap between constrained node and
non-constrained helper (whether client or authorization server) out of scope.

+      <section title="Trust bootstrap">
+        <t>
+          The imprint protocol results in a secure relationship between the
+          domain registrar and the new device.  If the new device is
+          sufficiently constrained that the ACE protocol should be leveraged
+          for operation, (see <xref target="I-D.ietf-ace-actors" />), and
the
+          domain registrar is also the Client Authorization Server or the
+          Authorization Server, then it may be appropriate to use this
secure
+          channel to exchange ACE tokens.
+        </t>
+      </section>
     </section>

I am uncomfortable with the words "ACE tokens", but I don't know what else to
write.  I mean the thing that would represent the trust between Client <-> CAS.
I think that this may also be out-of-scope.  I don't propose to make it
in-scope for ANIMA, but to make it clear that ANIMA bootstrap will have
created a (D)TLS connection which could be reused for something else.
Or a stateless TLS session-resumption token could be exchanged for later use
by ACE.

---

From: peter van der Stok <[email-masked]>
Date: Mon, 30 Nov 2015 09:49:53 +0100

Hi Michael,

Your text proposal does not help me much.

> +          best used to describe the boundaries.

The above text is much more restrictive than the text below.

> +          battery powered routers in an LLN.  Those types of networks 

I think the text about battery-powered or energy harvesting devices is 
the more appropriate.

What about text that formulates unwanted side effects coming from energy 
exhausted ("dead") nodes?
I don't think the dying of a node is allowed to jeopardize the 
functioning for other nodes or cause congestion, as your text suggests.

Some effort on getting this right is worthwhile, because I think the use 
of the anima Bootstrap may be interesting for the installation of large 
control networks, where
the verification of the correct functioning of the network as such is 
clearly separated from the correct functioning of the (control-) 
application on top.

Peter

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Nov 2015 16:39:58 -0500

> Your text proposal does not help me much.

Oh, I am sad.

    > The above text is much more restrictive than the text below.

So, my intention is to make people argue why IoT should be covered, rather
than assume it is unless not specified.

    >> +        <t>
    >> +          Specifically, there are protocol aspects described here which might

    > I think the text about battery-powered or energy harvesting devices is the
    > more appropriate.

Agreed.

    > I don't think the dying of a node is allowed to jeopardize the functioning
    > for other nodes or cause congestion, as your text suggests.

    > Some effort on getting this right is worthwhile, because I think the use of
    > the anima Bootstrap may be interesting for the installation of large control
    > networks, where
    > the verification of the correct functioning of the network as such is clearly
    > separated from the correct functioning of the (control-)
    > application on top.

Here is a use case that I imagine.

There is an existing LLN with a 6LBR and a backbone connection.
By construction, it has some energy constrained nodes in it, which function
just fine.

The LLN is to be expanded to service some new requirement. While the existing
6LBR can reach the new space, it won't work reliably enough, so a new 6LBR is
installed in the new space.  The 6LBR is ANIMA capable, and is mains powered,
and the new backhaul will be 802.11.  The new device doesn't have WEP/WPA
keys (and the AP doesn't speak ANIMA), but it does speak the 6tisch join
protocol, so it joins the existing LLN as a leaf.  Then, using the LLN, it
performs an *ANIMA* enrollment, with the LLN acting as a single "link" from
the ANIMA point of view.

Once enrolled, it has a domain specific certificate, has been provisioned
with the right WEP key, and can now enable the wifi as backbone.

Another use case might be a BFR in a cabinet that is being cabled up, but
said cables are not yet "lit".  It has been given a BTLE USB key into one of
it's USB slots usually intended for firmware updates.  The BFR does a pairing
over BTLE with the installers' smartphone, and using rfc7688, and connects to
the ACP that the smartphone is part of.  The BFR is now "up" enough for the
experts in the NOC to bring things up.  They might need to configure the
right lambdas for the 100G link to turn on... or instruct the cabling people
which cable goes into which port. (cables *never* get mis-labelled..)

In this context, the smartphone is energy constrained, and getting the ACP
off of it ASAP would be important.