m2m communications and next generation global ioticc2014.ieee-icc.org/2014/private/tutorial3.pdfm2m...

M2M Communications and Next Generation Global IoT

ICC’14 Tutorial Abd-Elhamid M. Taha – Alfaisal University, KSA

Najah Abu Ali – UAE University, UAE Hossam S. Hassanein – Queen’s University, Canada

ICC’14 Tutorials can be found at http://icc2014.ieee-icc.org/2014/private/programTutorials.html

http://icc2014.ieee-icc.org/2014/private/programTutorials.html



“The Internet

2014/06/10 Taha, Abu Ali and Hassanein -- M2M Comm. in Next Generation IoT 1

… is already made of things. (If that's not the case then we have a serious case of mass hysteria:-) For this reason, we prefer not to refer to a so-called "Internet of Things," nor to use the IoT acronym. Where it is necessary to distinguish our imperfect expectation of the future from the current Internet, we instead speak about the Internet with many more things but otherwise we just talk about the Internet.” Kutscher and Farrel, “Towards an Information-Centric Internet with more Things”, Informational Internet-Draft draft-kutcscher-icn-wmt-00, February 2011.

Introduction

The Thing is …

IoT in a Nutshell

• Ubiquitous computing. • Object-to-object, and object-to-person

communications. • Automated connectivity and data exchange. • Big data. • Diversity of IoT entities/objects.


IoT in a Nutshell

Connected to the Internet sophisticated computerized devices and interfaces

Smart Monitoring Smart Living Smart Industry


The Business Perspective • Cisco: New Internet of Everything index

– The estimated market of 14.4 Trillion up for grabs in the coming decade

• Intel – IoT brought about $2 billion of the company's $12.8

billion in revenue, which equated to 32 percent growth year over year

• IBM – Since 2003 IBM spent over $50 billion on acquisitions

and R&D in preparation for a radical shift in IBM's business.


The Need for the Cloud • Virtualization of physical resources. • Resource pooling. • Broad network access. • Location/device independence. • Highly-available and flexible computing platform. • Accountable service.


Cloud Computing

Virtualization Layer

OS OS OS

APP APP APP APP APP APP

Physical Servers/DBs/Storages


Cloud of Things

• Facilitating a merger of M2M communication with Cloud services

• Leveraging communication overhead to enable light-weight mobile-based M2M operation

• Introducing a hybrid model of Cloud based M2M communication


The Industrial Internet


A Working Definition of IoT

• An Internet evolution, capable of reliably and securely handling massive and heterogeneous connectivity and transmission, and utilizing mixed connectivity modes centered around either host, location or ID.


The Storyline


Massive number of machines, objects or things

Connected through different modes (location, IP address, label)

Transmitting massive amounts of information

Through the active Internet, using new and legacy protocols

With connections and/or contents secured

What this Tutorial is about? • Machines

– The characteristics of their communications • Networks

– The need for new protocols • Information

– How ICNs will help overcome scale • Location

– Why matters, and how it will be managed • Security

– Sustaining the IoT evolution, and beyond


Foundations of IoT

A Networks Perspective

IoT’s Main Drivers

IoT The Machine

The Network

The Location

The Information

The Security


THE MACHINE


Nao, Aldebaran’s TM Humanoid Robot

The Rise of the Massive


Image source: http://www.analysysmason.com/Research/Content/Comments/M2M-MENA-Etisalat-Oct2013-RDRK0/]

M2M device connections, the Middle East and North Africa, 2013–2018

• Due to the wide variety of applications of M2M, the number of devices is increasing rapidly.

• According to Cisco, by 2015 there are going to be 25 billion devices for 7.2 billion people

• According to Ericsson, the number of machines participating in MTC by 2020 will be 50 billion with a projected human population of 8 billion at that time

What is a Machine?

• Any device (or software) that can perform automated tasks, e.g., smartphones, refrigerator, sensors, etc. 2014/06/10 Taha, Abu Ali and Hassanein -- M2M

Comm. in Next Generation IoT 17

M2M Communications

• Devices that can take autonomous decisions based on information received from other devices

• Devices are mostly unsupervised Hence • Devices are smarter than traditional devices


M2M Architecture


Image source: http://blog.3g4g.co.uk/2010/02/quick-introduction-to-m2m.html

M2M Services • Public applications and non-public applications:

– Public applications include environment protection and monitoring and Intelligent Transportation System (ITS).

– Non-public applications include home network and asset management, bio and medical applications.

• Location-based services such as ITS and asset management services require localization techniques for the devices.


Machine Constraints

• Low-end – Great numbers – high energy efficiency – resources are too constrained to have IP support. – Supports basic functions. – Application example: environment monitoring.


Machine Constraints • Mid-end

– machines are subject to fewer constraints than Low-end

– more complex in functionalities such as, Localization, TCP/IP support, Power/traffic control and QoS support.

– Application: home network, asset management and industrial automation.

• High-end machines are mostly used for military, bio and medical applications.


Machine Network Traffic • M2M devices generate traffics of the following

types – Periodic: smart metering application. – Event-driven: emergency event report. – Continuous: surveillance camera.

• Large volume of different types of traffic at core network – Guarantee of diverse QoS traffic requirements – Reliability of both human-to-human and M2M traffic.


Open Research Issues

• Pricing schemes for M2M access • Traffic QoS • Spectrum issues. • Core network capacity.


THE NETWORK


Recent Protocols for IoT

• Powerline Communications (PLC) • IPv6 over Low Power Wireless Personal Area

Network (6LowPAN) • Routing Protocol for Low Power and Lossy

Networks (RPL) • ZigBee Smart Energy 2.0 • ETSI M2M Architecture • MQ Telemetry Transport (MQTT)


Connecting Things to the Internet


Adaptation layer to enable IP over IEEE 802.15.4 (LoWAPN)

• Internet packet passes through many different interconnected networks on its way from source to destination.

• Considering the link layer technology of each traversed network – Specification is needed to define how to transport IP packets

over specific link layer

– Specification can introduce a (sub)layer of its own, often called adaptation layer

– Connecting IoT to the internet requires defining adaptation layer for IP-over-LoWPAN


Several LoWPAN Link Layer Protocols

• Large number of semi/proprietary protocols – Zigbee, Z-Wave, Xmesh, SmartMesh, etc. – vendor oriented standard.

• Non-interoperable protocols problem oriented – Different Architectures, – Different Protocols


Requirements of IP Protocol for “IP-over-LoWPAN” Adaptation Layer

• Diversity – Different Things have different communication,

networking, data processing, data storage capacities transmission power and QoS requirements,

• Interoperability – Open source, innovation, cost effective

• Plug & Play • Secure • Global

2014/06/10 Taha, Abu Ali and Hassanein -- M2M


IPV6 vs. IPV4

IPV6 – More suitable for higher

density (futuristically 2 orders of magnitude larger than traditional networks)

– Statelessness mandated – No NAT necessary (adds extra

cost to the cost prohibitive WSN)

– Possibility of adding innovative techniques such as location aware addressing

IPV4 • Limited address space • NAT functionality needs

gateways, etc leads to more cost

• Statelessness not mandated • ……


Is IPv6 a Good Fit? • Universal Integration of the Internet of Things through

an IPv6-based Service Oriented Architecture enabling heterogeneous components interoperability

• Global scalability: 2128 Bit (16 Byte) Addressing –> Enough for Internet of Things

• IP-based technologies already exist, are well-known, and proven to be working.

• Open vs. closed proprietary solutions. • Auto-configuration: DHCP6 • Diagnoses and management tools of IP networks

already exist.


“IPV6-over-LoWPAN” ≡ 6LoWPAN (Adaptation Layer)


Internet

Requires full Internet devices

TCP IPv6

Internet of Things

UDP 6LoWPAN

Optimized IP access

Device Layer

Huge overhead, difficult parsing

Inefficient content encoding

100s - 1000s of bytes

XML

HTTP 10s of bytes Efficient Objects Web Objects

CoAP TLS DTLS

Efficient Web

Services Layer

Web of Things

Web

Zach Shelby, “Is the Internet Protocol enough?”

6LowPAN • IPv6 over Low Power Wireless Personal Area Networks

(6LowPAN) • Low-Power Wireless Embedded devices can now be

connected using familiar networking technology, – like Ethernet (but even where wiring is not viable) – and like WiFi (but even where power is not plentiful)

• All of these can interoperate in real applications • Interoperate with traditional computing infrastructure


Challenges 6LoWPAN must Address • Bandwidth and Energy

efficiency – Standard protocol: IEEE

802.15.4 L1/L2 (low bandwidth: 250 kbps, low power: 1mW)

• Header compression: – IPv6 headers (40 bytes) reduce

payload – 53 byte payload in 127 byte

802.15.4 frame • Fragmentation:

– IPv6 minimum frame size (MTU) = 1280 bytes

– IEEE 802.15.4 frame size (MTU) = 127 byte (higher bit error rate, failure proneness)


6LoWPAN Header • NO 6LoWPAN Header is used for

specifying that the received packet is not compliant to 6LoWPAN specifications

• A Dispatch Header is used to compress an IPv6 header or to manage link-layer multicast/broadcast.

• A Mesh Addressing Header allows IEEE 802.15.4 frames to be forwarded at link-layer, turning single-hop WSNs in multi-hop ones.

• A Fragmentation Header is used when a datagram does not fit within a single IEEE 802.15.4 frame


Fragmentation

• only required when the entire IPv6 packet cannot fit in a single IEEE 802.15.4 frame, • breaks a single IPv6 packet into smaller pieces • Standard defines two types of fragmentation • a fragmentation header is included in every fragment

– the first fragment header type contains only the datagram size (11 bits) and datagram-tag (16 bits) fields – subsequent fragments of the same IPv6packet also includes the datagram-offset (8 bits) field.

• Time limit for reassembly is 60 seconds.


6LoWPAN over Non IEEE 802.15.4 Technologies

• The working group is considering link-layer technologies other than 802.15.4 to use with 6LoWPAN – explored how 6LoWPAN can operate over heterogeneous

low-power technologies, in a similar way as how IP can operate over different underlying technologies.

• The working group adopted internet draft-ietf-6lowpan-btle – applies 6LoWPAN technology to Bluetooth Low Energy.

• Draft-mariager-6lowpan-v6over-dect-ule – The draft proposes 6LoWPAN technology for DECT ULE

(Digital Enhanced Cordless Technology Ultra Low Energy).


Routing in 6LoWPAN Networks

• Two types of routing – “Mesh-under”: forwarding at layer 2 is called mesh-under

routing Supported by 6LoWPAN – “Route-over”: IP routing within the PAN

Supported by RPL


Mesh under Routing • Uses link layer addresses to make forwarding decisions. • Every forwarding layer 2 router along the path of a packet is expected to maintain

its own forwarding table • forwarding decisions are based on link layer addresses. • Four addresses are required to forward the packet at an intermediate node

– the originator address, the final destination address, the current forwarding router address and the next hop router address.

• RFC 4944 introduces the Mesh Address Header for this purpose.


Route-over Routing:RPL

• Routing Protocol for Low-Power and Lossy Power and Lossy Networks (RPL)

• Developed by IETF Routing over Low-Power and Lossy Networks (ROLL) working group

• Low-Power and Lossy Networks (LLN) Routers have constraints on processing, memory, and energy. – Can’t use OSPF, OLSR, RIP, AODV, DSR, etc

• LLN links have high loss rate, low data rates, and instability – Costly packets transmission – Dynamically formed topology

• Covers both wireless and wired networks Requires bidirectional links. May be symmetric/asymmetric.

• Ideal for (data sink) communications and point-to-point communication • Multiple LLN instances on the same physical networks


RPL • RPL is a new Distance Vector routing protocol

– Nodes construct a destination-oriented acyclic graph (DODAG) by exchanging distance vectors and root with a controller

• RPL runs over IPv6-only as “Route Over”, guaranteeing the use of a variety of data links and route re-distribution with other IPv6 routing protocols – New routing metrics: Energy, latency, link reliability, node state, link color,…

• Support of various traffic flows – Multi-Point to Point – ie: meters to Head-end servers – upstream route – Point-to-MultiPoint – ie: Head-end servers to meters – downstream route – Point-to-Point – ie: Sensor to Actuator


RPL Point-to-Point Traffic Flow


Summary • 6LowPAN is designed for IPv6 over IEEE 802.15.4

Frame size and address sizes are primary issues Header compression is the key mechanism

• RPL is designed primarily for data collection No assumption about IEEE 802.15.4 or wireless or frame size Routing is the primary issue Forming a spanning tree like DODAG is the solution


THE LOCATION


The Role of Location in IoT

• Elemental functionality – Similar to traffic prioritization, pricing, routing,

mobility management, power control, authentication, etc.

• Almost all wireless access standards make provisions for localization and location management


Global IoT

https://www.sics.se/expertise/internet-of-things-and-sensor-networks


Location Based Services (LBS) • A two way communication and interaction

– User: asks the information he needs, preferences and position

– Provider: deliver information that meets the user needs

• Simply the answer should include: – Where am I? – What is near by? – How Can I go to?


Spatial Data • Essential component of LBS architecture

– Storing and analyzing spatial data • Geographical Information System (GIS)

– Refers to the computer-based capability to manipulate geographic data

• Maps or images can be stored in vector or raster format.

• A spatial object must have: – Location: a known point – Form: a geometric representation – Attribute: the nature of the object – Spatial relationship: the boundary of an area


Location-based services • Finding services based on location

– physical services (stores, restaurants, ATMs, ...) – electronic services (hot spots, printers, ...)

• Using location to improve (network) services – incoming or outgoing communications adapts to location

• Using location to provide information – tourist guides – advertisements

• Making others aware of user location – presence (individual) – popularity, movement (group)

• Security – grant access based on user’s location


Basic Components for LBS


Building Blocks


LBS

Maps & Navigation

Tracking Services

Information Services Application

• Maps • Routing • Assisted Navigation

• Friends Finder • Traffic Avoidance • Tracking

• Yellow pages • Tracking

• Social Networking • Advertising


Spatial Data • Essential component of LBS architecture

– Storing and analyzing spatial data • Geographical Information System (GIS)

– Refers to the computer-based capability to manipulate geographic data

• Maps or images can be stored in vector or raster format.

• A spatial object must have: – Location: a known point – Form: a geometric representation – Attribute: the nature of the object – Spatial relationship: the boundary of an area


Positioning LBS

GIS Spatial Database

Web GIS

Mobile GIS

Internet Mobile Internet

LBS Mobile devices


Localization/Positioning Methods

Method GPS Localization Symbolic Cellular Manual

Accuracy 10m 20m -100m room-level, AP 100m - 2km room or building AP

Pros • privacy • global • accurate

• simple to implement

• reasonably accurate

• room-level accuracy

•no infrastructure cost •client privacy

• no infrastructure • privacy

Cons mostly outdoors

•Requires network connectivity •Infrastructure required

mapping IP address to AP

location

•low accuracy •cell coverage

•stationary only •doesn’t scale


Localization Fusion Engines

U gps

cellular

network motion sensors

visual

2014/06/10 57 Taha, Abu Ali and Hassanein -- M2M Comm. in Next Generation IoT

Attributes of Localizations • Centralized vs. Distributed. • Indoors vs. Outdoors • Physical vs. Position • Passive Object vs. Active Object


Elements of Localizations • Set of deployed node

– Anchor Node: knows its position through • Manual placement. • GPS.

– Unknown Node: needs to be localized. – Settled Node: knows its position using localization techniques.

• Localization Technique – Measuring algorithm:

• Identify the angle or distance between Anchor and Unknown Node. – Location Estimation:

• Use the measured angle or distance between the Unknown Node and 3 Anchor node to estimate the position of the Unknown node.


Localization

Single-hop

Time Based

Angle Based

Received Signal Strength Indicator

Based (RSSI)

Measure the one way propagation time between two synchronized nodes.

Anchor nodes use the direction of the received wave from the unknown node to identify its position.

Uses the information of transmitter power of received signal and path propagation.


Localization

Single-hop

Time Based

Angle Based

Received Signal Strength Indicator

Based (RSSI)

Multi-hop

Range Based

Range Free

x3, y3

x2, y2

x1, y1

Which uses one of single hops ranging techniques

Which uses number of hops to estimate distance.


Issues with scale and mobility

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9

Mea

n er

ror (

m)

Speed (m/s)

Without AggregationWith Aggregation

0

20

40

60

80

1 2 3 4 5 6 7 8 9

Mea

n er

ror (

m)

Speed (m/s)


Localization Accuracy for 25 SNs Localization Accuracy for 200 SNs

0k50k

100k150k200k250k300k

25 50 75 100 125 150 175 200

Tota

l num

. of p

kt se

nt

Number of SNs


0k

4000k

8000k

12000k

16000k

25 50 75 100 125 150 175 200

Tota

l num

. of c

ollis

ions

Number of SNs


Packets Sent Collision at MAC


The Location – Summary • Localization as a “natural” networking

functionality • Essential tradeoffs

– Energy vs. Accuracy vs. Time vs. Security, etc. • In fusion, much of our understanding is empirical • Location management

– Or the “localization of localization information” • The good news? We do not need to localize all

things, all the time 2014/06/10 Taha, Abu Ali and Hassanein -- M2M


THE INFORMATION


Host Centricity • The TCP/IP infrastructure is built on a

philosophy of host-to-host connectivity • A connection is made to an interface that is

bound to a specific entity with a fixed location or locale

• For traditional applications, this host-centricity works well

• Host-centricity, however, is inefficient in communicating content


Host Centricity Inefficiencies

• Multicast/broadcast overhead • Near edge caching • Managing server load balancing • Disruption management


Information Centricity

• The rise of content on the Internet has shifted interest from host/entity communication to information communication – A shift from WHO to WHAT


Information Centric Networks • Content delivery network architecture. • Content naming/addressing:

– Self-certified vs. hierarchical name resolution infrastructure.

• Content routers as a basic network building block: – A future versions of the existing caching servers. – To replace or to work on top of existing IP-based

routers.


ICNs

Content Provider

Requester


http://www.google.ca/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&docid=pxnQaLuVqztm3M&tbnid=fi_L6VVi3SE8hM:&ved=0CAUQjRw&url=http://blogs.technet.com/b/jonjor/?p=3/default.aspx&PostSortBy=MostViewed&pi42154=4&ei=mgteU9jeD6-E2gXzq4HIAg&bvm=bv.65397613,d.b2I&psig=AFQjCNEAvWCYTmSRk09TS0_ajTN8N6gG-w&ust=1398758667615048

ICN in Action


Image source: Ahlgren et al, “A Survey of Information Centric Networking,” COMMAG’12

Projects • Clean-slate

– DONA – PSIRP, PURSUIT

http://www.fp7-pursuit.eu/

– 4WARD, SAIL http://www.sail-project.eu

– CONVERGENCE http://www.ict-convergence.eu

– CCN, NDN http://www.named-data.net/

– MobilityFirst http://mobilityfirst.winlab.rutgers.edu/

• Evolutionary – TRIAD – ICN-enhanced HTTP – COMET

http://www.comet-project.org/


http://www.fp7-pursuit.eu/

http://www.sail-project.eu/

http://www.ict-convergence.eu/

http://www.named-data.net/

http://mobilityfirst.winlab.rutgers.edu/

http://mobilityfirst.winlab.rutgers.edu/

http://www.comet-project.org/

Main Elements • Naming • Caching • Routing/Forwarding • Mobility • Security

• Design choices in one element affects the

performance of others


Naming

• In ICN, naming decouples object/information identity from its location

• This allows robustness by allowing object mobility and duplication

• Named Data Objects (NDOs) thus become the quanta of connectivity in ICNs

• NDO granularity depends on whether naming is done at the scale of object, chunk, or packet


NDO Namespace Characteristics

• Flat vs. Hierarchical • Fixed vs. dynamic length • Whether human readable

– Facilitates easy query generation

• Security – Self-certifying vs. PKI dependent

• Scalability


Namespace Examples

• DONA – P:L, where P is a cryptographic hash of the

owner’s public key, and L is an owner assigned label

• SAIL – Similar to DONA, P:L – For static content, L is the hash of the content – For dynamic content, L is a fixed ID and a digital

signature is stored in the meta-data


Namespace Examples

• NDN – Assigned and generated by users – Hierarchical structure with multiple components,

w/o constraint on component length

• PSIRP/PURSUIT – Similar to DONA; content names called Resource

Identifiers (RIds) – Scopes, with Scope Identifiers (SIds) control access

rights, authorization, replication, etc.


Caching and Replication

• Dependent on NDO granularity • Performed at both network edge and in-

network • Reactive vs. proactive • Requires care in selecting what to cache

• Any caching node can respond to requests for

the object 2014/06/10 Taha, Abu Ali and Hassanein -- M2M


Routing and Forwarding

• Dependent on namespace characteristics • Can be handled either through name

resolution or through direct routing


Using a Name Resolution Service

• Requests are routed to NRS node, object name translated into one or more source addresses

• Requests are routed to sources • Data routed from source to requester


Using Direct Routing

• Requests are routed directly to one or more sources

• Data is routed from source to requester


Mobility

• As ICNs do not rely on an end-to-end approach, “connection management” becomes easier

• The mobile can issue requests for NDOs on new access, which may be handled by different NRS or sources

• If multihoming is enabled, requests can be made on more than one access


Mobility

• Proposals vary in accommodating mobility – Most accommodate consumer mobility, though

some (DONA, SAIL) may requier session re-establishment

– Provider mobility is generally more complicate to realize


Security

• ICN bypasses the need for link and host security, and focus essentially on object security

• Objectives – Name security – Information integrity, authentication and

confidentiality – Authorization and provenance

2014/06/10 Taha, Abu Ali and Hassanein -- M2M


Example Architecture: DONA


Image source: Xylomenos et al, “A Survey of Information Centric Networks,” COMST’12

Example Architecture: PSIRP/PURSUIT



Example Architecture: 4WARD/SAIL



Example Architecture: MobilityFirst


Comparison CCNx/NDN DONA NetInf/4WARD/SAIL PRISP/Pursuit J

publish to centralized indexed catalog Resolution Handler (RH) Name Resolution Service (MDHT) Rendezvous System

best effort? find closest content sourceflat √ √ √hierarchical √

Naming granularity segment content content content name resolution √ √name-based routing √ √reverse path √out-of-band IP-based IP-based bloom filters forwarding mirrored source discoveryopportunistic cache discoveryresolution updatesin-network (on-path) √ √ √proactive (off-path) √ Caching proxyreissue previously sent unsatisfied Internet packets

√Change RH via DHCP -

reissue requests to new RHreissue requests to new

Resolution Servicereissue new forwarding ID and resubscribe to content

Choose alternate supplier from list of providers

√ √

Source mobilityMove domain of content

objects as one

Registers content with new RH - reestablish active transfers or continue as

Mobile IP

Register content with new Resolution Service - reestablish active transfers or continue as

Mobile IP

update Rendevouz System with new location -

compute new routes for subscribers

Real-time handover unresolvedPKI-based (sign content with Provider PK)

√ √ √

Self-certifying (PK is part of content name)

Content security (data-centric)

digital signature √

Content Distribution

Content Access

Content availability

Delivery?

Mobility Management

Naming

Cache management

SecurityVertical Functionality

Consumer mobility

Naming security (provider-centric)

ICN Proposals

Caching

Content discovery

Cache delivery

Content routing

Naming scheme


Pending Issues • Naming

– Copy management – Search management

• Inter-domain routing • Caching – is it worth it? • Mobility – Can it scale? • Global key management, privacy • QoS


THE SECURITY


Why Security in IoT Matters? • IoT inherits security challenges from exiting

Internet and wireless sensor networks. • The concept of internetworking everything

has raised various concerns from users, enterprises, and industries.

• In IoT, security risks will pass beyond computing devices to also target physical machines; imposing serious dangers and safety hazards.


Key Security Challenges

• Security attacks on IoT objects and systems. • Context-awareness manipulation. • Information integrity and authenticity. • Privacy.


Security Attacks • Being connected to the Internet: inheriting

the cyber attacking challenge. • IoT objects have greater security risks as they

are usually operated by embedded controllers. – Lack of security updates. – Unauthorized control and data collection. – Availability and safety Impacts on the

operator/user of the IoT object; especially in healthcare and industries.


Attacker Compromising the Owner’s Phone

Security Attacks

Remotely Start the Car

Remote Car Management in IoT


Context Manipulation • Data collection/processing in IoT objects are

subject to the surrounding context. • Manipulating the context include:

– providing false data to IoT objects. – moving IoT object to an environment not designed for.

• Result: false information; leading to improper decisions and great security risks.


Information Integrity and Authenticity

• Addressing of IoT entities – Spoofing an identity of an IoT object.

• Tampering with information from an IoT entity. • IoT complexity contributes into the addressing

and tampering challenges: – Diverse networking technologies, in which each has its

own security challenges. – The security of interfacing these technologies.


Information Integrity and Authenticity

X @myhome (spoofed)

@myhome (real - disabled)

Reporting “Armed” to @myhome Owner

X @localforst

1 (150 F)

2 (90 F)

3 (800 F)

4 (130 F)

5 (100 F)

6 (85 F)

@localforst:3 = 150F (forged

data)

Address Spoofing Data Tampering


Privacy • Today’s mobile computing devices incorporates

many sensors (such as GPS, proximity, gyroscope …etc).

• Collected data from these devices can be mined and linked to the operator/owner of these devices.

• Several (free?!) third-party software installed today conduct some sort of data collection for indentifying owners or tracking their habits.


Privacy • Sensors can be used to monitor activities on an

IoT entity: – Example: recording keystrokes via monitoring iPhone

accelerometer readings.

• Information from some IoT entities can be obtained without authentication: – Reading contact-less credit cards Identity theft. – Reading MAC addresses Tracking devices/owners.


Security Challenges in the Cloud

CSA identified in 2013 the top 9 threats to cloud computing

Data Breaches Data Losses Traffic

Hijacking

Insecure Interfaces

Denial of Service

Malicious Insiders

Service Abuse Insufficient

Due Diligence Technology

Vulnerabilities


Security Challenges in ICN • Content-to-identity binding. • Content confidentiality. • Resource exhaustion. • Cache poisoning. • Cryptographic robustness. • Routing/Forwarding resilience against attacks.


Content Binding to Identity • Content addressed by names instead of locations. • Challenge: how to trust the binding of the ICN

content to their identifiers. – Malicious content publishers. – Authenticity of a content: self-certified content vs. use

of resolution service. – Binding authority.


Content Confidentiality

• ICN features authenticity and data integrity. • Confidentiality and the nature of content

publishing. • Challenges to incorporate confidentiality:

– access control policies: how to enforce? – burden of cryptographic key management. – Self-confidential content: can this be achieved

securely?


Resource Exhaustion • ICN utilizes cache routers to reduce unnecessary

network utilization of popular content. • Overloading cache routers with flooding

valid/invalid requests (DoS) • Disabling the caching advantage via high-volume

requests of non-cached or non-popular content. – Content router may evict popular content from local

cache Increased network traffic.


Cache Poisoning • Injecting a malicious (fake) content into cache

routers. • The fake content can have:

– invalid or malformed signature corrupted – valid signature signed by a key not from the purported

provider detectable – valid signature signed by the key from the purported

provider undetectable


Cryptographic Robustness • Importance for content naming. • Points of weakness:

– Cryptographic Algorithms Vulnerabilities – Compromising of the Signing Authority

• Breaking into the signing certificates • Breaking into signing keys


Routing/Forwarding Resilience Against Attacks

• Content naming structure: – Overhead – Scalability – availability

• Trustfulness of content routers.


The Security – Summary • Different modern networking and computing

paradigms in the next generation Internet. • Additional security challenges as a result of:

– evolution of diverse technologies (IoT). – virtual entities (Cloud Computing – ICN). – separation of entities’ addresses and physical

locations (Cloud Computing – ICN). – cross-network communication.


Conclusions

The Road Ahead

• Managing massive connectivity at the access level

• Validating the new protocols, their inter-operability, and their backward compatibility

• Modelling in ICN • Facilitating inter-connectivity mode operation • Securing the heterogeneous massive


m2m communications and next generation global ioticc2014.ieee-icc.org/2014/private/tutorial3.pdfm2m...

Documents