IoT Harmonization using XMPP

Post on 21-Apr-2017

766 views 0 download

Transcript of IoT Harmonization using XMPP

IoT HarmonizationUsing XMPP

Peter Waherhttps://linkedin.com/in/peterwaher

ScopeThis standard defines a method for data sharing, interoperability, and security of messages over a network, where sensors, actuators and other devices can interoperate, regardless of underlying communication technology. The backend of such a globally scalable, secure and interoperable network would be based on the eXtensible Messaging and Presence Protocol (XMPP), and rely on infrastructural components, or bridges, with standardized interfaces that provide real-time conversion of other IoT and M2M protocols, such as those based on CoAP, HTTP, MQTT, AMQP, etc., and other interoperability interfaces, such as those provided by the IEEE 1451, oneM2M, OMA LWM2M, OIC, UPnP, IPSO Alliance, etc. The standard will utilize the advanced capabilities of the XMPP protocol such as providing globally authenticated identities, authorization, presence, life cycle management, interoperable communication, IoT discovery and provisioning. Descriptive meta-data about devices and operations will provide sufficient information for infrastructural components, services and end-users to dynamically adapt to a changing environment. Key components and needs of a successful Smart City infrastructure will be identified and addressed.

Goal Federated and freely extensible Globally scalable IoT backbone Based on free and open standards Allow all popular communication patterns Don’t limit users to specific middleware Secure Interoperable Interact with any existing IoT technology Handle legacy technologies (M2M)

Why XMPP? Federated Globally scalable Free, Open, Tested Standardized by the IETF Extensible (XSF) Secure Interoperable (IoT XEPs) Can bridge between protocols and technologies

(Concentrator) Not sensitive to network topology Open and Free to use by anybody

Are there alternatives to XMPP? HTTP CoAP MQTT AMQP DDS

HTTP Federated Well known Standardized by the IETF Limited in communication patterns Topology limitations (firewalls) Problems making it secure Difficult to implement a distributed security

model.Possible through OAUTH 2, JWT and

federated token authorities.

CoAP Federated Standardized by the IETF Binary version of HTTP Limited in communication patterns Has new communication patterns

Observe (Event subscription) Multicast UDP

Difficult to extend Topology limitations (firewalls) Meta-data limitations. Interfaces not loosely coupled. Does not support a distributed security model. Good for radio networks, or small devices behind gateways

(islands).

MQTT Not Federated Standardized by OASIS (not IETF) Limited in communication patterns Its wide adoption is due to its ease of use Intrinsically insecure and vulnerable

Protocol is flawed Many vulnerabilities cannot be amended

Intrinsically un-interoperable Several governments warn against its use on the

Internet Serves a purpose in closed networks (M2M)

MQTT flaws Allows Injection Allows full site sniffing. Clear-text Passwords

Requires implementation of SSL/TLS and other non-light weight technologies

No content type Makes interoperability impossible Makes integration and testing difficult.

No forwarding of identities. Making security decisions difficult Requires non-light weight security

countermeasures to be added on-top.

AMQP Not Federated Standardized by OASIS (not IETF) Limited in communication patterns Only standardizes transport between

endpoints. Management is made out-of-band (i.e. in a

proprietary manner) Relies on specific middleware

DDS Not Federated Limited in communication patterns Not open standard Proprietary Not free Relies on specific middleware

Federation Divide & Conquer Domains interact Can be extended freely Basis for global scalability Provides resilience Examples:

Mail (SMTP)Web (HTTP) Instant messaging (XMPP)

Security in XMPP Global unique identities Authentication Forwarded identities Authorization Pseudonomization instead of

anonymization Encryption End-to-end encryption IoT Discovery (safe discovery) Provisioning

Communication Patterns in XMPP Asynchronous messages Request/Respond Publish Subscribe

Presence Pubsub

Multicast Event subscription (observe) QoS Queues Brokered communication Server-less communication (peer-to-peer) Discovery Delegation of Trust (decision support)

Interoperability in XMPP Sensor Data (XEP-0323) Provisioning (XEP-0324) Control (XEP-0325) Concentrators, Bridging (XEP-0326) Discovery (XEP-0347)

Loosely Coupled Architecture Interfaces do not presuppose knowledge about

