Subject: [Anima] autonomic bootstrap: gap analysis

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jun 2014 16:13:12 -0400

I recognize that bootstrap is only one of the autonomic mechanisms that
are relevant to this group.  I have much reading on the other aspects
which I hope to get done.

The 6tisch security design team has been working on a "zero-touch" mechanism
that would permit constrained devices to join a Lowpower/Loss Network (LLN)
in a secure way.   We have considered adapting EAP-TLS (as ZigbeeIP has
done), or turning the WirelessHART (IEC62591) packet flow into something more
IPv6-like.  While there are significant bits of design space to explore
while trying to optimize packet count, size and total energy risk of the
join protocol;  the idea that there should be a set of authorization tokens
From the device vendor which would permit the network and new nodes to
recognize each other has been central to all discussions.

while draft-pritikin-bootstrapping-keyinfrastructures and
      draft-behringer-autonomic-bootstrap-00

have proposed valid high level concepts, I believe that specification of the
authz token is critical for the IoT space.  A great concern that is that the
LLNs created remain operational for decades at a time, and that the
components can individually and also in aggregate be both (re-)sold,
and/or the service provider operating the network be replaced.

(There are real life examples where a part of a 100 square mile refinery
is actually sold to a competitor; obviously it doesn't get moved.  On the
other side, one has the very real risk that you bought your sensor network
From a "Nortel")

I was pointed at 802.1AR's device ID mechanism.  Really, 802.1AR is about an
API between a (constrained) device and it's cryptographic hardware
module/TPM.   It profiles a number of IETF PKIX specifications in a useful
way, but there is little there in terms of actual protocol.  When it comes to
what does an *DevID look like, in it's section 7.2.8, saying that the DN
should contain a "serialNumber" attribute:

   The formatting of this field shall contain a unique X.500
   Distinguished Name (DN). This may include the unique device serial number assigned by the manufacturer
   or any other suitable unique DN value that the issuer prefers.

What I have observed is that there needs to be a way to clearly delegate from
Factory(Vendor) to VAR to DISTRIBUTOR to RESELLER to Plant-OWNER to
SERVICE-PROVIDER.    It would significantly reduce the number of certificates
in (non-constrained device) databases for some levels of this hierarchy if
the IDevID were aggregateable in some fashion.  RFC3779 came to mind, which
deals with delegation of Autonomous Systems Numbers (ASN) and IP address
ranges from RIRs to LIRs to ISPs and Enterprises.
          RFC3779: X.509 Extensions for IP Addresses and AS Identifiers

I created:
    X509.v3 certificate extension for authorization of device ownership
                 draft-richardson-6tisch-idevid-cert-00

which cribbed together via nroff2xml and a search and replace.

The Pritikin and Behringer documents seem to assume that the ultimate goal of
the trusted enrollment process is to create a path in which "EST"= Enrollment
over Secure Transport could operate that would permit a new locally
significant certificate to be loaded into the new device.
I agree with that goal.

There is the question of how that trust circuit is created, and in discussion
it seemed that it involve some kind of leap-of-faith TLS setup which would be
authenticated by the "authz" tokens later on.  I disagree; I think that with
appropriate evaluation of path constraints that the authentication can occur
within the TLS protocol. (Even easier if done in IKEv2)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jun 2014 11:00:42 +1200

