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

[Laurent Ciavaglia <[e-mail]>]

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

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Research Manager | Project Manager

Network Algorithms, Protocols and Security Group

Bell Labs | Alcatel Lucent

phone: [phone]

email: [e-mail] 
<mailto:[e-mail]>

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

address: Route de Villejust | 91620 NOZAY | France