Page 129 - ITU Kaleidoscope 2016

ICTs for a Sustainable World

Check message security/
Lookup identity privacy Resource
query controller

Security check No Load statistics Resource allocation
passed? Replica creation

Yes
Check record in index, check Reject
record privacy query Replica (A)
Replication
Record cache
Does record exist No Replica (B)
and meet privacy?
Yes Figure 3. Record replication
Response Get record from file or DB, Neglect
packetize with proper security query

4.2. Record Replication
When the volume of records in the authorized directory or a
Figure 2. Flowchart of security and privacy scheme. cache server is large, the frequency of lookup queries
becomes high, and the monitored metrics indicate that the
performance starts degrading and about to miss the target
devices. For instance, some environment sensing IoT levels, the resource controller prepares a replica server and
devices allow everyone to obtain from the IoT directory asks the authorized directory or cache server to move some
their address and types of sensing data they provide, while records to the new replica server. For example, in Figure 3,
they hide the owner’s name. Similarly, some IoT devices two replicas A and B are created where records from the
might only allow the authorized clients (e.g. belonging to cache server are copied.
the same owner or located in the same locality) to know
their address and data types.
4.3. Record Lookup
Figure 2 shows a flowchart of the security and privacy As mentioned earlier, to get a desired record of an IoT
enforcement scheme. The security and privacy checks are device, a client IoT application sends a lookup query to a
carried out in two steps: (1) message security and identity nearby record cache server, as shown in Figure 4. The
privacy check, and (2) record privacy check. In the first cache server verifies if the lookup query message passes
step, it is checked if the lookup query message itself has through the first step of security and privacy check (as
been secured and privacy protected at the level satisfying described in Section 3.3). The cache server then checks its
the basic requirements, e.g. message integrity protected or record index to determine if the record exists and which
name/identity privacy is protected by encryption. In the replica server holds it. It then forwards the query to the
second step, it is checked if the querying client is corresponding replica server, which executes the second
authorized to get the requested record by satisfying the security and privacy check to determine if the client is
privacy policy. Only the lookup queries that pass through authorized to receive the requested record or parts of it. In
both checks are answered with the records. Privacy policies case the query passes through the record privacy check, the
can be applied to full records or part of them. replica server retrieves the record from its database,
configures a response message with the record, and
4. RECORD CACHING, REPLICATION, LOOKUP, transmits it to the client.
UPDATE, AND RESOURCE ADJUSTMENT
Record Replica (A)
In this section, we describe the mechanisms for caching, cache
replication, lookup, and update of the records with the Query
objective to meet the target performance requirements. forwarding
Replica (B)
4.1. Record Caching Locations
The proposed IoT directory service establishes record
caches in locations closer to the potential clients. Such Lookup
locations are determined by using application-dependent query Lookup
heuristic methods. For instance, record caches are response
instantiated in the location where the record owner (e.g. a
car) has currently moved to and where the possibility that Client
an IoT application (e.g. running on the other cars) from the
surrounding making a lookup query for the record is high.
Figure 4. Record lookup

– 111 –