Michael's message is very interesting. For present purposes,
i.e. getting ready for the UCAN BOF, do we need to add some
points to the relevant use case draft
(http://tools.ietf.org/html/draft-behringer-autonomic-bootstrap)?

More generally - I think the AN protagonists have been thinking
of the scope of AN being carrier, enterprise, and home networks.
Should we add IoT to the scope? I think it's an important
question, because it would put new meanings on "simple" and
"available resources". It seems obvious that IoT networks need
to be completely autonomic, but is it the *same* autonomic?

Regards
   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 17 Jun 2014 06:19:14 +0000

>to be completely autonomic, but is it the *same* autonomic?

Indeed, the scope is an important question. For me, the answer rely on solution rather than autonomic concept. Every network, no matter what kind of network it is, has the requirements to be autonomic, or more and more autonomic. However, giving the differences of these networks, we may not be able to find a generic solution that suits all. It is time for us to start discuss the potential solution and their suitable scenarios. After then, we may know whether we can unify into the same autonomic network or we have to settle on more than one autonomic network architecture.

Regards,

Sheng

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 17 Jun 2014 06:59:00 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 17 June 2014 01:01
> To: [email-masked]
> Cc: 6tisch-security
> Subject: [Anima] Scope question [was: autonomic bootstrap: gap analysis]
> 
> Michael's message is very interesting. For present purposes, i.e. getting
> ready for the UCAN BOF, do we need to add some points to the relevant use
> case draft (http://tools.ietf.org/html/draft-behringer-autonomic-
> bootstrap)?
> 
> More generally - I think the AN protagonists have been thinking of the
> scope of AN being carrier, enterprise, and home networks.
> Should we add IoT to the scope? I think it's an important question, because
> it would put new meanings on "simple" and "available resources". It seems
> obvious that IoT networks need to be completely autonomic, but is it the
> *same* autonomic?

Brian, we have always positioned AN also in the IoT context, and I agree with Sheng, AN can be used everywhere. Especially when it comes to devices that will be deployed and managed in the thousands or even millions, autonomic concepts are a requirement, not a nice to have. 

We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a high-level solution in 6tisch. It explains how you CAN bootstrap a network, zero-touch AND secure, and fits perfectly to the 6tisch requirements. The corresponding use case is described in draft-behringer-autonomic-bootstrap. 

To me, the bootstrap problem is one of the real solid examples of autonomic behaviour, because to bootstrap a device into a network I MUST have some functionality on the devices, ie, distribution is absolutely mandatory here. 

So this is one of the criteria for the use cases: Is distribution a requirement? Because if it is, then this points very clearly to an autonomic solution. 

Michael

> > I recognize that bootstrap is only one of the autonomic mechanisms
> > that are relevant to this group.  I have much reading on the other
> > aspects which I hope to get done.
> >
> > The 6tisch security design team has been working on a "zero-touch"
> > mechanism that would permit constrained devices to join a
> Lowpower/Loss Network (LLN)
> > done), or turning the WirelessHART (IEC62591) packet flow into
> > something more IPv6-like.  While there are significant bits of design
> > space to explore while trying to optimize packet count, size and total
> > energy risk of the join protocol;  the idea that there should be a set
> > of authorization tokens From the device vendor which would permit the
> > network and new nodes to recognize each other has been central to all
> discussions.
> >
> > have proposed valid high level concepts, I believe that specification
> > of the authz token is critical for the IoT space.  A great concern
> > that is that the LLNs created remain operational for decades at a
> > time, and that the components can individually and also in aggregate
> > be both (re-)sold, and/or the service provider operating the network be
> replaced.
> >
> > (There are real life examples where a part of a 100 square mile
> > refinery is actually sold to a competitor; obviously it doesn't get
> > moved.  On the other side, one has the very real risk that you bought
> > your sensor network From a "Nortel")
> >
> > I was pointed at 802.1AR's device ID mechanism.  Really, 802.1AR is
> > about an API between a (constrained) device and it's cryptographic
> hardware
> > way, but there is little there in terms of actual protocol.  When it
> > comes to what does an *DevID look like, in it's section 7.2.8, saying
> > that the DN should contain a "serialNumber" attribute:
> >
> > in (non-constrained device) databases for some levels of this
> > hierarchy if the IDevID were aggregateable in some fashion.  RFC3779
> > came to mind, which deals with delegation of Autonomous Systems
> > Numbers (ASN) and IP address ranges from RIRs to LIRs to ISPs and
> Enterprises.
> > The Pritikin and Behringer documents seem to assume that the ultimate
> > goal of the trusted enrollment process is to create a path in which
> > "EST"= Enrollment over Secure Transport could operate that would
> > permit a new locally significant certificate to be loaded into the new
> device.
> > I agree with that goal.
> >
> > There is the question of how that trust circuit is created, and in
> > discussion it seemed that it involve some kind of leap-of-faith TLS
> > setup which would be authenticated by the "authz" tokens later on.  I
> > disagree; I think that with appropriate evaluation of path constraints
> > that the authentication can occur within the TLS protocol. (Even
> > easier if done in IKEv2)
> >
> > --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Jun 2014 07:21:03 +0000

I agree with Michael,

As IT and more specifically IEEE/IETF technology is getting pervasive, we need to simplify commissioning and deployment in a fundamental manner.

There are no CCIEs in an oil field or a deep mine in Alaska and still growing amounts of IP and Ethernet devices get deployed in all sorts of places, homes, curbs, factory floors, you name it, with a renewed interest in wireless monitoring.

6TiSCH targets at some of those environments and it clearly requires AN for use cases with huge scalability or ease-of-deployment constraints.

And certainly, the lack of CCIEs is more pervasive than just the WSN/6TiSCH...

Pascal

Le 17 juin 2014 à 08:59, "Michael Behringer (mbehring)" <[email-masked]> a écrit :

> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

---

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 17 Jun 2014 10:03:53 +0200

Dear Michael, all,

It's nice to see inputs/thoughts from very different domains (IoT) 
coming in!

Connected devices or entities are for sure in the scope of applicability 
for autonomic networking. And if we consider the future 5G networks, the 
number of connected "nodes" will be even more important and will put 
even more pressure on the (operators of the) networking infrastructures 
to cope with e.g. up-to-date/synchronized inventory (just to name one).
In this context, autonomic technologies definitely make sense: to 
address scalability, optimisation/adaptation of the control 
process/functions, coordination/orchestration among autonomic 
nodes/functions, etc).

If we speak IoT/Smart objects, I see a clear and easy first link with 
SmartHome (homenet), and as long as we see a _role_ for the network 
(thus the "_connecte__d_" x), and someone acting as an "operator" (not 
necessarily a classical telco carrier: e.g. who the homenet 
operator(s)?), there is a place for autonomic technologies.

What we can provide (ultimately)  is a (consistent/integrated?) set of 
autonomic/management tools for these very operators applicable in the 
different technological/industrial domains (smart homes, smart cities... 
and of course also "purely" telecommuncations networks). Of course one 
goal would be to not re-specify/develop the core solutions for all the 
different domains. This is very much in line with one of our goals in 
this BoF to identify commonalities that will drive the 
protocol/architecture work.
Autonomic networking will/should develop and provide both the 
procotols/mechanisms and the right (simple, extensible, composable) 
interfaces for operators to use them (in different domains).

As for the point on distribution, I don't know how to phrase it, but it 
is even more than a requirement, it is part of the nature of any 
networked environment: distributed in nature. So we will have to 
"attach" a number of basic/essential (autonomic) functionality to the 
(distributed) "nodes". Secured bootstrap is one. Others well-known ones 
could be (TBD): discovery, information exchange, capability negotiation, 
enforcement, group communications...

Best regards, Laurent.

On 17/06/2014 08:59, Michael Behringer (mbehring) wrote:
>> To:[email-masked]
>>> Michael Richardson<[email-masked]>, Sandelman Software
>> Works

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 NOZAY | France

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 17 Jun 2014 10:17:48 +0200

When speaking about bootstraping, does this have much in common with the
http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01
draft?
regards balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 17 Jun 2014 12:49:51 +0000

> From: Balazs Lengyel [mailto:[email-masked]]
> Sent: 17 June 2014 10:18
> To: Michael Behringer (mbehring); Brian E Carpenter; [email-masked]
> Cc: 6tisch-security
> Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap
> analysis]
> 

In a nutshell: 
draft-kwatsen-netconf-zerotouch-01 expects the config server URIs to be pre-provisioned. (If I understand it correctly, from section 4.1 - didn't read the whole doc, so correct me if I'm wrong). 
draft-pritikin-bootstrapping-keyinfrastructures does not require any pre-provisioning. The new device "learns" to which network it belongs, and will find the servers through discovery. 

Michael

