IoT Protocol Standards Landscape and Trends

Transcription

1 IoT Protocol Standards Landscape and Trends INRIA Paris, hbp:// 1 Prof. Carsten Bormann, cabo@tzi.org

2 Carsten Bormann Universität Bremen TZI IETF CoRE WG IRTF T2T RG hbp:// 2 Prof. Dr.-Ing. Carsten Bormann, cabo@tzi.org

3 3 RFC 2429 RFC 2509 RFC 2686 RFC 2687 RFC 2689 RFC 3095 RFC 3189 RFC 3190 RFC 3241 RFC 3320 RFC 3485 RFC 3544 RFC 3819 RFC 3940 RFC 3941 RFC 4629 RFC 5049 RFC 5401 RFC 5740 RFC 5856 RFC 5857 RFC 5858 RFC 6469 RFC 6606 RFC 6775 RFC 7049 RFC 7228 RFC 7252 RFC 7400 RFC 7959 RFC 8132 RFC 8138

4 Bringing the Internet to new applications Application X will never run on the Internet How to we turn off the remaining parts of X that still aren t on the Internet? 4

5 Scale up: Number of nodes (50 billion by 2020) 5

6 Scale down: node 6

7 Scale down: cost complexity 7

8 cent kilobyte megahertz 8

9 Constrained nodes: orders of magnitude 10/100 vs. 50/250! There is not just a single class of constrained node! Class 0: too small to securely run on the Internet " too constrained! Class 1: ~10 KiB data, ~100 KiB code " quite constrained, 10/100! Class 2: ~50 KiB data, ~250 KiB code " not so constrained, 50/250! These classes are not clear-cut, but may structure the discussion and help avoid talking at cross-purposes RFC core@ietf80,

10 IP is important IP = Integration Protocol 10

11 But do we need all of the baggage? Or, just because we can move it, do we still want it? 11

12 Can you put a sofa on a motorcycle? Yes, you can. But do you want to? Is sofa transport even a good criteria for vehicle selection? 12

13 Two camps IP is too expensive for my microcontroller applicapon (my hand-knibed protocol is beber) vs. IP already works well as it is, just go ahead and use it Both can be true! 13

14 Moving the boundaries Enable Internet Technologies for mass-market applicapons Can use Internet Technologies unchanged Cannot use Internet Technologies Can use Internet Technologies Can use Linux Acceptable complexity, Energy/Power needs, Cost 14

15 Moving the boundaries Enable Internet Technologies for mass-market applicapons Can use Internet Technologies unchanged Cannot use Internet Technologies Can use Internet Technologies Can use Linux Acceptable complexity, Energy/Power needs, Cost 15

16 Hype-IoT Real IoT IPv4, NATs Device-to-Cloud Gateways, Silos Questionable Security IPv6 Internet Small Things Loosely Joined Real Security $40+ < $5 W mw, µw 16

17 a properly networked world could be safer, greener, more efficient and more productive But in order for that to emerge, the system has to be designed in the way that the internet was designed in the 1970s by engineers who know what they re doing, setting the protocols and technical standards that will bring some kind of order and security into the chaos of a technological stampede. John Naughton, The internet of things needs better-made things (The Guardian, ) 17

18 We make the net work18

19 IETF: Constrained Node Network WG Cluster INT LWIG Guidance INT 6LoWPAN IP over INT 6Lo IP-over-foo INT 6TiSCH IP over TSCH INT LPWAN Low-Power WAN RTG ROLL Routing Networks (RPL) APP CoRE REST (CoAP) + Ops APP CBOR CBOR & CDDL SEC DICE Improving DTLS SEC ACE Constrained AA 19 SEC COSE Object Security

20 Protocol Stack Application Resource Model Encoding (CBOR) CoAP DTLS UDP TLS TCP IPv6 L2 Connectivity (Wi-Fi) Project B OIC Stack [Source: OCF] 20

21 OMA LWM2M: CoAP + DTLS 21

