Re: [I2nsf] 答复: draft-qi-i2nsf-access-network-usecase-00

[Hannes Tschofenig <[e-mail]>]

Thanks for your quick response, Minpeng.

Wouldn't it be an implementation / deployment issue to decide how to run
the server-side infrastructure? (e.g., what virtualization technology to
use)

Currently, there are RESTful APIs defined to let these IoT devices (of
different classes) interact with the server-side infrastructure (at
least for the configuration management). Those APIs should be able to
work fine with any virtualization technology out there.

Is there anything else one would have to do?

Ciao
Hannes

On 11/25/2014 04:10 PM, Minpeng Qi wrote:
> Hi Hannes,
> 
> Thanks for sharing so many information and give recommendations.
> 
> 1. I'm not intended to involve too much details about access level procedure which usually could be seen transparently for upper layer protocol (e.g. DICE, CORE, etc.). And there is nothing wrong with current solution, but some operation issue.
> 
> For better understanding, I can set a similar example here by using DICE and DTLS in IoT device:
> Some assumption: First, let's suppose there are several kinds of IoT devices (e.g. class 1 type, class 2 type, and beyond class 2 type) which would occasionally connect to the network. Class 1 IoT devices can only run DICE for secure connection. Class 2 IoT devices can run DICE/DTLS for secure connection. Beyond class 2 IoT devices can run DTLS only for secure connection. Suppose there are ~4000 class 1 type devices, ~1000 class 2 type devices and ~5000 beyond class 2 type devices.
> Secondly, on the network side, due to cost or deployment problem, server could provide either DTLS or DICE connection. And suppose one server could connect ~1000 IoT devices. 
> So if we want to connect 4000 devices, network should prepare EIGHT servers: 4 servers for DICE connection for the case all class 1 type devices connected and 4 servers for DTLS connections for the case all beyond class 2 devices connected. What is more, class 2 devices could not choose which solution it could use when they connected to specific server. 
> However, if we can use virtualized network server, only FOUR servers with different instantiation is enough. If 4000 class 1 devices connected, the 4 servers could all be DICE applicable instantiation, while if 4000 beyond class 2 devices connected, the 4 servers could all be DTLS applicable instantiation. And class 2 devices have more flexibility to select preferred DICE/DTLS solution to use.
> 
> In short, it does not propose to enhance current solution, but willing to develop a solution for more flexible deployment.
> 
> 2. The motivation about configuration provisioning is: clients and servers could negotiate configuration as well as selection specific solutions in order to reduce the negotiation/handshake inside this specific solution procedure. You are right this have some overlap with ACE working group use case, but the solutions are not same. We are fine to keep it out of mind if there is consensus to make no duplication between these two solutions.
> 
> BRs,
> Minpeng
> 
> -----邮件原件-----
> 发件人: I2nsf [mailto:[e-mail]] 代表 Hannes Tschofenig
> 发送时间: 2014年11月25日 4:31
> 收件人: [e-mail]
> 主题: [I2nsf] draft-qi-i2nsf-access-network-usecase-00
> 
> Following the presentation at the last IETF meeting I read draft-qi-i2nsf-access-network-usecase-00 with a focus on the mentioned Internet of Things use cases.
> 
> The draft mentions Internet of Things in Section 3 as well but does not go into the details about the type of security (and configuration) provisioning.
> 
> Since we have been working on various Internet of Things related scenarios in other working groups (DICE, CORE, LWIG, ACE, etc.) it would be good to go into more details.
> 
> In particular, I would like to understand what is wrong with the currently developed solution. Maybe they do not provide the functionality needed or there are other use cases that have not been covered yet.
> 
> I would also suggest to look at the OMA Lightweight Machine-to-Machine specification since it provides provisioning capabilities and makes use of the IETF CoAP protocol. It also offers a number of cellular operator-based scenarios.
> 
> The specification can be found at:
> http://openmobilealliance.org/about-oma/work-program/m2m-enablers/
> 
> At the last IETF meeting my co-worker Michael Koster gave an overview talk that explained how CoAP, OMA LWM2M, and the IPSO objects fit together. The slides can be found here:
> http://www.slideshare.net/MichaelKoster/ietf91-ad-hoccoaplwm2mipso-41542196
> 
> Note also that this provisioning interface is rather generic and allows various parties to use it - not just network operators but also application providers.
> 
> It might also be worthwhile to note that
> 
> * when IoT devices execute network authentication then there is no user interaction (just a terminology issue since you are writing about users in your scenario),
> 
> * the street lighting deployments I am aware of do not use cellular technology but rather a multi-hop mesh network based on sub-Ghz IEEE
> 802.15.4 technology. For this reason it might be useful to go into more details with regard to the description of the scenario.
> 
> * when you use cellular radio technology then you would have the shared secret for the AKA algorithm already on the smart card and the credential provisioning happens during the manufacturing time.
> 
> * The story about configuring different key lengths is OK but we are currently working on a profile that tries to reduce the number of options as much as possible (at least when DTLS/TLS is used in the IoT context). This work happens in the IETF DICE working group.
> 
> * There could potentially be an overlap with the use cases we are investigating in the ACE working group. Please take a look at the use case document, which you can find at
> http://tools.ietf.org/html/draft-seitz-ace-usecases-02
> 
> Ciao
> Hannes
> 
> 
> 
> 
> 
> 
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>