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

From: peter van der Stok <[email-masked]>
Date: Tue, 01 Dec 2015 14:11:19 +0100

HI Michael,

The use case I like to be covered seems less complex than the ones you 
describe below.

Suppose:
A new building is installed with building equipment such as HVAC, 
lighting, etc.
Or an existing building is retrofit.
Cables are laid out, connected to equipment, Access Points are 
installed, 6LBRs are installed,
and wireless equipment connecting to the 6LBRs and APs is installed.
Cabling is tested and wrong connections are removed.

Assuming the cabling, the 6LBRs and APs are correctly installed, the 
network is powered up.
Assume most equipment is ANIMA enabled. The network is bootstrapped with 
factory security in place.
After bootstrap this is a perfect moment to decide whether the network 
(ACP) works or not.

Once the network is declared to work (satisfies the specification), 
additional service discovery, group declarations, application specific 
keying material can be installed.

Such a network will be composed of LLNs, and includes constrained 
devices.
Sleepy nodes (energy harvesting sensors) may include ANIMA services, but 
special provisions to include them in the network are more likely to be 
deployed.

For the moment I have no idea what ACP and Anima bootstrapping implies 
in terms of resources and resource consumption.
But excluding everything smaller than a tablet may be premature.

Peter

Michael Richardson schreef op 2015-11-30 22:39:
> peter van der Stok <[email-masked]> wrote:
>     > Hi Michael,
> 
>     > Your text proposal does not help me much.
> 
> Oh, I am sad.
> 
> peter van der Stok <[email-masked]> wrote:
>     >> +      <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>
> 
>     > 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
>     >> +          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>
>     >> +      </section>
> 
>     > I think the text about battery-powered or energy harvesting 
> devices is the
>     > more appropriate.
> 
> Agreed.
> 
>     > 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.
> 
> 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.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Dec 2015 08:11:17 +1300

Hi Peter,

On 02/12/2015 02:11, peter van der Stok wrote:
...
> Such a network will be composed of LLNs, and includes constrained devices.
> Sleepy nodes (energy harvesting sensors) may include ANIMA services, but special provisions to include them in the network are
> more likely to be deployed.
> 
> For the moment I have no idea what ACP and Anima bootstrapping implies in terms of resources and resource consumption.

ANs are basically nodes that participate in management actions that historically
would have been carried out by a centralised NMS or NOC. So in my view an individual
light switch isn't an AN but should be managed by an AN. The lighting controller
for a section of a building could be an AN. Or to say it another way, a node that
just does what it's told isn't an AN. (It may of course need a security bootstrap
anyway.)

However, indeed the resource question is important. An AN is going to need a
multi-threading OS, a full network stack, and a heap of software on top. For
example, GRASP alone is about 2500 lines of C (in the now-obsolete BUPT prototype)
and looks as if it will also be a couple of thousand lines of Python. Add to
that the ACP, the security bootstrap, and all the supporting code, before
you install any ASAs.

    Brian

---

From: peter van der Stok <[email-masked]>
Date: Wed, 02 Dec 2015 09:07:54 +0100

Hi Brian,

Brian E Carpenter schreef op 2015-12-01 20:11:
>> Sleepy nodes (energy harvesting sensors) may include ANIMA services, 
>> but special provisions to include them in the network are
> just does what it's told isn't an AN.
<pvds> Strictly speaking from a network management point of view?
In that case the numerous light controllers are probably not ANs.
However, the building control can (will) be part other networks, and the 
management of all these network components will include ANs.
For the moment these aspects are far from clear to me.
</pvds>
(It may of course need a
> security bootstrap
<pvds>
That's where my interest comes from. Listening to Max in Yokohama, where 
he explained his central table, I understood the bootstrap
and the accompanying ACP to realize a domain wide neighbor discovery 
including secure bootstrap (beyond single link or mesh); with apologies 
for my over-simplification.
The domain being (one of) the building control component(s) in the total 
network.
For the moment I did not see the need for a multi-threaded OS to realize 
this part.
Therefore my optimism that (this part of) Anima could be used to 
separate network installation responsibility from application 
installation responsibility.
</pvds>
> that the ACP, the security bootstrap, and all the supporting code, 
<pvds>
Therefore I will try to look for possibilities to install ACP with 
bootstrap in a given node without using all the other goodies.
Unless such a separation is unwanted, and my view needs to find 
expression elsewhere.
</pvds>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Dec 2015 13:19:08 +1300

On 02/12/2015 21:07, peter van der Stok wrote:

...
> <pvds>
> Therefore I will try to look for possibilities to install ACP with bootstrap in a given node without using all the other goodies.
> Unless such a separation is unwanted, and my view needs to find expression elsewhere.
> </pvds>

fwiw, I can certainly imagine a tiny subset of GRASP that only supports
client-side discovery/response, if that's what the bootstrap needs. We could
fit that in a smart light switch.

   Brian

---

From: peter van der Stok <[email-masked]>
Date: Thu, 03 Dec 2015 09:10:57 +0100

HI Brian,

So, I have a mission.

Peter

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 7 Dec 2015 22:47:26 +0000

> On Nov 25, 2015, at 8:14 AM, Michael Richardson <[email-masked]> wrote:
> 
> 
> 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

“to use ACE specified mechanisms”? 

This avoids trying to hint at what the mechanism might be. 

- max

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