Re: [6tisch] [Anima] Scope question [was: autonomic bootstrap: gap analysis]

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Brian

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

> 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

> -----Original Message-----
> From: Anima [mailto:[e-mail]] On Behalf Of Brian E
> Carpenter
> Sent: mardi 17 juin 2014 21:52
> To: Michael Behringer (mbehring)
> Cc: 6tisch-security; [e-mail]
> Subject: Re: [Anima] Scope question [was: autonomic bootstrap: gap
> analysis]
> 
> On 17/06/2014 18:59, Michael Behringer (mbehring) wrote:
> >> -----Original Message-----
> >> From: Anima [mailto:[e-mail]] On Behalf Of Brian E
> >> Carpenter
> >> Sent: 17 June 2014 01:01
> >> To: [e-mail]
> >> 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.
> 
> 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
> 
> > 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
> >>
> >> On 17/06/2014 08:13, Michael Richardson wrote:
> >>> 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 <[e-mail]>, Sandelman Software
> >> Works
> >>> -= IPv6 IoT consulting =-
> >>>
> >> _______________________________________________
> >> Anima mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/anima
> > .
> >
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima