idnits 2.17.1 draft-zhang-icnrg-icniot-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 34 instances of too long lines in the document, the longest one being 59 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2017) is 2476 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '31' is mentioned on line 726, but not defined == Unused Reference: '3' is defined on line 1063, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1108, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1141, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group Y. Zhang 3 Internet-Draft D. Raychadhuri 4 Intended status: Informational WINLAB, Rutgers University 5 Expires: January 17, 2018 L. Grieco 6 Politecnico di Bari (DEI) 7 S. Sabrina 8 Universita degli studi dell Insubria 9 H. Liu 10 The Catholic University of America 11 S. Misra 12 New Mexico State University 13 R. Ravindran 14 G. Wang 15 Huawei Technologies 16 July 16, 2017 18 ICN based Architecture for IoT 19 draft-zhang-icnrg-icniot-architecture-01 21 Abstract 23 The Internet of Things (IoT) technology promises to connect billions 24 of objects to Internet. Today, the IoT landscape is very fragmented 25 from both the technology and service perspectives. As a consequence, 26 it is difficult to integrate and cross-correlate data coming from the 27 heterogeneous contexts and build value-added services on top. This 28 reason has motivated the current trend to develop a unified de- 29 fragmented IoT architecture so that objects can be made accessible to 30 applications across organizations and domains. Several proposals 31 have been made to build a unified IoT architecture as an overlay on 32 top of today's Internet. Such overlay solutions, however, inherit 33 the existing limitations of the IP protocol: mobility, security, 34 scalability, and communication reliability. To address this problem, 35 A unified IoT architecture based on the Information Centric 36 Networking (ICN) architecture, which we call ICN-IoT [1] has been 37 proposed. ICN-IoT leverages the salient features of ICN, and thus 38 provides seamless device-to-device (D2D) communication, mobility 39 support, scalability, and efficient content and service delivery. 40 Furthermore, in order to guarantee the real diffusion of ICN-IoT 41 architecture it is fundamental to deal with self-configuring features 42 such as device onboarinding and discovery, service discovery, 43 scalability, security and privacy requirements, content 44 dissemmination since the IoT system will comprise of diverse 45 applications with heterogenous requirements including connectivity, 46 resource constraints and mobility. Towards this, the draft 47 elaborates on a set of middleware functions to enable large operation 48 of an ICN-IoT deployment. 50 This draft begins by motivating the need for an unified ICN-IoT 51 architecture to connect heterogeneous IoT systems. We then propose 52 an ICN-IoT system architecture and middleware components which 53 includes device/network-service discovery, naming service, IoT 54 service discovery, data discovery, user registration, and content 55 delivery. For all of these components, discussions for secure 56 solutions are offered. We also provide discussions on inter- 57 connecting heterogeneous ICN-IoT domains. 59 Status of This Memo 61 This Internet-Draft is submitted in full conformance with the 62 provisions of BCP 78 and BCP 79. 64 Internet-Drafts are working documents of the Internet Engineering 65 Task Force (IETF). Note that other groups may also distribute 66 working documents as Internet-Drafts. The list of current Internet- 67 Drafts is at http://datatracker.ietf.org/drafts/current/. 69 Internet-Drafts are draft documents valid for a maximum of six months 70 and may be updated, replaced, or obsoleted by other documents at any 71 time. It is inappropriate to use Internet-Drafts as reference 72 material or to cite them other than as "work in progress." 74 This Internet-Draft will expire on January 17, 2018. 76 Copyright Notice 78 Copyright (c) 2017 IETF Trust and the persons identified as the 79 document authors. All rights reserved. 81 This document is subject to BCP 78 and the IETF Trust's Legal 82 Provisions Relating to IETF Documents 83 (http://trustee.ietf.org/license-info) in effect on the date of 84 publication of this document. Please review these documents 85 carefully, as they describe your rights and restrictions with respect 86 to this document. Code Components extracted from this document must 87 include Simplified BSD License text as described in Section 4.e of 88 the Trust Legal Provisions and are provided without warranty as 89 described in the Simplified BSD License. 91 Table of Contents 93 1. ICN-Centric Unified IoT Architecture . . . . . . . . . . . . 3 94 1.1. Strengths of ICN-IoT . . . . . . . . . . . . . . . . . . 4 95 2. ICN-IoT System Architecture . . . . . . . . . . . . . . . . . 6 96 3. ICN-IoT Middleware Architecture . . . . . . . . . . . . . . . 7 97 4. ICN-IoT Middleware Functions . . . . . . . . . . . . . . . . 9 98 4.1. Device Onboarding and Discovery . . . . . . . . . . . . . 10 99 4.2. Detailed Discovery Process . . . . . . . . . . . . . . . 11 100 4.3. Naming Service . . . . . . . . . . . . . . . . . . . . . 14 101 4.4. Service Discovery . . . . . . . . . . . . . . . . . . . . 16 102 4.5. Context Processing and Storage . . . . . . . . . . . . . 17 103 4.6. Publish-Subscribe Management . . . . . . . . . . . . . . 19 104 4.7. Security . . . . . . . . . . . . . . . . . . . . . . . . 22 105 5. Support to heterogeneous core networks . . . . . . . . . . . 23 106 5.1. Interoperability with IP legacy network . . . . . . . . . 23 107 5.2. Named protocol bridge . . . . . . . . . . . . . . . . . . 23 108 5.3. Inter-domain Management . . . . . . . . . . . . . . . . . 23 109 6. Informative References . . . . . . . . . . . . . . . . . . . 24 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 112 1. ICN-Centric Unified IoT Architecture 114 In recent years, the current Internet has become inefficient in 115 supporting rapidly emerging Internet use cases, e.g., mobility, 116 content retrieval, IoT, contextual communication, etc. As a result, 117 Information Centric Networking (ICN) has been proposed as a future 118 Internet design to address these inefficiencies. ICN has the 119 following main features: (1) it identifies a network object 120 (including a mobile device, a content, a service, or a context) by 121 its name instead of its IP address, (2) a hybrid name/address 122 routing, and (3) a delay-tolerant transport. These features make it 123 easy to realize many in-network functions, such as mobility support, 124 multicasting, content caching, cloud/edge computing and security. 126 Considering these salient features of ICN, we propose to build a 127 unified IoT architecture, in which the middlware IoT services are 128 proposed for administrative purposes such as towards onboarding 129 devices, device/service discovery and naming. Other functions such 130 as name publishing, discovery, and delivery of the IoT data/services 131 is directly implemented in the ICN network. Figure 1 shows the 132 proposed ICN-IoT approach, which is centered around the ICN network 133 instead of today's Internet. 135 ______________ __________ __________ 136 |IoT Smart Home| |IoT Smart | |IoT Smart | 137 |Management | |Transport | |Healthcare| 138 |______________| |Management| |Management| 139 \ |__________| |__________| 140 \ | / 141 \ _____________|___________ / 142 { } 143 { } 144 { ICN } 145 { } 146 {_________________________} 147 / | \ 148 / | \ 149 _________/ ________|______ __\_____________ 150 { } { } { } 151 {Smart home} {Smart Transport} {Smart Healthcare} 152 {__________} {_______________} {________________} 153 | | | | | | 154 ___|__ __|___ __|__ __|__ ____|____ ____|____ 155 |Home-1||Home-2| |Car-1||Car-2| |Medical ||Medcical | 156 |______||______| |_____||_____| |Devices-1||Devices-2| 157 |_________||_________| 159 Figure 1: The proposed ICN-IoT unified architecture. 161 1.1. Strengths of ICN-IoT 163 Our proposed ICN-IoT architecture delivers IoT services over the ICN 164 network, which aims to satisfy the requirements of the open IoT 165 networking system (discussed in the ICN-IoT design considerations 166 draft [1]): 168 o Naming. In ICN-IoT, we assign a unique name to an IoT object, an 169 IoT service, or even a context. These names are persistent 170 throughout their scopes. 172 o Security and privacy. In ICN-IoT, secure binding between names 173 and data objects instead of IP addresses to identify devices/data/ 174 services, is inherently more secure than the traditional IP 175 paradigm [16]. 177 o Scalability. In ICN-IoT, the name resolution is performed in the 178 network layer in an online or using a mapping system with name 179 state distributed within the entire network. Thus, it can achieve 180 high degree of scalability exploiting features like content 181 locality, local computing, and multicasting. 183 o Resource efficiency. In ICN-IoT, in both the constrained and non- 184 constrained parts of the network, only those data that are 185 subscribed by applications or requested by clients in the 186 specified context will be delivered. Thus, it offers a resource- 187 efficient solution. 189 o Local traffic Pattern. In ICN-IoT, we can easily cache data or 190 deploy computation services in the network, hence making 191 communications more localized and reducing the overall traffic 192 volume. 194 o Context-aware communications. ICN-IoT supports contexts at 195 different layers, including device layer, networking layer and 196 application layer. Contexts at the device layer include 197 information such as battery level or location; contexts at the 198 network layer include information such as network status and 199 statistics; contexts at the application layer are usually defined 200 by individual applications. In ICN-IoT, device context may be 201 available to the network layer, while network elements (i.e., 202 routers) are able to resolve application-layer contexts to lower- 203 layer contexts. As a result of adopting contexts and context- 204 aware communications, communications only occur under situations 205 that are specified by applications, which can significantly reduce 206 the network traffic volume. 208 o Seamless mobility handling. In ICN-IoT, ICN's name resolution 209 layer allows multiple levels of mobility relying on receiver- 210 oriented nature for self-recovery for consumers, and using 211 multicasting and late-binding techniques to realize seamless 212 mobility support of the producing nodes. 214 o Self-Organization: Name based networking allows service level self 215 configuration and bootstrapping of devices with minimal 216 manufacturer or administrator provisioned configuration. This 217 configuration involves naming, key distribution and trust 218 association to enable data exchange between applications and 219 services. 221 o Data storage and Caching. In ICN-IoT, data are stored locally, 222 either by the mobile device or by the gateway nodes or at service 223 points. In-network caching [4] also speeds up data delivery and 224 also offer local repair over unreliable links such as over 225 wireless mediums. 227 o Communication reliability. ICN-IoT supports delay tolerant 228 communications [23], which in turn provides reliable 229 communications over unreliable links as mentioned earlier. Also 230 opportunistic caching allows to increase the content copies in the 231 network to help consumers with diverse application requirements 232 (such as operating at different request rates) or situations 233 dealing with mobility scenarios. 235 o Ad hoc and infrastructure mode. ICN-IoT supports both 236 applications operating in ad-hoc [2] and infrastructure modes. 238 o In-network processing. ICN offers in-network processing that 239 supports various network services, such as context resolution, 240 data aggregation and compression. 242 2. ICN-IoT System Architecture 244 The ICN-IoT system architecture, which is also a general abstraction 245 of an IoT system, is shown in Figure 2, has the following six main 246 system components: 248 +----------------+ +-----------------+ +-----------------+ +------------------+ +----------------------+ 249 |Embedded System | <--> | Aggregator | <--> | Local Service | <--> | IoT Server | <--> |Authentication Manager| 250 +----------------+ +-----------------+ | Gateway | | | | | 251 | | +-----------------+ +------------------+ +----------------------+ 252 | | ^ ^ 253 +----------------+ +----------------+ | | 254 | Embedded System| |Aggregator | <------------ V 255 +----------------+ +----------------+ +-------------------+ 256 | Services/Consumers| 257 +-------------------+ 259 Figure 2: ICN-IoT System Architecture 261 o Embedded Systems (ES): The embedded sensor has sensing and 262 actuating functions and may also be able to relay data for other 263 sensors to the Aggregator, through wireless or wired links. 265 o Aggregator: It interconnects various entities in a local IoT 266 network. Aggregators serve the following functionalities: device 267 discovery, service discovery, and name assignment. Aggregators 268 can communication with each other directly or through the local 269 service gateway. 271 o Local Service Gateway (LSG): A LSG serves the following 272 functionalities: (1) it is at the administrative boundary, such 273 as, the home or an enterprise, connecting the local IoT system to 274 the rest of the global IoT system, (2) it serves to assign ICN 275 names to local sensors, (3) it enforces data access policies for 276 local IoT devices, and (4) it runs context processing services to 277 generate information specified by application-specific contexts 278 (instead of raw data) to the IoT server. 280 o IoT Server: Within a given IoT service context, the IoT server is 281 a centralized server that maintains subscription memberships and 282 provides the lookup service for subscribers. Unlike legacy IoT 283 servers that are involved in the data path from publishers to 284 subscribers -- raising the concern of its interfaces being a 285 bottleneck -- the IoT server in our architecture is only involved 286 in the control path where publishers and subscribers exchange 287 their names, certificates, and impose other security functions 288 such as access control. 290 o Authentication Manager (AM): The authentication manager serves to 291 enable authentication of the embedded devices when they are 292 onboarded in the network and also if their identities need to be 293 validated at the overall system level. The authentication manager 294 may be co-resident with the LSG or the IoT server, but it can also 295 be standalone inside the administrative boundary or outside it. 297 o Services/Consumer: These are other application instances 298 interacting with the IoT server to fetch or be notified of 299 anything of interest within the scope of the IoT service. 301 The logical topology of the IoT system can be mesh-like, with every 302 ES attached to one or more aggregators or to another ES, while every 303 aggregator is attached to one or more LSG and all the LSGs connected 304 to the IoT server. Thus, each ES has its aggregators, and each of 305 which in turn has its LSG. All ES belonging to the same IoT service 306 share the same IoT server. All the aggregators that are attached to 307 the same LSG management are reacheble to to one another hence capable 308 of requesting services or content from them. While such richer 309 connectivity improves reliability, it also requires control plane 310 sophistication to manage the inter-connection. Though our discussion 311 can be generalized to such mesh topologies, in the rest of the draft, 312 we will focus on the tree topology for the sake of simplicity. 314 3. ICN-IoT Middleware Architecture 316 The proposed ICN-IoT middleware aims to bridge the gap between 317 underlying ICN functions, IoT applications and devices to achieve 318 self-organizing capability. 320 The middleware functions are shown in Fig. 3 and it includes six core 321 functions: device discovery, naming service, service discovery, 322 context processing and storage, pub/sub management, and security 323 which spans all these functions. 325 In contrast to centralized or overlay-based implementation in the 326 legacy IP-based IoT platform, ICN-IoT architecture pushes a large 327 portion of the functionalities to the network layer, such as name 328 resolution, mobility management, in-network processing/caching, 329 context processing, which greatly simplifies the middleware design. 331 +------------------------------------+ 332 | (IoT Middleware) | 333 | | 334 | +----------------------+ +--+ | 335 | | Pub/Sub Management | | | | +---------------------+ 336 | +----------------------+ | | | | Consumer | 337 +-------------+ | |Context Processing and| |S | | | +-------------+ | 338 | | | | Storage | |E | | | | | | 339 | Sensor | | +----------------------+ |C | | | | App | | 340 + ----------- + | |IoT Service Discovery | |U | | | +-------------+ | 341 |Gateway |<--> | | | |R | | <--> | | Service | | 342 +-------------+ | +----------------------+ |I | | | +-------------+ | 343 |Actuator | | | Naming Service | |T | | +---------------------+ 344 +-------------+ | +----------------------+ |Y | | 345 |Smart thing | | | Device Onboarding | | | | 346 +-------------+ | | and Discovery | | | | 347 | +----------------------+ +--+ | 348 +------------------------------------+ 349 ^ ^ 350 | | 351 V V 352 +---------------------------------------------+ 353 | ICN Network | 354 | +-------------------------------------+ | 355 | | In-network Computing | | 356 | | (Data Aggregation/Fusion) | | 357 | +-------------------------------------+ | 358 | | Network Service | | 359 | | (Multicast/Push/Pull) | | 360 | +-------------------------------------+ | 361 | | Name Based Routing | | 362 | +-------------------------------------+ | 363 | | Mobility and Security | | 364 | +-------------------------------------+ | 365 +---------------------------------------------+ 367 Figure 3: The ICN-IoT Middleware Functions 369 4. ICN-IoT Middleware Functions 371 For each of these middleware functions we highlight what these 372 function achieve, advantages an ICN architecture enables in realizing 373 each function, and provide discussion of how the function can be 374 realized considering two ICN protocols i.e. NDN [6] and MobilityFirst 375 (MF) [5]. 377 Please note most of these middleware functions are implemented on 378 unconstrained aggregators, LSGs and the IoT servers, only very 379 limited functions (mainly for device discovery and naming service) 380 are implemented on resource-constrained ES, while unconstrained 381 devices within an aggregator can execute more functions such as 382 service discovery. 384 4.1. Device Onboarding and Discovery 386 In the literature several works do not differentiate between device 387 onboarding and device discovery. In this draft, we make a 388 distinction. The objective of onboarding is to connect new devices 389 to the rest and enable them to operate in the ecosystem. Every 390 entity should be exposed to its direct upstream neighbor and may be 391 another embedded system or aggregator. Specifically, it includes the 392 following three aspects: (1) a newly added ES should be exposed to 393 its neighbor (ES or aggregator) and possibly to its LSG, AM, and the 394 IoT server; (2) a newly added aggregator is exposed to its LSG, and 395 possibly to its neighbor aggregators; (3) a newly added AM should be 396 exposed to the IoT server and the LSG; and (4) a newly added LSG 397 should be exposed to the IoT server. Device discovery serves two 398 functions: 1) it is used in the context of discovering neighboring 399 ESs to form routing paths, where existing mechanims can be use; 2) 400 for device onboarding, on which we focus here. During onboarding, 401 the ES passes its device-level information (such as manufacturer-ID 402 and model number) and application-level information (such as service 403 type and data type) to the upstream devices. In the NDN architecture 404 (and other name-based approaches), there is no need to identify the 405 devices with IDs. But, if the device is required to have a globally 406 unique ICN ID, it can be provided one by the naming service 407 (described in Section 4.3), and recorded by the LSG (and possibly the 408 aggregator and the IoT server). As part of the device discovery 409 process, each ES will also be assigned a local network ID (LID) that 410 is unique in its local domain. Then the device will use its LID for 411 routing within the local domain (i.e. between ESs and the 412 aggregator) because the globally unique ICN ID associated with a 413 device is quite long and not energy efficient for constrained IoT 414 devices. One approach to generate a short LID is to hash its 415 persistent ID. In the name-based ICN approaches where device 416 identity is not needed, a device can publish within the name scope of 417 the aggregator (e.g., /iot/agg1/dev10 for Device numbered 10 under 418 aggregator numbered 1). In most IoT systems, devices interact with 419 the aggregator for data or information processing or aggregation, 420 hence there is no direct communication between devices under an 421 aggregator. If in some set-up devices under the aggregator need to 422 communicate with each other a scalable mechanism is to allow direct 423 neighbors to communicate with each other while others communicate 424 through the aggregator. 426 ICN enables flexible and context-centric device discovery which is 427 important in IoT ecosystem where heterogeneous IoT systems belonging 428 to different IoT services may co-exist sharing the same wireless 429 resources. Contextualization is a result of name-based networking 430 where different IoT services can agree on unique multicast names that 431 can be pre-provisioned in end devices and the network infrastructure 432 using the routing control plane. This also has an advantage of 433 localizing device discovery to regions of network relevant to an ICN 434 service, also enabling certain level of IoT asset security by 435 isolation. In contrast IP offers no such natural IoT service 436 mapping; any forced mapping of this manner will entail high 437 configuration cost both in terms of device configuration, and network 438 control and forwarding overhead. 440 4.2. Detailed Discovery Process 442 A device can be an embedded device, a virtual device, a process, or a 443 service instance such as a sensing service. We assume that the 444 device has pre-loaded secure keys. Specifically, we consider both 445 resource-constrained devices and resource-rich devices, and assume 446 that the pre-loaded secure keys are symmetric keys or passwords for 447 the former, while the asymmetric key pair (public key certificate and 448 the corresponding private key) for the latter. 450 Below we discuss the detailed device discovery process considering 451 both resource-constrained devices and resource-rich devices. As 452 assumed for the former there is a mechanism for either securely pre- 453 loading symmetric keys or passwords, while for the latter asymmetric 454 key-pair using the public key infrastructure and certificate are used 455 to exchange/generate the symmetric key (denoted as SMK_{device}). We 456 note that the use of asymmetric keys follows the standard PKI 457 procedures with the the use of either self-certificates, certificates 458 generated by a local (or domain specific) or global authority. The 459 bootstrapping of the constrained devices with symmetric keys can be 460 performed in several ways. As mentioned, pre-loading the device with 461 keys before shipping is one approach, or the symmetric keys can be 462 loaded by the administrator (or home owner or site-manager) at the 463 time of bootstrapping of the device on-site. The approach is based 464 on the level of trust and the threat model in which the system 465 operates. We also note that with ongoing research constrained 466 devices are becoming increasingly powerful and new low-cost and 467 computation based PKI approaches are being proposed. In the future, 468 constrained devices may be able to also use PKI mechanisms for 469 creating symmetric keys. In addition, we assume that there is a 470 local authentication service (AS) that performs authentication, 471 authorization and transient action key distribution. The local 472 authentication service is a logical entity that can be co-hosted at 473 the LSG or IoT server. The location of the AS may be informed by 474 efficiency, security, and trust considerations. The design offloads 475 the complexity to the local AS and simplifies the operations at the 476 devices. Mechanisms can be devised for authenticating and onboarding 477 a device onto the IoT network even if the device does not trust its 478 neighbors and the aggregator using the AS. This can be done by 479 having the key SMK_{device} shared with an AS, which can be 480 communicated this information during device bootstrapping. The AS is 481 used to authenticate the device in the network. The mechanism can be 482 extended for the device to authenticate the network it is connecting 483 to as well [10]. 485 The general steps for device discovery assuming pre-shared symmetric 486 keys are as follows : 488 o New device polling: The configuration service periodically sends 489 out messages pulling information from new devices. Then the 490 device can communicate its manufacturer ID to the aggregator who 491 forwards the message to the AS. The AS will send back a discover- 492 reply, with a nonce encrypted with SMK_{device} and another nonce 493 to be used by the device in the reply; this message is forwarded 494 back to the device. The device decrypts the message obtains the 495 nonce, and encrypts a concatenation of the two nonces with 496 SMK_{device}, which it sends back to the AS. The AS decrypts the 497 content again and authenticates the device. Then it creates a 498 symmetric key to be shared between the aggregator and the device 499 and encrypts a copy of the key with a symmetric key shared by the 500 aggregator and the other copy with SMK_{device} shared with the 501 device and replies back to the device. The reply message reaches 502 the device via the aggregator and they both receive the key to 503 perform secure communication. In NDN, this process can be 504 initiated by the configuration service running on the LSG, which 505 periodically broadcasts discovery Interests (using the name 506 /iot/agg1/discover message) or the discovery can be initiated by 507 the new device in the network which can send a discover message 508 using its globally unique ID (e.g., manufacturer ID). If no 509 authentication of the device's identity is required, then the 510 discover message can be forwarded to the aggregator, which can 511 reply with its namespace and a locally unique ID for the device, 512 say dev10, so the namespace for the device is /iot/agg1/dev10). 513 Or the globally unique ID of the device can also be used as the 514 locally unique ID. This mechanism does not preclude the 515 communication between the device and the aggregator going over a 516 multi-hop path consisting of other IoT devices that are already 517 on-boarded. If device authentication is required, In MF, we can 518 set a group-GUID as the destination address, and the configuration 519 service issues a polling via multicasting. Once the new device 520 enters the IoT domain and receives the polling message, it sends a 521 association request (AssoReq) message, including its manufacture 522 ID, or ICN ID (if it has been assigned one before), its network 523 and security capabilities, and a message ID which is used for the 524 further message exchange between the new device and aggregator. 525 If the device is already assigned a symmetric key, it can use the 526 symmetric key to communicate with the LSG (the ID can be 527 transmitted in clear or by using a pseudonym [17]) to facilitate 528 quick identification by the LSG. If the device can use the PKI, a 529 symmetric key can also be generated. After the aggregator 530 receives the AssoReq from the new device, it will request the LSG 531 naming service to issue a local LID for this new device. The 532 aggregator shall send an Association Reply (AssoRep) message to 533 the new device, which includes the message ID copied from the 534 previous AssoReq message from the new device to indicate this 535 association reply is for this new device, the selected 536 authentication method according to the new device security 537 capabilities, the assigned LID. The AssoRep is sent to the new 538 device via a specific multicast group (as the new device does not 539 have a routable ID yet at this moment). The LID is a short ID 540 unique in the local IoT domain, and is used for the routing 541 purpose in the local domain. This specification will not limit 542 the format of the LID and the method to generate a LID. If 543 authentication is not required, the device discovery is completed 544 and the device can communicate with the aggregator using the LID. 545 If the Authentication is required, this LID is blocked by the 546 aggregator from passing general data traffic between two devices 547 until the authentication transaction completes successfully with 548 the local authentication service. The unauthenticated LID can 549 only send traffic to the authentication service. The aggregator 550 forwards the traffic between the device and the local AS. The 551 aggregator may also implement the policy to regulate the amount of 552 traffic to be sent by an unauthenticated LID to mitigate the DoS 553 attack. If the authentication is required, the following steps 554 shall be performed. 556 o Mutual Authentication: The mutual authentication allows only 557 authorized device to register and use the network, and to provide 558 the device with assurance that it is communicating with a 559 legitimate network. If the authentication is required in the 560 AssoRep, the device shall send a Authentication Request (AuReq) 561 message to the aggregator using the selected authentication 562 method. The AuReq is signed with the pre-loaded SMK{device} for 563 authentication. The aggregator forwards the AuReq to the local 564 AS. The local AS performs authentication locally or contacts a 565 third-party AS according to the authentication method. If the 566 authentication is successful, the local AS generates a master 567 symmetric key SMK{device, aggregator} for the communications 568 between the device and the aggregator. It sends Authentication 569 Reply (AuRep) with master SMK{device, aggregator} to the device 570 via the aggregator. The master SMK{device, aggregator} is 571 protected with the pre-loaded SMK{device}. The local AS also sends 572 a copy of master SMK{device, aggregator} to the aggregator through 573 the secure connection between the local AS and the aggregator. 574 This same approach will work equally well in the NDN architecture 575 as well. 577 o Key generation and distribution: Once the master SMK{device, 578 aggregator} is placed on the device and aggregator, the session 579 keys (AKs) and group keys (GTKs) are generated and placed on the 580 device and the aggregator for unicast and multicast 581 communications, respectively, using the master SMK{device, 582 aggregator}. 584 o Protected Data Transfer: The session keys (AKa and AKe) are used 585 for message integrity and data confidentiality, respectively, 586 which can be renewed periodically. The renewal can happen using 587 key generation functions with the shared secrets and some nonces 588 used for generating the new session keys [10]. 590 The other case is when devices have sufficient resources to run 591 asymmetric keys. That is, the device is pre-loaded with a 592 manufacture ID, a pair of public/private keys (PK_{device}, 593 SK_{device}) and a certificate which binds the device identity and 594 public key. In this case, we also go through the above three steps, 595 with the only difference being in the second step which is Mutual 596 Authentication. To illustrate it using MF as the architecture, in 597 this case, the AuReq message shall include the device certificate and 598 a message authentication code signed by the device private key 599 SK_{device}. The local AS will authenticate the device once receiving 600 the AuReq. If the authentication succeeds, then the local AS will 601 send the master SMK{device, aggregator} along with its certificate in 602 AuRep. AuRep contains a MAC signed by the local AS private key. The 603 mater SMK{device, aggregator} is encrypted using the device public 604 key PK_{device}. SMK{device, aggregator} will be used for generation 605 of AKs to ensure the integrity and confidentiality of future data 606 exchange between the device and the aggregator. 608 4.3. Naming Service 610 The objective of the naming service is to assure that either the 611 device or the service itself is authenticated, attempting to prevent 612 sybil (or spoofing) attack [18] and that the assigned name closely 613 binds to the device (or service). Naming service assigns and 614 authenticates ES and device names. An effective naming service 615 should be secure, persistent, and able to support a large number of 616 application agnostic names. 618 Traditional IoT systems use IP addresses as names, which are insecure 619 and non-persistent. IP addresses also have relatively poor 620 scalability, due to their fixed structure. Instead, ICN separates 621 names from locators, and assigns unique and persistent names to each 622 ES, which satisfies the above requirements. 624 If a device needs a global unique name/ID, but does not have one, it 625 may request the naming service to obtain one after it is 626 authenticated. Alternatively, the IoT domain (LSG or aggregator) may 627 determine ID (name) for an authenticated device is required based on 628 the policy. The proposed naming process works as follows. After a 629 device has been authenticated, it may request an ID from the naming 630 service (or the aggregator, if it can give the device a locally 631 unique name). It sends a ID request (IDReq) to the naming service or 632 aggregator. If the aggregator can accept request to give a unique 633 name to the device, it will do that. For instance, in NDN the device 634 can create content within the aggregator's namespace. If the 635 aggregator cannot then it can serve as the devices' proxy and sends 636 the IDReq to the naming service at the LSG. The naming service 637 assigns a ID to the device, which can be self-certified or a URI. . 638 The naming service also generates a certificate, binding the ID/ 639 public key with the devices' manufacture ID or human-readable name. 640 The LSG sends the ID reply (IDRep) message to the aggregator that 641 sends the IDRep to the device. The IDRep includes the ID certificate 642 and the corresponding private key. The private key is encrypted and 643 the entire message is integrity-protected with AK_{device} when the 644 message is delivered to the device. Alternatively, if the LSG 645 determines that an authenticated device requires an ID when the 646 aggregator registers this device, it will contact the naming service 647 to generate the ID, certificate, and corresponding private key for 648 the device. It sends the ID information to the device. If the 649 device already has a pre-loaded public key, the naming service may 650 use this pre-loaded public key as the device's ID. 652 The LSG maintains the mapping between every devices' LID and the ID. 653 When the LSG receives a message from the external network that is 654 intended for a device within the domain, the LSG will translate the 655 destination devices' ID (which is included in the message) to its LID 656 and then route the message to the device using its LID. Similarly, 657 when the LSG receives a message from within the domain, it will 658 replace the source devices' LID with its ID and then forward the 659 message to the next-hop router. Such a mechanism can ensure global 660 reachability of any IoT device as well as energy efficiency for 661 resource-constrained devices. 663 Finally, we note that the same naming mechanism can be used to name 664 higher-level IoT devices such as aggregators and LSGs. 666 4.4. Service Discovery 668 Service discovery intends to learn IoT services that are hosted by 669 one aggregator by its neighbor aggregators. The aggregators 670 themselves learn service capability of the devices during the device 671 discovery process or separately after authenticating (or during or 672 after naming) them. The requirements for any discovery mechanism 673 includes low protocol overhead (including low latency and low control 674 message count), and discovery accuracy. 676 In today's IoT platforms, ESs, aggregators and LSGs are connected via 677 IP multicast, which involves complicated group management and 678 multicast name to IP translation service. Multicast, however, is 679 greatly simplified in ICN as most ICN architectures have natural 680 support for multicast. 682 Service discovery is widely accepted as an essential element in 683 pervasive computing environments. Many research activities on 684 service discovery has been conducted, but privacy has often been 685 ignored. While it is essential that legitimate users can discover 686 the services for which they have the proper credentials, it is also 687 necessary that services were hidden from illegitimate users. Since 688 service information, service provider's information, service 689 requests, and credentials to access services via service discovery 690 protocols could be sensitive, it is important to keep them private. 691 In [8], the authors present a user-centric model, called Prudent 692 Exposure, as an approach designed for exposing minimal information 693 privately, securely, and automatically for both service providers and 694 users of service discovery protocols. 696 Below, we explain how service discovery is implemented. The key to 697 service discovery is to expose aggregator's services to its neighbor 698 aggregators. How this is implemented differs in NDN and MF. 700 In NDN, the following procedures are performed: 1) The source 701 aggregator broadcasts an interest using the well-known name 702 /area/servicename/certificate, which will eventually reach the 703 destination aggregator. NDN's Interest/Data mechanisms allows only 704 one response for each Interest sent while discovery may require to 705 learn multiple entities. Efficient discovery can be realized using 706 exclusion via Selectors in the protocol or as an overlay protocol 707 [7]; 2) The destination aggregator that hosts the service checks the 708 certificate and registers the source Aggregator if there is a matched 709 service. It replies with an acknowledgment containing certificate to 710 the source aggregator. 712 As an example of an NDN smart home, a thermostat expresses a request 713 to discover a AC service using well-known name /home/ac/certificate 714 via broadcast channel. In MF case, a multicast group GUID 1234 can 715 be assigned to all home appliance IoT service. The thermostat sends 716 the request containing the service name and certificate to 1234. In 717 both cases, the AC hosting this service replies with acknowledgment 718 if all conditions match. 720 As regards to secure multicast service request, it is possible to use 721 the following solution in MF. In fact, especially in MF IoT, secured 722 group GUID can be utilized, which may be owned by multiple hosts, 723 hence conventional public/private key scheme may not be suitable for 724 this case. For secure service discovery, a secured name needs to 725 assigned to the service host. As an alternative, group key 726 management protocol (GKMP) [31] can be adopted to resolve the issue 727 above -- A naming service residing at LSG or IoT server (depending on 728 application scope) generates a group public key that is used as group 729 GUID for a service, then this group public/private keys pair is 730 assigned to each Aggregator that hosts this service. The service 731 hosting Aggregator in the group then listen on this group GUID, and 732 use the group private key to decrypt the incoming discovery message. 733 Finally, we note that this form of secure service discovery is 734 difficult for NDN because of the use of self-certified names by MF. 736 4.5. Context Processing and Storage 738 In order to facilitate context-aware communication and data 739 retrieval, we need to support context processing in the IoT system. 740 The objective of context processing is to expose the ES's low-level 741 context information to upstream aggregators and LSGs, as well as to 742 resolve the application's high-level context requirements using 743 lower-level ES contexts. The context processing service usually runs 744 on both aggregators and LSGs. 746 Context processing requires the underlying network to be able to 747 support in-network computing at both application and network levels. 748 ICN supports in-networking computing (e.g. using named functions [14] 749 and computing layer in MF) and caching, which thus offers unique 750 advantages compared to traditional IP network where the support for 751 in-network computing and caching is poor. 753 Application level contexts differ from application to application, 754 and therefore, we need to provide a set of basic mechanisms to 755 support efficient context processing. Firstly, the network needs to 756 define a basic set of contextual attributes for devices (including 757 ESs, aggregators, and LSGs), including device-level attributes (such 758 as location, data type, battery level, multiple interfaces, available 759 cache size, etc), network-level attributes (such as ICN names , 760 latency per interface, packet loss rates, etc.), and service-level 761 attributes (such as max, min, average, etc.). 763 Secondly, we need to have means to expose ES/aggregator/LSG 764 contextual attributes to the rest of the system, through centralized 765 naming resolution service or distributed routing protocols. 767 Thirdly, the IoT server needs to allow applications (either producers 768 or consumers) to specify their contextual requirements. Fourthly, 769 the unconstrained part of ICN-IoT needs to be able to map the higher- 770 level application-specific contextual requirements to lower-level 771 device-level, network-level , and service-level contextual 772 information. 774 Once the contextual requirements and the corresponding mappings are 775 in place, then in-network caching can be leveraged to optimize 776 overall network performance and system QoS. In an IoT network, 777 cached data can be used to perform data aggregation, in-network 778 processing, and quick turnaround for answering queries. In-network 779 caching can also be used to store data that may be relevant to many 780 nodes and has temporal popularity in a region, and the processed data 781 to serve the users. The contextual requirements can help define in- 782 network processing. This goes beyond the traditional way of 783 aggregators doing the data gathering, processing, and reduction, but 784 also moving computation to the data (also termed network functions). 785 Network functions in essence serves to move the computation into the 786 network for it to happen where the context and the information is 787 available, with the results returned to the requester. In an ICN-IoT 788 these functionalities can be easily incorporated at scale. A good 789 use case for both in-network caching and processing is that of an IoT 790 network of cameras working together to gather a complete field-of- 791 view (FoV) of an area and transmit it for aggregation at the 792 aggregator (may be implemented in the pub/sub model). A user could 793 fire a query that involves processing on the gathered field-of-views 794 at the aggregator (or some other node storing the FOV-data) to answer 795 the query. 797 In-network processing can be implemented at the network level and 798 application level. For example, a user may request the information 799 regarding the maximum car speed in an area. With the network-level 800 implementation, the user issues a request with a function expression 801 /max(/area/carspeed)[14]. The network returns the user the computed 802 results. This result can be obtained in two steps (a)name 803 manipulation and orchestration of computation, an aggregator or LSG 804 will check whether it already has the cached result for /max(/area/ 805 carspeed). If not, it will analyze the function expression, retrieve 806 the function /max and the data /area/carspeed, and compute the 807 result, or forward the request to another node for execution (b) 808 Actual function execution for computation and data processing, that 809 is, calculate /max(/area/carspeed). Alternatively, a user may issue 810 a request /carspeed_service{max_car_speed in the area}[22]. The 811 request is sent to a car_speed service application. The car speed 812 service processes application-level request, i.e. max_car_speed in 813 the area. With the former approach, the data processing and result 814 retrieval may be more efficient. However, the network, that is, the 815 aggregators and LSGs should have a runtime execution environment at 816 the network layer to understand and process the function expression 817 logic. The later approach is simple and robust because the more 818 complex function execution can be performed at the application layer 819 using dedicated virtual machines. 821 4.6. Publish-Subscribe Management 823 Data Publish/Subscribe (Pub/Sub) is an important function for ICN- 824 IoT, and is responsible for IoT information resource sharing and 825 management. The objective of pub/sub system is to provide 826 centralized membership management service. Efficient pub/sub 827 management poses two main requirements to the underlying system: high 828 data availability and low network bandwidth consumption. 830 In conventional IP network, most of the IoT platforms provide a 831 centralized server to aggregate all IoT service and data. While this 832 centralized architecture ensures high availability, it scales poorly 833 and has high bandwidth consumption due to high volume of control/data 834 exchange, and poor support of multicast. 836 Next we consider two decentralized pub/sub models. The first one is 837 the Rendezvous mode that is commonly used for today's pub/sub 838 servers, and the second one involves Data-Control separation that is 839 unique to ICN networks where the control messages are handled by the 840 centralized IoT server and the data messages are handled by the 841 underlying ICN network. Compared to the popular Rendezvous mode 842 where both control and data messages both meet at the centralized 843 server, separating data and control messages can greatly improve the 844 scalability of the entire system, which is enabled by the ICN 845 network. 847 In today's IP network, Rendezvous mode is the classic pub/sub scheme 848 in which data and requests meet at an intermediate node. In this 849 case the role of the IoT server is only required to authenticate the 850 consumers and providing it Rendezvous service ID. 852 While NDN is a Pull-based architecture that inherently does not 853 support the Pub/Sub mode naturally, there are a couple of approaches 854 proposed to create a pub/sub model on top of NDN: namely COPSS [19] 855 and persistent interests. COPSS integrates a push based multicast 856 feature with the pull based NDN architecture at the network layer by 857 introducing Rendezvous Node(RN). RN is a network layer logical 858 entity that resides in a subset of NDN nodes. The publisher first 859 forwards a Content Descriptor (CD) as a snapshot to the RN. RN 860 maintains a subscription table, and receives the subscription message 861 from subscriber. The data publisher just sends the content using 862 Publish packet by looking up FIB instead of PIT. If the same content 863 prefix is requested by multiple subscribers, RN will deliver one copy 864 of content downstream, which reduces the bandwidth consumption 865 substantially. 867 Compared with the Rendezvous mode in which data plane and control 868 plane both reside on the same ICN network layer, we consider an 869 architecture where the control message is handled by the centralized 870 server while data is handled by ICN network layer. Following the 871 naming process mentioned above, the LSG has the ICN name for the 872 local resource which is available for publishing on IoT server. IoT 873 server maintains the subscription membership, and receives 874 subscription requests from subscribers. Since the subscribers has no 875 knowledge about the number of resource providers and their identities 876 in a dynamic scenario, IoT server has to take responsibility of 877 grouping and assigning group name for the resource. 879 MF takes advantage of Group-GUID to identify a service provided by 880 multiple resources. This Group-GUID will be distributed to the 881 subscriber as well as the publisher. In an example of NDN, it uses 882 the common prefix/home/monitoring/ to identify a group of resource 883 that provides multiple monitoring services such as /home/monitoring/ 884 temperature and /home/monitoring/light. The subscriber retrieves the 885 prefix from the IoT server, and sends Interest toward the resource. 886 In a MF example, GUID-x identifies the "home monitoring" service that 887 combines with "light status" and "temperature". The resource 888 producers, i.e. the host of "temperature" and the host of "light 889 status" are notified that their services belong to GUID-x, then 890 listen on GUID-x. The subscriber sends the request containing GUID-x 891 through multicasting which ultimately reach the producers at the last 892 common node. Once receiving the request, the resource producer 893 unicasts the data to the subscriber. In addition, if multiple 894 resource consumers subscribe to the same resource, the idea of Group- 895 GUID can be reused to group the consumers to further save bandwidth 896 using multicast. 898 Another approach to extend the NDN architecture to enable pub/sub is 899 for the subscriber(s) to send Interests that are identified as long- 900 term Interests [11]. The Interests do not expire from the PIT of the 901 intermediate forwarding routers on the path from the publisher to the 902 subscribers. Each time the publisher creates a new content, it 903 publishes it into the network, the content reaches each subscriber 904 along the reverse-path from the producer based on the faces stored in 905 the PIT entry. However, the Interest is not removed from the PIT 906 entry. This allows the creation of a multicast tree rooted at the 907 publisher, reaching every subscriber and enables the pushing of 908 content from the publisher to the subscribers as needed. 910 With a pub/sub framework, important considerations should be given 911 towards user registration and content distribution. 913 User Registration: A user, who wants to access/subscribe to a 914 service, has to perform the registration operation by sending 915 information that depends on the specific application domain to the 916 IoT server. The information can be secured with the help of the PKI 917 infrastructure. Upon successful registration the IoT server securely 918 transmits an identifier, a user signature key SK_{user} (to be used 919 to sign messages), a user encryption key EK_{user} (to communicate 920 data confidentially), and an access password to the user in an 921 encrypted message. Upon reception of the message, the user accesses 922 the system to modify his/her password (function changePassword). 923 With respect to existing secure application-layer solutions, a 924 further benefit of the presented approach is the introduction of a 925 second level of security, represented by the use of a temporary 926 password (immediately replaced) and a couple of keys (signature 927 SK_{user} and encryption EK_{user}), which is well suited for the 928 heterogeneous and distributed IoT environment. 930 Content Distribution: In literature, there are some solutions able to 931 guarantee content security [9] [15][12]. In fact, the work presented 932 in [9] [12] aims to ensure a high availability of the cached data 933 only to legitimate users. The authors design a security framework 934 for ICN able to deliver trusted content securely and efficiently to 935 legitimate users/subscribers. They assume that the content is 936 encrypted by the content provider, either at the servers or in the 937 content distribution network (if it is trusted), by means of a 938 popular symmetric key encryption algorithm. A group of contents may 939 be encrypted using the broadcast encryption key, which only 940 legitimate users can decrypt. The goal is to ensure that the 941 encrypted content cannot be used by an entity that is not a 942 legitimate user/customer. The authors achieve this goal by 943 guaranteeing that only a legitimate user can obtain the symmetric key 944 to decrypt the content, whereas a fake or a revoked user cannot. In 945 this way, the framework does not require any user authentication, for 946 example by an online server, each time a content is requested. 947 Instead, Zhang et al. in [15] consider trust and security as built-in 948 properties for future Internet architecture. Leveraging the concept 949 of named content in recently proposed information centric network, 950 the authors proposed a name-based trust and security protection 951 mechanism. Their scheme is built with identity-based cryptography 952 (IBC), where the identity of a user or device can act as a public key 953 string. Uniquely, in named content network such as content-centric 954 network (CCN), a content name or its prefixes can be used as a public 955 identity, with which content integrity and authenticity can be 956 achieved by means of IBC algorithms. The trust of a content is 957 seamlessly integrated with the verification of the content's 958 integrity and authenticity with its name or prefix, instead of the 959 public key certificate of its publisher. In addition, flexible 960 confidentiality protection is enabled between content publishers and 961 consumers. For scalable deployment purpose, they further propose to 962 use a hybrid scheme combined with traditional public-key 963 infrastructure (PKI) and IBC. Keeping in mind the available 964 solutions, in our proposed method, the device sends to the aggregator 965 its ICN name, its ID encrypted with its signature key SK_{device} and 966 the data encrypted with its own action key AK_{device}, in order to 967 guarantee confidentiality and integrity. The action key AK_{device} 968 has been distributed during the device discovery (see Section Device 969 discovery). The aggregator is able to decrypt the data using the 970 corresponding action key AK_{device}, stored with the device ID, the 971 signature key SK_{device} and the device ICN name obtained during the 972 name service (see Section Name service), in particular the aggregator 973 uses the device name for identifying the related action key 974 AK_{device} (function contentDecryption). Note that the data are 975 encrypted only if it is required by the application domain (i.e., 976 some contexts may not have any security requirements - in this case 977 the function contentDecryption is not applied). As regards the 978 content delivery towards a user who subscribes to a service, the ICN 979 IoT server transmits to the user the data encrypted with the user 980 action key AK_{user} in order to guarantee security and privacy, if 981 it is a requirement of the application domain. The user decrypts the 982 received data using his/her action key AK_{user}(function 983 contentDecryption). In such a situation, the services are treated as 984 multiple-unicast ones, since the aggregator has to use different keys 985 for different devices. In order to address a multicast approach, a 986 group signature key system may be adopted, as in MF approach. 988 4.7. Security 990 This spans across all the middleware functions. Generally speaking, 991 the security objective is to assure that the device that connects to 992 the network should be authenticated, the provided services are 993 authenticated and the data generated (through sensing or actuating) 994 by both devices and services can be authenticated and kept privacy 995 (if needed). To be specific, we consider the approach to secure 996 device discovery, naming service and service discovery, because other 997 services, such as pub/sub management and context processing and 998 storage, can be properly secured according to application-specific 999 demands. 1001 5. Support to heterogeneous core networks 1003 5.1. Interoperability with IP legacy network 1005 Interoperability between the IP legacy network and ICN networks is an 1006 important property that the middleware must meet in order to ensure 1007 the co-existence and gradual migration from the today IP-based 1008 technologies and protocols. This could provide a market strength to 1009 the deployment of the ICN technologies. To this end, the Internames 1010 architecture [21][22] provides an embedded capability to manage 1011 different network domains (or realms), and to support legacy web 1012 applications and services. In this sense, a crucial role is played 1013 by the Name Resolution Service (NRS), whose functionalities can 1014 decouple names from network locators as function of 1015 time/location/context/service, and provide ICN functionalities in IP 1016 networks. By integrating these functionalities on appropriated nodes 1017 a distributed database is created to ease internet-working among 1018 heterogeneous protocol stacks in the core network. 1020 5.2. Named protocol bridge 1022 In an heterogeneous network, composed of different ICN networks and 1023 legacy IP-based networks, interoperability can be pursued, thanks to 1024 the name-to-name primitives. To this end, a name-based protocol 1025 bridge could be deployed at different points of the heterogeneous 1026 core network so as to provide bridging functionalities at the border 1027 of different administered network domains. In order to correctly 1028 forward the message through the network, the NRS node could aid the 1029 name-based protocol bridge providing inter-domain routing 1030 functionalities. 1032 5.3. Inter-domain Management 1034 In heterogeneous networks the IoT server has to strictly cooperate 1035 with the NRS nodes in the core network in order to build a virtual 1036 network topology to efficiently support Req/Res and Pub/Sub 1037 functionalities. The IoT Server could provide the names of the 1038 internal resources to the NRS, so that when the internal network 1039 changes, hence the connectivity to the resources. This ensures that 1040 the NRS database is always synchronized and updated with every IoT 1041 subsystems. In order to support Req/Res and Pub/Sub services 1042 management efficiently in an heterogeneous core network, the IoT 1043 Servers of the different administered domains have to strictly 1044 cooperate with the NRS nodes in the core network. This is to provide 1045 internal information of their own administered domain, such as the 1046 names and or the locators of the internal resources. When the 1047 internal network changes, the status of the resources are synced in 1048 order to maintain an accurate database of the virtual network 1049 topology view comprising of various IoT subsystems. 1051 6. Informative References 1053 [1] Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E., 1054 Burke, J., Ravindran, R., Wang, G., Lindgren, A., Ahlgren, 1055 B., and O. Schelen, "Design Considerations for Applying 1056 ICN to IoT", draft-zhang-icnrg-icniot-01 (work in 1057 progress), June 2017. 1059 [2] Grassi, G., Pesavento, D., and Giovanni. Pau, "VANET via 1060 Named Data Networking.", IEEE Conference on Computer 1061 Communications Workshops (INFOCOM WKSHPS) , 2014. 1063 [3] ICN based Architecture for IoT - Requirements and 1064 Challenges, ICN-IoT., "https://tools.ietf.org/html/draft- 1065 zhang-icnrg-icniot-requirements-01", IETF/ICNRG 2015. 1067 [4] Dong, L., Zhang, Y., and D. Raychaudhuri, "Enhance Content 1068 Broadcast Efficiency in Routers with Integrated Caching.", 1069 Proceedings of the IEEE Symposium on Computers and 1070 Communications (ISCC) , 2011. 1072 [5] NSF FIA project, MobilityFirst., 1073 "http://www.nets-fia.net/", 2010. 1075 [6] NSF FIA project, NDN., "http://named-data.net/", 2010. 1077 [7] Ravindran, R., Biswas, T., Zhang, X., Chakrabort, A., and 1078 G. Wang, "Information-centric Networking based Homenet", 1079 ACM, Sigcomm, 2013. 1081 [8] Feng, Z., Mutka, M., and L. Ni, "Prudent Exposure: A 1082 private and user-centric service discovery protocol", 1083 Pervasive Computing and Communications, 2004, Proceedings 1084 of the Second IEEE Annual Conference on. IEEE, 2004. 1086 [9] Misra, S., Tourani, R., and N. Majd, "Secure content 1087 delivery in information-centric networks: design, 1088 implementation, and analyses", Proceedings of the 3rd ACM 1089 SIGCOMM workshop on Information-centric networking. ACM, 1090 2013. 1092 [10] Mick, T., Misra, S., and R. Tourani, "LASeR: Lightweight 1093 authentication and secured routing for NDN IoT in smart 1094 cities", arXiv:1703.08453v1 (in submission in IEEE IoT 1095 Journal). 1097 [11] Tourani, R., Misra, S., Mick, T., and S. Biswal, "iCenS: 1098 An information-centric smart grid network architecture", 1099 In IEEE International Conference on Smart Grid 1100 Communications (SmartGridComm), pp. 417-422, 2016. 1102 [12] Misra, S., Tourani, R., Mick, T., Brahma, T., Biswal, S., 1103 and D. Ameme, "iCenS: An information-centric smart grid 1104 network architecture", In IEEE International Conference on 1105 Smart Grid Communications (SmartGridComm), pp. 417-422, 1106 2016.. 1108 [13] Liu, H., Eldaratt, F., Alqahtani, H., Reznik, A., De Foy, 1109 X., and Y. Zhang, "Mobile Edge Cloud System: 1110 Architectures, Challenges, and Approaches", IEEE Systems 1111 Journal, pp. 1-14, DOI: 10.1109/JSYST.2017.2654119, Dec. 1112 2016.. 1114 [14] Sifalakis, M., Kohler, B., Scherb, C., and C. Tschudin, 1115 "An information centric network for computing the 1116 distribution of computations", In Proceedings of the 1st 1117 ACM International conference on Information-Centric 1118 Networking, pp. 137-146, 2014.. 1120 [15] Zhang, X., "Towards name-based trust and security for 1121 content-centric network", Network Protocols (ICNP), 2011 1122 19th IEEE International Conference on. IEEE, 2011. 1124 [16] Nikander, P., Gurtov, A., and T. Henderson, "Host identity 1125 protocol (HIP): Connectivity, mobility, multi-homing, 1126 security, and privacy over IPv4 and IPv6 networks", IEEE 1127 Communications Surveys and Tutorials, pp: 186-204, 2010. 1129 [17] Misra, S. and G. Xue, "Efficient anonymity schemes for 1130 clustered wireless sensor networks", International Journal 1131 of Sensor Networks, volume 1, number 1/2, pp: 50-63, 2006. 1133 [18] Newsome, J., Shi, E., Song, DX., and A. Perrig, "The sybil 1134 attack in sensor networks: analysis and defenses", IEEE, 1135 IPSN, 2004. 1137 [19] Jiachen, C., Mayutan, A., Lei, J., Xiaoming, Fu., and KK. 1138 Ramakrishnan, "COPSS: An efficient content oriented 1139 publish/subscribe system", ACM/IEEE ANCS, 2011. 1141 [20] Marica, A., Campolo, C., and A. Molinaro, "Multi-source 1142 data retrieval in IoT via named data networking", ACM ICN 1143 Siggcomm, 2014. 1145 [21] Blefari-Melazzi, A., Mayutan, A., Detti, A., and KK. 1146 Ramakrishnan, "Internames: a name-toname principle for the 1147 future Internet", Proc. of International Workshop on 1148 Quality, Reliability, and Security in Information-Centric 1149 Networking (Q-ICN), 2014. 1151 [22] Piro, G., Signorello, S., Palatella, M., Grieco, L., 1152 Boggia, G., and T. Engel, "Understanding the Social impact 1153 of ICN: between myth and reality", AI Society: Journal of 1154 Knowledge, Culture and Communication, Springer, pp. 1-9, 1155 2016. 1157 [23] Nelson, S., Bhanage, G., and D. Raychaudhuri, ""GSTAR: 1158 generalized storage-aware routing for mobilityfirst in the 1159 future mobile internet", Proceedings of the sixth 1160 international workshop on MobiArch, pp. 19--24, 2011. 1162 Authors' Addresses 1164 Prof.Yanyong Zhang 1165 WINLAB, Rutgers University 1166 671, U.S 1 1167 North Brunswick, NJ 08902 1168 USA 1170 Email: yyzhang@winlab.rutgers.edu 1172 Prof. Dipankar Raychadhuri 1173 WINLAB, Rutgers University 1174 671, U.S 1 1175 North Brunswick, NJ 08902 1176 USA 1178 Email: ray@winlab.rutgers.edu 1180 Prof. Luigi Alfredo Grieco 1181 Politecnico di Bari (DEI) 1182 671, U.S 1 1183 Via Orabona 4, Bari 70125 1184 Italy 1186 Email: alfredo.grieco@poliba.it 1187 Sicari Sabrina 1188 Universita degli studi dell Insubria 1189 Via Mazzini 5 1190 Varese, VA 21100 1191 Italy 1193 Email: sabrina.sicari@uninsubria.it 1195 Hang Liu 1196 The Catholic University of America 1197 620 Michigan Ave., N.E. 1198 Washington, DC 20064 1199 USA 1201 Email: liuh@cua.edu 1203 Satyajayant Misra 1204 New Mexico State University 1205 1780 E University Ave 1206 Las Cruces, NM 88003 1207 USA 1209 Email: misra@cs.nmsu.edu 1211 Ravi Ravindran 1212 Huawei Technologies 1213 2330 Central Expressway 1214 Santa Clara, CA 95050 1215 USA 1217 Email: ravi.ravindran@huawei.com 1219 G.Q.Wang 1220 Huawei Technologies 1221 2330 Central Expressway 1222 Santa Clara, CA 95050 1223 USA 1225 Email: gq.wang@huawei.com