> >> Michael's message is very interesting. For present purposes, i.e.
> >> getting ready for the UCAN BOF, do we need to add some points to the
> >> relevant use case draft
> >> More generally - I think the AN protagonists have been thinking of
> >> the scope of AN being carrier, enterprise, and home networks.
> >> Should we add IoT to the scope? I think it's an important question,
> >> because it would put new meanings on "simple" and "available
> >> resources". It seems obvious that IoT networks need to be completely
> >> autonomic, but is it the
> >> *same* autonomic?
> > Brian, we have always positioned AN also in the IoT context, and I agree
> with Sheng, AN can be used everywhere. Especially when it comes to
> devices that will be deployed and managed in the thousands or even
> millions, autonomic concepts are a requirement, not a nice to have.
> >
> > We have positioned draft-pritikin-bootstrapping-keyinfrastructures as a
> high-level solution in 6tisch. It explains how you CAN bootstrap a network,
> zero-touch AND secure, and fits perfectly to the 6tisch requirements. The
> corresponding use case is described in draft-behringer-autonomic-
> bootstrap.
> >
> > To me, the bootstrap problem is one of the real solid examples of
> autonomic behaviour, because to bootstrap a device into a network I MUST
> have some functionality on the devices, ie, distribution is absolutely
> mandatory here.
> >
> > So this is one of the criteria for the use cases: Is distribution a
> requirement? Because if it is, then this points very clearly to an autonomic
> solution.
> >
> > Michael
> >
> >
> >> Regards
> >>     Brian
> >>
> >>> something more IPv6-like.  While there are significant bits of
> >>> design space to explore while trying to optimize packet count, size
> >>> and total energy risk of the join protocol;  the idea that there
> >>> should be a set of authorization tokens From the device vendor which
> >>> would permit the network and new nodes to recognize each other has
> >>> been central to all
> >> discussions.
> >>> have proposed valid high level concepts, I believe that
> >>> specification of the authz token is critical for the IoT space.  A
> >>> great concern that is that the LLNs created remain operational for
> >>> decades at a time, and that the components can individually and also
> >>> in aggregate be both (re-)sold, and/or the service provider
> >>> operating the network be
> >> replaced.
> >>> moved.  On the other side, one has the very real risk that you
> >>> bought your sensor network From a "Nortel")
> >>>
> >>> comes to what does an *DevID look like, in it's section 7.2.8,
> >>> saying that the DN should contain a "serialNumber" attribute:
> >>>
> >>>     Distinguished Name (DN). This may include the unique device
> >>> serial
> >> number assigned by the manufacturer
> >>> The Pritikin and Behringer documents seem to assume that the
> >>> ultimate goal of the trusted enrollment process is to create a path
> >>> in which "EST"= Enrollment over Secure Transport could operate that
> >>> would permit a new locally significant certificate to be loaded into
> >>> the new
> >> device.
> >>> I agree with that goal.
> >>>
> >>> setup which would be authenticated by the "authz" tokens later on.
> >>> I disagree; I think that with appropriate evaluation of path
> >>> constraints that the authentication can occur within the TLS
> >>> protocol. (Even easier if done in IKEv2)
> >>>
> >>> --

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jun 2014 07:52:19 +1200

> Brian, we have always positioned AN also in the IoT context, and I agree with Sheng, AN can be used everywhere. Especially when it comes to devices that will be deployed and managed in the thousand…

Fully agree. But when I see people asking whether we will use YANG,
I find myself wondering about low-end devices in an IoT context.

    Brian

> .

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Jun 2014 15:00:10 -0500

Hi Michael,

I had a draft on this for quite longtime, the link is:

http://tools.ietf.org/html/draft-sarikaya-ace-secure-bootstrapping-00

you forgot to mention this one?

Behcet

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 18 Jun 2014 06:15:01 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Behcet
> Sarikaya
> Sent: 17 June 2014 22:00
> To: [email-masked]
> Cc: 6tisch-security
> Subject: Re: [Anima] autonomic bootstrap: gap analysis
> 
> Hi Michael,
> 

I missed that one. Will have a look now. Thanks for the pointer!

Michael

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Jun 2014 06:37:47 +0000

Hello Brian

>> with Sheng, AN can be used everywhere. Especially when it comes to devices
>> that will be deployed and managed in the thousands or even millions,
>> autonomic concepts are a requirement, not a nice to have.

> Fully agree. But when I see people asking whether we will use YANG, I find
> myself wondering about low-end devices in an IoT context.

6TiSCH uses YANG to model the configuration data of the 6top sublayer. 
There was no perceived contradiction between that modelling and the
 constrained environment that we are targeting for.

AN is definitely a key technology for large scale IoT applications. In the
specific use case of industrial, additional policies may still have to be applied
to impose zone and conduits structures, but the more autonomicity the
better.

Cheers,

Pascal

> Sent: mardi 17 juin 2014 21:52
> To: Michael Behringer (mbehring)
> Cc: 6tisch-security; [email-masked]
> with Sheng, AN can be used everywhere. Especially when it comes to devices
> that will be deployed and managed in the thousands or even millions,
> autonomic concepts are a requirement, not a nice to have.
> 
> Fully agree. But when I see people asking whether we will use YANG, I find
> myself wondering about low-end devices in an IoT context.
> 
>     Brian
> 
> corresponding use case is described in draft-behringer-autonomic-bootstrap.
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jun 2014 07:51:32 +1200

>  constrained environment that we are targeting for.

For those of us on the anima list that don't follow 6TiSCH in
detail, can you sketch out the boundary between the high level
model and the low end devices? (I fully recognise the advantage
of a high level model.)

    Brian