22 : 6LoWPAN IPv6 over Low-Power WPANs : IP over X for Encapsulation RFC 4944 (2007) Header Compression redone RFC 6282 (2011) Network Architecture and ND RFC 6775 (2012) (Informationals: RFC 4919, RFC 6568, RFC 6606) 22

23 6LoWPAN = RFC4944 HC1/HC2 + RFC6282 (6LoWPAN-HC) + RFC6775 (6LoWPAN-ND) 23

24 6LoWPAN = IPv6 over IEEE Lo = 6LoWPAN Technologies for other radios 24

25 Technology IEEE ( ZigBee ) BlueTooth Smart DECT ULE ITU-T G.9959 ( Z-Wave ) ah ( HaLow ) NFC 6lobac IEEE (LF PLC) Ethernet + PoE WiFi, LTE, Traits Many SoCs, 0.9 or 2.4 GHz, 6TiSCH upcoming On every Phone Dedicated Spectrum, In every home gateway Low power WiFi Proximity Wired (RS485) Reuses mains power lines Wired, supplies W Power? 2.4 GHz 0.9 GHz 1.8 GHz 6Lo13.56 MHz 25

26 : ROLL Routing Over Low power and Lossy networks Tree-based routing RPL RFC (2012) with Trickle RFC 6206 (2011) with MRHOF RFC 6719 Experimentals: P2P-RPL (RFC 6997), Measuring (RFC 6998) MPL (Semi-Reliable Multicast Flooding) RFC (Lots of Informationals: RFC ) 26

27 RPL: Routing for CN/N! RFC 6550: Specialized routing protocol RPL Rooted DAGs (directed acyclic graphs) redundancies in the tree help cope with churn rank : loop avoidance Storing Mode: Every router has map of subtree Non-Storing Mode: Only root has map of tree 2012 Metrics: e.g., ETX 1 Root 1 Root

28 : CoRE Constrained Restful Environments CoAP RFC 7252 ( ) Observe: RFC 7641, Block: RFC 7959 HTTP mapping: RFC 8075 Experimentals: RFC 7390 group communications Discovery (»Link-Format«) RFC

29 The elements of success of the Web! HTML! uniform representation of documents! (now moving forward to HTML5 with CSS, JavaScript)! URIs! uniform referents to data and services on the Web! HTTP! universal transfer protocol! enables a distribution system of proxies and reverse proxies 29

30 Translating this to M2M! HTML! uniform representation of documents! (now moving forward to HTML5 with CSS, JavaScript)! URIs! uniform referents to data and services on the Web New data formats: M2M semantics instead of presentation semantics! HTTP! universal transfer protocol! enables a distribution system of proxies and reverse proxies 30

31 Make things as simple as possible, but not simpler. Attributed to Albert Einstein 31

32 The Constrained Application Protocol CoAP! implements HTTP s REST model! GET, PUT, DELETE, POST; media type model! while avoiding most of the complexities of HTTP! Simple protocol, datagram only (UDP, DTLS)! 4-byte header, compact yet simple options encoding! adds observe, a lean notification architecture 32

33 Proxying and caching Source: 6lowpan.net 33

34 CoRE breakthroughs RFC 7252: embrace REST but get rid of HTTP baggage and extend REST with Observe RFC 6690: Web Linking for discovery: /.well-known/core building resource-directory on top of that 34

35 Security is not optional!! HTTP can use TLS ( SSL )! CoAP: Use DTLS 1.2! Add 6LoWPAN-GHC for efficiency! Crypto: Move to ECC! P-256 curve! SHA-256! AES-128! To do:! Commissioning models (Mother/Duckling, Mothership, )! Authorization format and workflow! Performance fixes (DICE) 128-bit security (~ RSA 3072-bit) 35

36 IoT Security today Thin perimeter protection WiFi password = keys to the kingdom Once you are in, you can do everything No authorization Doesn t even work for a three-member family 36

37 If it is not usably secure, it s not the Internet of Things 37

38 : ACE Authentication and Authorization for Constrained Environments currently applying OAuth framework to IoT 38