contents. Sufficient meta-data exists for services, devices

and users to interact. Sufficient information exists to manage both

machine (M2M) and human (H2M) interfaces. Allows for abstract bulk processing algorithms,

such as data storage, transportation, conversion, presentation, processing, logging, management, administration, etc. regardless of type of device.

Content base can be freely updated or extended, without updating underlying infrastructure or software.

Bridging technologies Concentrators (XEP-0326) allows addressing of

devices behind any XMPP entity. Can be used to

Manage embedded devices (i.e. PLC) Bridge protocols Interface systems and middleware

Integrated into all IoT XEPs Also allows for a standardized way to administer

and manage devices and data sources in the extended network.

Contains sufficient meta-data to create both machine (M2M) and human (H2M) interfaces.

Concentrator example: PLC

PLC

XMPP Broker

IO2IO1 IO3

XMPP Device

Concentrator example: Bridge

BridgeXMPP Broker

CoAP Device

CoAP Device

CoAP DeviceXMPP

Device

Concentrator example: Integration

H IT

GN

XMPPBridge

XMPPbridge

Backend system

XMPPBridge

3rd part API

Global Federated XMPP network

Concentrator example: Backbone

Federated globalXMPP network

MQTT Island

CoAP Island

HTTP Island

ZigBee Island

XMPP Device

XMPP Device

XMPP Device

XMPP Device

Necessity of Global Identity

Server

Client

Client

Client

Client

Centralized architecture Decentralized architecture

Client

Server

Server

Server

Server

Identities can be managed locallyon the server. Integration difficult.

Identities must be handledglobally and federated.

Threat

Director of National Intelligence

James R. Clapper

http://www.popsci.com/clapper-americas-greatest-threat-is-internet-things

”America's greatest threat is the

Internet of Things”Feb 9, 2016

Principal causes of unsecure solutions Only considers transport (M2M) Security is invisible. Lack of knowledge about existing

technologies. Unclear definition of what IoT is (4 areas). It’s a new paradigm. It uses new communication patterns. It’s a new architecture.

Definition: Internet of Things

The Internet of Things is what you get when you connect things, not operated by humans, to the Internet.

Contains 4 areas of study: Connection (protocols) Things (sensors, actuators, controllers, etc.) Not operated by humans (decision support,

provisioning, AI) Internet (security, interoperability).

Vision: Smart City

In a Smart City or a Smart Society, you have:

Ubiquitous access to sensors and things. Ubiquitous access to data and information from

society’s authorities. Access to smart services in all niches of society.

Driving forces for the Smart City Cross-fertilization of different fields of

activities and business areas. Easy and simple integration. Standardized interfaces. Local anchoring Local knowledge Open, but secure access to things and

data.

Requirement of new infrastructures Open data sources. Federated model for identity and social

infrastructure. Decision support (authorization &

provisioning). Economic feedback models for trading of

sensor data.

Division of responsibilitiesToday, IoT suppliers are responsible for:

Manufacture of devices (back-end) Hosting and managing infrastructure Development of services (front-end)

Division of responsibilities is required: Suppliers of equipment, only supplies

equipment. An “IoT operator” hosts infrastructure,

regardless of supplier of equipment. Devices are published by owners, who get

economic feedback. A natural market forms. Developers with local knowledge, develop

services.

Links & Resourceshttp://xmpp.org/http://xmpp.org/about/xmpp-standards-foundation.htmlhttp://xmpp.org/uses/internet-of-things.htmlhttp://www.xmpp-iot.org/https://xmpp.net/http://www.slideshare.net/peterwaher/xsfhttps://prezi.com/esosntqhewhs/iot-xmpp/https://www.iana.org/assignments/uri-schemes/prov/iotdisco.pdfhttp://xmpp.org/extensions/index.htmlhttp://xmpp.org/extensions/xep-0323.htmlhttp://xmpp.org/extensions/xep-0324.htmlhttp://xmpp.org/extensions/xep-0325.htmlhttp://xmpp.org/extensions/xep-0326.htmlhttp://xmpp.org/extensions/xep-0347.htmlhttps://www.amazon.com/Learning-Internet-Things-Peter-Waher/dp/1783553537http://htmlpreview.github.io/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/xep-0000-IoT-Interoperability.html