39 39

40 : CBOR Concise Binary Object Representation : JSON equivalent for constrained nodes start from JSON data model (no schema needed) add binary data, extensibility ( tags ) concise binary encoding (byte-oriented, counting objects) add diagnostic notation Started AD-sponsored, turned into a WG on

41 : COSE CBOR Object Signing and Encryption: Object Security for the IoT Based on JOSE: JSON Web Token, JWS, JWE, Data structures for signatures, integrity, encryption Derived from on OAuth JWT Encoded in JSON, can encrypt/sign other data COSE: use CBOR instead of JSON Can directly use binary encoding (no base64) Optimized for constrained devices 41

42 ApplicaPon Layer Technologies! The Web of Things: CoAP and HTTP " Using CoAP for management: OMA LWM2M, COMI " Time Series Data: CoAP-Pubsub (and XMPP, MQTT)! Data Formats: CBOR and JSON " Data objects: OMA LWM2M, IPSO Smart Objects " Sensor data: SenML (in use in OMA LWM2M)! Real Security " CommunicaPons: DTLS and TLS " Object Security: COSE and JOSE " AuthenPcated AuthorizaPon: ACE 42 Prof. Dr.-Ing. Carsten Bormann,

43 IETF: Constrained Node Network WG Cluster INT LWIG Guidance INT 6LoWPAN IP over INT 6Lo IP-over-foo INT 6TiSCH IP over TSCH INT LPWAN Low-Power WAN RTG ROLL Routing Networks (RPL) APP CoRE REST (CoAP) + Ops APP CBOR CBOR & CDDL SEC DICE Improving DTLS SEC ACE Constrained AA 43 SEC COSE Object Security

44 IRTF: Internet Research Task Force (sister of IETF) IRTF complements IETF with longer-term Research Groups New: Thing-to-Thing Research Group (T2TRG) Investigate open research issues in: turning a true Internet of Things into reality, an Internet where low-resource nodes ( Things, Constrained Nodes ) can communicate among themselves and with the wider Internet, in order to partake in permissionless innovation. 44

45 How to use REST in IoT? Ignore it, build a SOAP on top Use it half-heartedly and reap some of the benefits Use it right But what are the best practices that work well in the IoT? RESEARCH 45

46 REST for Thing-to-Thing Communication Cloud-to-Cloud (with Things) Thing-to-Thing (may include cloud services) Matthias Kovatsch 46 From REST-as-we-use-it to Design Patterns 2

47 How? Client Resource Directory Entry URI Follow links Submit forms Thing A Action Result Thing B Thing C Choice & redundancy Dynamically extend process flow Thing C Auth-Server [Source: Kovatsch/Hartke]

48 We make the net work48

49 Constrained cast and network simulation Olaf Bergmann 49

50 50 Send Bloom Filter with packet, match OIF Bloom filter DAG root multicast data DAG parent ulticast istener Multicast Sender

51 IoT Security An overview Stefanie Gerdes 51

52 Four legs I Every endpoint has its own AM I CAM is controlled by COP, SAM is controlled by ROP I CAM helps authenticating S for C and provides authorization information about S to C I SAM helps authenticating C for S and provides authorization information about C to S / 18

53 Evaluation (DCAF-DTLS) Reference implementation of DCAF-DTLS adds I about 440 Bytes Code I 54 Bytes data for ticket face I 722 Bytes parser for CBOR payload to existing CoAP/DTLS server (ARM Cortex M3) representing S / 18

54 IoT Devices as an attack platform 54

55 55

56 56

57 57

58 Manufacturer s Usage DescripPon (MUD)! Protect the network and other unrelated users against an IoT Device that may be insecure! Idea: Document expected behavior in an acponable way! MUD as standardized today: Can be used for firewall configurapon " Poke firewall holes for desirable traffic " Detect when the IoT Device has been compromised! Where can we take this idea? 58 Prof. Carsten Bormann, cabo@tzi.org

59 Software Updates are needed Bugs are being found Environments change Update or discard! Traditional: manual upgrade by connecting a special upgrader device (e.g., PC with upgrader app) Too expensive; device might be hard to reach Needed: Over-the-air Upgrade 59

60 Software Updates change the end system Need to be authorized An authentic upgrade is not enough Applicable to device s configuration, application? Qualified in lab testing? 60

61 Contextual aspects Is this a good time for an upgrade? airplane in the air or in the hangar Holy grail: hitless upgrades but upgrades also can go wrong 61

62 62

63 63

64 IoT Data Formats and data modeling 64

65 n 2 n 65

66 2n 66

67 4 Vocabulary Semantic Level Taxonomy Meaning Information Model Ontology Data Model Abstract Syntax Concrete Syntax Marshaling Scheme Message Transport Serialization Encoding Format 67

68 COSE: CBOR Object Signing and Encryption Do for CBOR what has been done for JSON Much easier: no base64 Now draft-ietf-cose-msg, in RFC editor queue Main Customer: Internet of Things/Web of Things but used in many other environments 68

69 CWT: CBOR Web Token JWT: JSON Web Token (RFC 7519) Package Claim Set into JSON Apply JOSE for Signing and Encryption CWT: Use CBOR and COSE instead of JSON and JOSE CWT can replace unstructured misuse of certificates for Claim Sets Being completed in IETF ACE WG 69

70 COSWID: Software-ID tags for constrained devices IM, DM, and Serialization SWID IM Software Instance SWID XML DM Schema 1 DM Data Definition 2 SWID CBOR DM 3 DM n SWID XML Serialization Serialization SWID CBOR 1.1 Serialization Instance Instance Serialization n.1 70 IETF 95 - April

71 TUDA: Time-based unidirectional attestation Remote Attestation: attempt to describe the integrity and trustworthiness of a host or device Measurements of components (e.g., hash values) Protocols for RA typically bidirectional Challenge for freshness TUDA: Time-based unidirectional attestation 71

72 Evolving REST for a Web of Things Klaus Hartke 72

73 CoRAL Forms flags form relation type Method Accept Href.Path [68, 1 (create-item), [ 1, 2 (POST), 2, 60 (application/cbor), 12, "items"]] option number option value 73 22

74 Open source projects for IoT Olaf Bergmann 74

75 libcoap is One of The Major CoAP-Implementations 75 Bergmann: Technology Transfer Projects 5 / 7

76 tinydtls I Eclipse IoT project I implements RFC 6347 (DTLS) using cipher suites recommended by RFC 7252 I POSIX and Contiki, RIOT I used as blueprint and interop testing tool for many other DTLS implementations (e. g. ContikiDTLS, Scandium) I Ported for Eclipse Wakaama LWM2M library 76 Bergmann: Technology Transfer Projects 6 / 7

77 Interoperability and playgrounds 77

78 IoT CoAP Plugtests March 2012, Paris Registra on Deadline: 9 March 2012 Website: h p:// C GET/temperature /temperature SERVER CLIENT 200 OK applica on/text 22.5 C ETSI Plugtests, the IPSO Alliance and the FP7 Probe IT project are pleased to invite you to par cipate in the first Internet of Things CoAP Plugtest, taking place from 24 25th March 2011 in Paris, France. The event is co located with the 83 rd IETF held March 26 30th. core@ietf83,

79 ETSI Plugtests! COAP 1: , Paris! COAP 2: , Sophia-AnPpolis! COAP 3: , Las Vegas (colocated with OMA LWM2M)! COAP 4: , London! 6LoWPAN 1: , Berlin! 6Lo 1: , Yokohama! Test descrippons provided by TZI Open-source development on github.com 79 Prof. Carsten Bormann,

80 80

81 81

82 Implementations Parsing/generating CBOR easier than interfacing with application Minimal implementation: 822 bytes of ARM code Different integration models, different languages > 25 implementations (after first two years)

83 CBOR playground Convert back and forth between diagnostic notation (~JSON) and binary encoding 83