Chairs: Carsten Bormann & Ari Keränen
Note takers: chairs, Christian Groves
Jabber scribe: Johannes Hund
Carsten introduced the T2TRG and introduced the work done thus far from December 2015.
Agenda bash: adjusted agenda; starting with Lobaro CoAP.
Tobias introduced Lobaro. Lobaro is a startup at Hamburg working with low power sensors and backend software. Including a javascript IoT dashboard and the Lobaro CoAP stack. Focusing on Cortex M3 and M0 on devices.
Lobaro's stack has CoAP client & server in single stack. Observe and block support. Know about RiOT-OS but not using it as they feel many scenarios don’t need a full RTOS. Lobaro's stack is transport independent implementation. Focusing on easy use of resources. Published two open source ports for ESP8266 (wifi) and ZWIR4512 (802.15.4 + 6LoWPAN). Now building implementation for LoRa WAN.
Tobias presented implementations for callbacks. Only notify and request handlers needed for simple implementation.
Known issues: new transport binding implementations have been hard. Wrapping in Go language for unit testing surfaced some API issues. Client also too minimalistic.
CoAP over serial port seems very promising and useful. Need to implement a SMS transport for a customer. At the point of deciding which RTOS for production. Planning a form of LoRa MAC for WSN (instead of LPWAN).
Julien Vermillard: using DTLS for security?
Tobias: relying on L2 security and IPsec currently.
Johannes Hund: license of code? Modularity of code?
Tobias: MIT. Only transports are modular. The rest not intended to be used alone at the moment.
Achim Kraus: What is the advantage of using a different handler for notify?
Tobias: this was done for memory issues.
...
Matthias Kovatsch: seems that ends up duplicating code for responding to normal messages and Notify. Better to unify for memory considerations. Use the same response handlers.
Achim: notify should be based on all information; if URIs etc. are stripped, not sure if can build full response.
Matthias: if enough memory, just store
request. With limited memory need knowledge from resource on what
triggered transaction. If request handler does not care of
options, no need to store them. What to store depends on the
request handler and the resource.
Tobias: very limited EEPROM was main driver for design
choices.
Hauke Petersen: can partition memory or all in one pool? Will run out of memory with many observers and run in deadlock?
Tobias: works like malloc. Not under control. Would not send ACK for observe if can't observe that.
Hauke: If you store an observe and it uses up the available memory, then you run into the deadlock of not being able to receive an incoming packet.
Tobias: perfect candidate for unit tests
Oleg Hahm: numbers on memory footprint?
Tobias: would need to look into details. Using devices with 60-100k of Flash. Not worth counting every last bit. Every M0 will have enough to run such code. No justification for using 8-bit processors today.
Oleg: even on M0 want to leave some RAM for application, not just stack
Tobias: Haven't ran out of Flash for quite some time. Easy to switch to different device. RAM bigger issue.
Daniel Lux: can connect ZigBee modules on SPI.
Carsten: anyone using CoAP over SPI?
Achim: if using SPI you get bound to what you get from HW.
Carsten: SPI gives you a tight coupling. The point of REST is to remove this coupling.
Achim: you don't have influence on the SPI interface with manufacturer. If no CoAP provided, can't use it. If you make both endpoints, could use CoAP, but not otherwise.
Oleg: API on the lower end what is expected? Using 3rd party code for IPSEC?
Tobias: not so easy to implement a new network stack. Planning on re-implementing this aspect. Tried to abstract the socket layer into another socket layer.
Daniel: What stack? Not always IP?
Tobias: Between devices using LoWPAN, not
using IP.
Carsten: wanted to do non-IP serial too? What kind
envisioning?
Tobias: simple protocol going on serial stream, forms packets, and gives to stack.
Carsten: 6lobac is IP over RS485; can maybe steal something from there. Assumes MS/TP MAC, but maybe can do simpler for CoAP over Serial. Anyone working on CoAP over SPI bus?
Tobias: SPI mainly targeted for connecting stuff on PCB.
Carsten: interesting to look into local interconnects and which would benefit from CoAP for CPU to CPU communication.
Daniel: These are master-slave busses. Makes pulling the only option. Multimaster I2C?
Matthias: How do you deal with endpoint identifiers?
Tobias: have on socket API comparison of endpoints.
Matthias: Have a struct and copy identifier in and do a union to derive the id.
Ziran presented IoTivity slides. IoTivity is the reference implementation of the OCF standards, sponsored by OCF. OCF certifies implementations.
Dark blue in the scope slides indicates functionality in OCF core specifications. Relying heavily on CoAP / CoRE specifications. Basic RFCs (CoAP, Observe, blockwise), and beyond (e.g., CoAP pub/sub broker).
Iotivity uses Libcoap for packet formation and processing. The rest of functionality they have implemented themselves.
Support block-wise transfer block1 and block2 options.
Iotivity-over Cloud: Native 1: coap/TCP/TLS, message format alternative L3.
Kai Hudalla: what's the difference between alternatives?
Carsten: during spec time there were three alternatives on how to encode framing, chose coin-toss way option one, but OCF needed bigger data which is better in L3. But need also capability exchange that was added to the draft. Core WG now using L3 so in agreement with OCF. The question is does IoTivity implement the capability exchange. Haven't seen code for that yet. May need to revisit this aspects. Compliant implementation will wait for capability message. In simple setting, both send 2-byte message.
Achim: wonder if L3 allows better speed. If connection is unstable, need to retransfer lots of payload. Is statement from real world experience?
Ziran: statement comes from lab experiments. Looking how this works together with Block transfers.
Matthias: L3 option has CoAP-header-encoded 32 bit field.
Carsten: have CoAP over TCP slides coming later
Cloud native 2: Pub-sub framework for CoAP. Based on CoAP pub/sub broker draft. Did implementation on Android. For pub/sub so far looked at CoAP but will also be looking at non-CoAP protocols too.
Cloud native 3: OAuth over CoAP. Multi-user security. OCF own spec; need to check ACE work.
Cloud native 4: CoAP HTTP-Proxy.
Johannes: how handling redirects?
Ziran/Carsten: can be handled locally at proxy. When designed CoAP made sure not needing re-directs.
Christian Groves: now there's a draft on re-directs?
Carsten: number of security implications on re-direct. Mostly seems to work on simplest cases. But security implications when going beyond.
For security, did implementation of DTLS and TLS.
Thoughts on CoAP:
Carsten: CoAP was designed to work well on networks without good multicast. Don't want to make assumption discovery packets would eventually be received. Have RD for advertising. No advertisement in beaconing, but directory.
Matthias: have all patterns in place for realizing this. Multicast GET to .well-known/core. Simple registration on RD with (also) empty multicast post. This pattern could be extended beyond.
Daniel: sounds like multicast listener discovery protocol (MLDP).
Carsten: that works on WiFi but not necessary on 15.4 networks
Matthias: the pattern in RD draft could be harmonized and standardized to accommodate for this.
Reason to not use transport layer in Libcoap was because it was IP specific.
Daniel: timeout of 2 secs too fast for LoRa (can be up to 10 seconds).
Carsten: with IP in general you don't know the sequence of link layers
Daniel: low rate protocols over long range results in issues
Carsten: may want to implement CoCoa in that kind of case. Can do measurements and act accordingly. Relatively simple thing. Learns RTT. New group at IETF: LPWAN. Looking into ways to run IP over LPWANs. Looking into compressing CoAP even beyond current size. Another draft at RG about Bluetooth LE URIs. May want to take that work in this direction.
Future direction: going beyond client to cloud; peer-to-peer, bridging and forwarding, reporting & control. Following OCF specs.
Christian: isn't there group for industrial Internet? MQTT etc.
Ziran: have MQTT implemented already. Can connect to the implementers.
[coffee break]
Carsten presented from chair slides (s. 17 ->). CoAP over TCP draft in WGLC now. Latest draft 2 weeks old. Right time to read the draft and send comments! Want to ship this. People have implemented already.
Covers TCP and Websockets, with TLS too. TCP more efficient for large amount of messages. Also NAT traversal because of longer NAT binding times than for UDP (can be hours instead of tens of seconds).
Websockets because browsers don't support CoAP natively yet.
Hauke: any info from Firefox and other browser guys implementing CoAP on browsers?
Carsten: chicken-egg problems. Haven't seen many users for browser CoAP
Christian: WebRTC data channel draft for CoAP too.
Kaspar: TCP also reduces complexity of CoAP implementation?
Carsten: yes, but introduces complexity of TCP to system.
Kaspar: can share that code with rest of the system if they need TCP too
Framing needed on TCP. Added length field and using "L3 variant" as OCF did. Not needed for Websockets.
Christian: there also for Websockets, but not used
Carsten: yes, with value zero
Message IDs and types left out because reliability comes from TCP instead.
Also, don't need blockwise if large message sizes are agreed. BERT: multiple 1024 byte blocks in one CoAP message. In Wi-Fi with reliable packet delivery could make sense. Also defining signaling messages (about the connection). 7.xx series messages are CoAP specific. Capability and Settings Message (CSM) exchanged in the start (not currently in OCF implementation). Capability support means that receiver indicates capabilities. Settings: sender uses to indicate different behavior from usual. Mostly Capability messages. TLS Server Name Indication (SNI) example of setting. Ping/pong messages. Pong custody option: sender has processed everything up to ping.
Kai: similar to CoAP ACK?
Carsten: ACK never had those semantics. Even if people used it for it. But hard to do for UDP "received everything up to X"
Matthias: good to clarify: ACK only ACKs receipt of message. Not processing. Can't rely that other endpoint has done that.
Kai: plans to add something like that for CoAP UDP?
Carsten: for UDP would be part of response/ACK for notification.
Matthias: problem that there's no response to response.
Johannes: different models for UDP and TCP. Will in future converge? Or two different formats?
Carsten: probably will not. UDP needs the ID etc. But the formats are very similar.
Johannes: if I have GW with UDP on one side and TCP on other. Need to re-pack on the other side. With two message formats, if converge, could just replace UDP specific and replace with TCP things.
Carsten: need to manage message IDs. Bit more work than repacking. Repacking means header becomes 2 bytes longer.
Johannes: but need to parse message to GW. Can't just rewrite.
Carsten: don't have to rewrite everything, just few bytes.
Daniel: made implementation over tun. "UDP over TCP".
Carsten: but not something we'd be standardizing
Kai: what's the meaning of WGLC in practice?
Carsten: point for the draft where everybody should have a look at the draft.
Achim: for hold-off have to send to all endpoints?
Carsten: things needed to figure out for the new draft
Tobias: MQTT used a lot nowadays. Only over TCP and WS.
Julien: MQTT-SN for datagrams
Carsten: For traversal of hostile environments TCP makes sense.
Ari: CoAP pub/sub broker helps in such environments by changing the roles of who connects
Ziran: Are NATs going to exist in the future?
Carsten: Going away in large parts of world. 50% of IPv6 in Germany. Other parts have IPv6 deployed slowly.
Ari: Unfortunately also IPv6 NATs out there. And not only NAT traversal but also other middleboxes, such as firewalls, that behave similarly.
Kai: Opted not for Abort message. If crash, can't do it anyway.
Carsten: In TLS sometimes are interested to know "intended end of datastream".
Kai: could also want to stop because no authorization anymore. But if shutting down server, no point sending millions of abort messages. Shutting down may not be good example.
Carsten: not sure if good answers yet.
Carsten: alternative addresses spec where we need to think about security. "Connect to this address". With TLS will verify the server name, but nefarious ways of using this. Server shutting down could send orderly abort messages to redistribute load.
Due to technical problems, Matthias based his talk on old slides from 2014. Californium started as "the other (cloud) side" for constrained devices. Easier to get started than in the embedded world. Easy for newcomers and takes care of many things automatically (e.g., blockwise transfer).
Skipped to Slide "3-stage architecture". Looked at designs in the HTTP world to address scalability. Network, protocol, and logic stages. For example Californium got better performance on Windows with multiple threads reading the network buffer.
Kaspar: What kind of performance numbers talking about?
Matthias: 400k messages per second on standard I7 processor. Comparing UDP to TCP but still. Also compared Node JS cluster mode, which is very efficient, but still much more efficient.
Carsten: still hold record for most powerful web server?
Matthias: haven't checked recently. Adding monitoring functionality etc slows down though.
Kai: being able to scale horizontally key for performance
Can instantiate thread pools per resource. Client can also use thread pools.
Endpoints slide. Can have different stacks in parallel. Related to discussion how to implement signalling over TCP. Can process 7.xx messages since same format (and ignore if not known). Benefit of using the same format. For different use cases for CoAP framework may want to implement different API on stage 2 and 3, using the same framework.
The implementation has minimal error handling. However easy to add more extensive handling.
Deduplication tricky. Need to keep lots of state. Complicated on backend. Needs to be well designed. Blockwise and Observe interfere with each other. Layered approach didn't work as expected. Need to check blockwise on many layers. Idea is to rip out all Blockwise support and make it naive implementation. Application needs to be aware of Blockwise. Not the same user-friendliness but can get of lots of complexity in the stack. Can provide convenience functions for the application.
Carsten: might be blockwise on any request
Matthias: interpreted on resource/client level. But state not part of overall state.
Would like to discuss what happens if you start treating responses and notification differently. Just check the token?
Kai: idea that in cloud environment want to support cases where one node started to observe, that node fails, but still receive observations. Want to look up token and figure out that "one of us" has initiated this. Very likely that over lifetime of Observe node fails / taken off duty. Started to handle notification differently from responses due to this.
Matthias: responses and notifications (=response+obs option) should go through stack similarly. Token matching then decides if normal resource handler or Observe manger with notification orderer etc.
…
Kai: requires lookups in shared memory / redis. Dramatically slowing down.
Johannes: on different transports than UDP can't rely on getting response on same node to which sent request.
Kai: in NATed environment nearly every time that problem
Achim: Observe pattern makes lot of trouble. Maybe should think right usage. Good progress notification but not good for long term events. For couple of minutes instead of hours. Think we use Observe now too much. Think other definition of how to do eventing.
Kai: problem with LwM2M.
Achim: if lots of notification in short time observe works. Original observe doesn’t work for longer period which might result in an address change.
Matthias: would be nice to specify. In WoT discussion some ideas on creating events and state changes. Event lives on it's own and must not be lost. Even if one thing times out, can keep local state.
Achim: don't want such thing on protocol layer. Should have another way to inform that something has changed over long time. Upper layer to take care of authentication etc.
Carsten: important question who’s responsible for the changes. Original Observe design assumed lightweight server. Just send notifications. What we do on HTTP side is heavyweight notifications; give source of notification a URI and source needs to lookup, build connection, and send notification over that. Maybe something between the two models. Something that keeps light weight of Observe but can handle changes in endpoints.
Kai: we have POST?
Johannes: pub/sub over CoAP can be used to de-couple. Broker can do fan-out.
Kai: for our cases most of the time sensors sleep and send one item. Predominant model. Not well suited with Observe. Node could do one post and go back to sleep. Problem how LwM2M is designed. Only way to give data upstream is Observe.
Matthias: not interested in heavyweight method? Does not work with NATs etc.
Carsten: POST looks like simple exchange, but isn't. POST node needs to find transport address.
Kai: it's the cloud backend so it's constant. LwM2M client is CoAP server and knows the server.
Matthias: but could be also completely different machine since it's full URI of the target
Achim: would recommend not using Observe for long term. Getting just more and more complex.
Kai: For example in environment with NATing
Achim: good to have other solution. People don't know other ways.
Matthias: lots of conservative decision in Observe RFC on how to correlate. Token matching opens security holes and was solved by being restrictive on what to accept.
Carsten: Observe works for hours if you don't have difficult path in between.
Achim: the original idea of request/response being in short time frame doesn't hold for Observe. Hannes wrote long email about this on CoRE mailing list (see https://www.ietf.org/mail-archive/web/core/current/msg07813.html).
Carsten: still need to figure out medium-weight mechanism. Back to the drawing board.
Johannes: usual way with HTTP is webhooks. That's too heavy weight?
Carsten: requires client to define server that can take notifications. Maybe URIs are the right way but useful to be able to correlate with previous exchange that made request. Nothing in POST to say that it's notification for something previously set up.
Kai: could define option for that
Daniel: too closely coupled with UDP. Need to break linkage.
Matthias: starting assumption 6lowpan with IPv6 etc. But doesn't hold today.
Johannes: two ways forward. Can we standardize something on web hooks etc. Or go below resource layer. Use info from lower layers (request from this address, response there).
Carsten: "address" in terminology is difficult one. In the endpoint discussion we should pick this up. And discuss how to do that with Observe.
Carsten showed slide 33 of chair slides.
LwM2M using content formats 1542 and 1543. Reserved space in CoAP. Proposed solution: use 11542 and 11543 for media types. But also mark 1542 and 1543 as "reserved, do not use".
Julien: Is fine. Not sure where the numbers originally came from.
Kai: someone made it up
Julien: Reserving also seems good idea. Not mandatory, but makes sense.
Kai: for Sierra wireless population, can roll out the change?
Julien: yes, can do update
Kai: for Bosch not a problem. Not that many devices in the field.
Achim: always was a known risk that the numbers are not final. Should not be problem.
Julien: status is that OMA wanted reservation. Got back message that not possible. What's the situation now?
Carsten: OMA did answer; "let's get them anyway". IANA came to IESG who came to CoRE chairs.
Julien: likely not technical people who did request.
Christian: why the requested values not assigned?
Carsten: 1000 to 9999 are reserved for future IETF specs (actually 256-9999). Will send message to IANA. Will Cc Julien and Achim.
Carsten initiated discussion starting with slide 35 of chair slides.
End point is "you" or the other. HTTP uses scheme/host/port. Indirection due to host part being looked up using with DNS. Security based on verifying path of the identifier. TCP address identifies endpoint. Sometimes servers look into IP and port for authorization purposes (weak security, but sometimes done). Client certificates rarely used. Usually client ID in cookies. But cookies are not endpoint IDs but part of application state.
In CoAP DNS not always used. Classic PKI certificates are deemphasized. No cookies (no server generated client IDs). Often device as client and server; long term can be problematic to match IDs. In CoAP client uses URI data to find server (lookup details not defined). Server uses client transport address to reply. But IP addresses and port numbers are not stable. Lose endpoint identity. When server address changes, lookup mechanisms using cache likely to contain stale information. Client may not be able to relate long running requests to replies. Observation state gets broken.
With CoAP and DTLS, client states with SNI which identity it expect from server, and verifies identity. Endpoint is the peer in the (D)TLS connection.
Kai: how client verifies SNI identity?
Carsten: with certificates straightforward. With RPK need out of band mechanism. With RPK assumption is bidirectional authentication.
SNI option in TLS handshake. Info on what cert to send in server hello. Allows sharing IP address with multiple identities / server names (load balancers etc.). In HTTP based on server name (can't do on IP address). In CoAP, "commonly" RD endpoint identifier used for SNI.
Identity often misunderstood term in security. Really identity is set of claims. Need new word for "real world identity". Ownership, role change, repairs change identity? Where authorization is entirely based on identity, need "revocation".
Endpoint claims in HTTPS: server matches to DNS name. Other claims that can be in certifications often not visible to applications. Client claims established in-band (via username/password) and reified to cookies.
In CoAPs: PSK needs out of band channel for the claims. Source and scope specified by the out of band mechanism. RPK has implicit server identity claim (same public key matching to the same server over time). RPK identities are cheap; can be used for directed identities: one per purpose. Certificate mode less well defined (could use HTTPS model). CoAP doesn't tell you how to use cert mode.
Implicit claims: PSK: existing security association; RPK: server (or client) possessing private key. PKI Cert: Explicit claim of SNI possession.
COSE Web Tokens have more fine grained control.
Application APIs have very little information about identities. HTTP dodges the issue due to the use of DNS name. How can we present endpoint information in APIs?
DTLS connection dies if transport address changes.
Julien: our implementation keeps epoch over resumptions.
Achim: in DTLS you indicate "something new" with epoch zero. Next epoch is 1, which is same as last time. Not perhaps what security folks would call same epoch (see https://www.ietf.org/mail-archive/web/core/current/msg07816.html).
Carsten: so there are workarounds. Nonce uniqueness might suffer?
Kai: DTLS spec is not clear on what you do with resuming session.
Julien: concept of connection. With TLS if you resume, it's not same connection.
Kai: it's use new connection. Used also for duplicating connection. But in LwM2M we don't want to spawn a new connection but pick up the old one.
Carsten: ways to creatively interpret DTLS. May be fixing the problem. Alternative: resumption.
Could extend matching across resumption. Set of issues: garbage collection (when to discard)
Kai: guidelines at DICE. Recommended max 24 hours.
Julien: same in TLS spec
(issues continue): who is responsible for resumption, client or server?
Achim: Both CoAP client and server on both sides. LwM2M does both. DTLS role and CoAP role needs to be distinguished. Dynamic part should do hello.
Kai: LwM2M server just waits for clients to connect.
Julien: CoAP point of view it's client and server.
Kai: It's always LwM2M client initiation connection
Matthias: can't assume CoAP client is not DTLS client
Carsten: important to separate the terms
What are the security semantics of the resumption?
Kai: spawning new vs. resuming connection?
Carsten: how do you ensure the new has same semantics
Achim: has same credentials as in the previous session. Make handshake and check all is OK. Resume uses the same credentials.
Carsten: looks good on napkin but second look would be useful
How to prepare for session resumption? Old drafts about that. Never got traction. Problem: preparing for resumption creates new identifier. Need to be careful how to use that. In ideal world client and server can do resumption without disclosing it's the same endpoint.
Julien: with TLS PSK identity in plain text. No problem.
Achim: PSK identifier used to map to private key.
Julien: with IP we're already leaking information
Carsten: with out of band protocol could be kept secure. PSK written at time when people thought "PSK is cheap security when can't have real security". PSK identities don't need to be unencrypted.
Achim: with special contract can have identity mixed up. But without contract it's well known token and function that matches this. Needs to be common function.
Carsten: the kind of security we don't want. Mechanisms like OAuth give token like mechanisms that can be used to result in PSK mechanisms that can be used in clear.
Worth reading: draft-hummen-tls-extended-session-resumption and draft-barret-mobile-dtls
Matthias: might be useful to explicitly say where audience should go from here.
Achim: have thought several months the problem. There was discussion for TLS 1.3. Arguments against connection identifier. When initially exchanging IDs, could encrypt them. On resumption client needs to decrypt the ID and then present that in clear. Also to have separate record indicator for this.
Carsten: need to take this off-line
Next Steps:
Achim: often client does not know it has new address. Need to add guidance on when to do resumption.
Carsten: server should be able to send back "who are you message"
Kai: discouraged in TLS (to react on unknown messages).
Carsten: detection of address change difficult in presence of NATs.
Need to work on how to present this on API level. Need to ask from certificate people what they get out of certificates.
Kai: is it out of question that endpoint ID would simply be session ID?
Carsten: that's the way it is. Coincidental that transport address is there (how DTLS works today). CoAP doesn't care about transport addresses.
Kai: not sure if true. Endpoint identified by address and port
Daniel: in our system use UUIDs. IP address not used.
Carsten: alternative way for deriving RD EP IDs
Kai: can use CoAP URI scheme with hostname and port. All subsequent after DTLS connection will be based on session ID.
Carsten: application usually doesn't care about connection establishment. Interested in long term identifiers (host name, etc. claims). Probably always need to do some matching.
Kai: in our use case with NATed devices, don't have long term claims.
Carsten: need to have some identity
Kai: not supported by address scheme of CoAP (Based on address and port). Assumption is these are long term IDs. Fundamentally broken.
Matthias: IDs are part of security model which is orthogonal. One part to make working to get response, but other the security which up to application. In LwM2M have endpoint name that's long lasting. What is missing is tying to security mechanism.
Carsten: what Kai is saying is URI should be stable, but in CoAP world it's not
Kai: don't send to LwM2M client based on IP address but endpoint name. That's the stable part. Whether IP address is changed is up to CoAP implementation to resolve.
Achim: disadvantage that no mechanism to protect from -- using long term endpoint requires client keeps mapping. If client not aware of address changes.
Matthias: need to be tied to security mechanism
Kai: need to map endpoint name to session ID. Not IP address.
Matthias: Endpoint names encrypted with RPK could help
Achim: then need some changes in Californium. Currently chooses session by address. Need to use long term identifier.
Matthias: more Scandium part (DTLS). But DTLS keeps completely open how to manage certs etc. Could use PSK but management of keys becomes complicated. Outside of Californium framework. TLS only gives secure transport, other things outside of scope.
Achim: TLS ensures I reach the same peer. Plain CoAP doesn't ensure this.
Matthias: CoAP doesn't become secure by adding S to end
Kai: what needs to be done? Need to implement right way? Or something else?
Carsten: on CoAP spec need to change relying on address. With DTLS it's really DTLS connection that generates endpoints. Disassociate that from transport.
Kai: need alternative mechanism for identities
Matthias: (needs to leave) maybe need to check LwM2M spec again. Some homework to do. Collecting input, requirements, etc.
Carsten: fun part will be porting the insights here to object security case. Then just UDP below.
Matthias: we could take that. Others need to fix LwM2M. Should make these folks aware that need to link these to security
Achim: in LwM2M registration this is described.
Matthias: might be some disconnects
Achim: in CoAP RFC endpoint defined by IP and DTLS session. Maybe extended with long-term session ID. Could help with RPK case.
Carsten: CoAP RFC section 9.1.2 describes parts. But need to relax to get rid of transport address and possibly epoch when we understand what that means. 9.1.3 has SNI discussion. Drafts out there how to extend this info. In RFC 6066 section 3 hostname. Maybe can use this. Also open enum that can be used with other types of SNIs. "Currently only DNS names are supported; other name types can be added by RFCs".
Kai: is this already useful?
Carsten: for DNS names. Names that are not anchored in DNS need work.
Kai: where to do this? When things talk to each other? In our predominant use cases device talks to cloud. In peer-to-peer, devices look up RD and then use EP name to identify peer. In cloud server may want to talk to virtual host. But in p2p is there such case as virtual host?
Carsten: in IPv6 you can generate any number of address. Maybe virtual hosts are not needed any more.
Kai: would like to finish the part on what we need
Johannes: what's the use case?
Kai: device behind a NAT connecting to cloud. Currently identified by address and port. Need to provide alternative mechanism. Don't want to have the long identifier in each packet. Client ends up getting timeouts because server doesn't recognize packets coming from new address.
Ari: similar issue in ICE and WebRTC. But there we know a set of address where DTLS can come from.
Tobias: how about client certificates?
Kai: only helps with new handshakes. Need way for client to identify session explicitly.
Carsten: session hint would be enough. "Select out of three sessions instead of thousand".
Kai: draft-fossati-tls-iot-optimizations suggest session ID
Achim: could use this only when client thinks it's useful
Carsten: hard to synch progression of identifiers if these are meant to stay unlinkable over time
Achim: get ticket from the server; if long pause in data, can use that ticket for identifying session. After resumption get new encrypted ticket.
Carsten: assumes packet arrival and in right order. Need to think about this.
Kai: how do we address this issue. What's the right process?
Achim: can post to mailing list; but to TLS list or where?
Carsten: probably good to start at CoRE mailing list. Enough security people on that list.
Daniel: don't you leak identity anyway. Can spoof IP address and port.
Johannes: without encrypted one-time ticket can steal session
Daniel/Kai: no problem. MAC check fails.
Achim: discussion at TLS mailing list on version 1.3. Hannes and Stephen Farrell discussed in length. Good to read the discussion. If you have connection ID that is visible, someone can track you (see https://www.ietf.org/mail-archive/web/tls/current/msg20424.html and https://www.ietf.org/mail-archive/web/tls/current/msg20437.html).
Daniel: can always track: see TCP connection.
Julien: devices do lots of resumptions. Can track easily. Seem to have consensus on doing this for LwM2M.
Carsten: Need to look into this. Either mechanism in draft-fossati or something else without adding new long term ID. Useful to have something in every packet so server can find out when client has new address and can correlate packets. Something relatively light weight is useful.
Kai: would it be helpful trying to implement this on Californium
Carsten: helps implementing to find implications.
Julien showed slides about CoAP/DTLS feedback. In some mobile networks 20s timeout for UDP. Need to do abbreviated handshake or something else. Connection ID (draft-fossati) could help.
LwM2M object observation. If only one part changes, you need to send full response. Would like to send "patch" notifications.
Achim: experience that mainly triggered that need to set several notifications instead of one. Problems with DTLS and NATs etc. PATCH may be lost.
Julien: maybe can use e-tags to help on this
Binary SMS issues due to changes to 7-bit encoding and/or roaming issues. Now using base64 instead. DTLS handshake over SMS can result in operator blocking as spammer. Use SMS only for wake-up instead. COSE/OSCOAP could be solution at some point. Not sure if can do with one way SMS. For MNOs the SMS work, but issues for others.
High scalability CoAP/DTLS. Issues with come cloud providers not supporting UDP on load balancer. Need to cope with NATs still.
Carsten: issue with batch notification is interesting. Should discuss this. Have draft on text-based SMS more efficient than base64 (draft-bormann-coap-misc, appendix A.5.1).
Julien: with LwM2M the wakeup is 10 bytes. Easy for SMS. For configuration better compression is good thing. But need to figure out security.
---
Carsten: Discussing API issues; didn't cover RD yet. Who has RD implementations out there?
Kai: using one in Californium
Hauke: implementing one on Node.js. Looking into multicast discovery too.
Kai: application interaction?
Carsten: someone owns RD and has reason to run it. Someone wants to interact with that. How application exposes RD
Ziran: Cloud exposes RD. Retrieving part with .well-known used for discovery
Carsten: need for application to influence what RD accepts
Kai: Leshan implements subset of RD. That's what LwM2M does. Usage very restricted to LwM2M. Get events when device registers.
Kai: Californium implementation seems like "forgotten child". Californium tools package got only recently attention. Not as well maintained as the rest.
Carsten: paper from Jaime argued that more of the RD should be exposed
Kai: we couldn't see real use case for RD in cloud. RD locally makes sense for p2p communication, but not so clear for the cloud
Ziran/Kai: LwM2M needs to know if device is there.
Kai: but don't see use case for running RD beyond LwM2M use case. Has not been much inquiry for such service.
Carsten: this morning had quick discussion on how CoAP allocates and handles memory. Matthias trying to keep application decoupled from memory management. Arena style management, etc. Someone needs to write a nice paper about this. Everyone doing this in some way but not well understood area in general.
Ari presented slides with intro to ICE and initial ideas on doing ICE-based NAT traversal with COAP.
Not only NAT traversal but also traversal of other middle boxes. IETF protocol for NAT traversal ICE (RFC 5245). Not just a single protocol but a suite of protocols e.g. STUN & TURN.
ICE WG currently working on an update to ICE. Fixing errors and adding functionality in a backwards compatible way. ICE-bis split SIP/SDP way from base mechanism. New version is agnostic to the usage protocol.
Originally for UDP but also TCP specified. Used by XMPP, RTSP, HIP, RELOAD, OCF, etc. WebRTC main use case today. Also for multihome & dual stack address election.
Used in 3 phases: 1. Gather candidates, 2. Exchange candidates via an out of band channel, 3. Connectivity checks
Kai: Are STUN servers a public resource?
Ari: Yes there are some services today.
Kai: Can I use STUN to determine whether my IP address has changed?
Ari: Yes, but there are some corner cases where that doesn't work. That's why ICE will try all addresses.
Often first check on a candidate pair will go through your own NAT but will be blocked by the peer NAT. When the peer replies it will open a pinhole in that NAT and check succeeds. Once candidates are exchanged then the candidates are prioritised, those using TURN are given a low priority.
Question: is ICE applicable to CoAP?
May not want to use STUN and TURN protocols but can some of the existing infrastructure be used? Out of bound communication channel: Pub/sub could be used. May use this as a rendezvous layer but not for all of traffic.
Kai: You could create a specific resource on the RD for the purpose.
You could use CBOR for efficient encoding.
Achim : RD server would have to be placed co-located with LWM2M destination server.
Ari: Yes they have to be in similar place.
Kai: Sounds reasonable but sounds like working on the symptoms but not the problem.
Ari: The problem is beyond our control.
Carsten: What was discussed assumes we solved the problem of getting packets through the NAT.
Ari: A lot of the problems go away if endpoint client is in the cloud.
Kai: could extend a LwM2M server with some of this functionality.
Pub/Sub broker could be used as a TURN server. We already have a lot of the pieces in place.
Christian: Will we pick up options from ICE? Ice-lite, Trickle ice, etc.
Ari: ICE lite makes sense. Server could be a lite-ICE service. Trickle ICE may not be so relevant for IoT use cases. TCP simultaneous open also needs to be considered.
No draft as yet. Just early discusses.
Kai: Interest for RD as STUN server. Implementation sounds easy.
Ari: Can use of CoAP machinery for some of this.
Ari: how common is this use case; is there need for solution?
Christian: WebRTC uses ICE so CoAP over WebRTC
Ari: Do people see implementing this?
Casper: Yes definitely.
Kai: Yes in californium
Carsten: Will go into his resource directory.
Tobias: doesn’t see so many use cases. Thought that manufacturer of two devices could provide the infrastructure in cloud to relay traffic.
Ari: Where end-to-end latency is not an issue you probably don’t want to do this.
Carsten: When home uses expand networks, they stack NAT on NAT on NAT.
Tobias: Would be nice to see an actual use case from someone that has the problem.
Carsten: some work on unifying the APIs of CoAP implementations would be useful.
Open issues in libcoap include use of TLS library and platform specific code cleanup.
TinyDTLS still in alpha. First non-alpha maybe Q1 2017. Replacing ECC implementation
Oleg: got working on RIOT native port. But handshake packets seem to be lost and things get stuck. Proposed patches.
Achim: used year ago. Repeating of handshake wasn't problem. Made handshakes with PSK and ECC. Release version took up to 20 seconds. Changed into something Bosch-internal.
Carsten: high on the agenda for libcoap to get other TLS implementations in.
Carsten: have implementation of CoAP on Ruby. Bindings to Ruby on Rails. Has implementation of RD. Planning to put on coap.me.
Kaspar: JCoAP (based on nano coap). Yet Another CoAP, etc. Should add our CoAP libs to coap.technology
Achim: Nordic has Bluetooth platform with CoAP support. Another commercial implementation from Nordic.
Oleg: Zephyr people have also their implementation
Achim: Bosch has also implementation, but only with products. Is there implementation for iOS?
Carsten: Yes. SwiftCoAP
Tobias: also implementation at the App Store.
Carsten: SwiftCoAP implementation interesting since it uses a recent programming language
Kai: most important for use cases is that there's DTLS implementation.
Achim: some security issues with CBC.
Carsten: nobody uses with CoAP
Kai: with LwM2M specified as mandatory to implement with CoAP
Achim: has been reported that CBC needs to be removed
Kai: apparently came to LwM2M because some library only supported CBC
Stapling; client provides pre-looked up revocation information. But need to be using certificates to be interesting.
Kai: nobody uses X.509 certificates
Carsten: the idea is use the certificates only very rarely. Setting up things.
Kai: does anybody use DNSsec to validate keys? Need out-of-band mechanisms for RPKs.
Carsten: lots of DNSsec is RSA based. Could be issue.
Where should we meet in the future?
Kai: policy on where to host meetings?
Carsten: not really, but aim for useful outcomes. Will meet at Seoul with the IETF. Had meeting in US at March, will certainly happen again. What is good location of getting people together?
Kai: if want to attach to Eclipsecon, there's summer meeting at France, and following in US. Suggesting not to attach only to IETF, but Linux foundation, IoT open world, etc.
Carsten: which conferences people are traveling to?
Kai: IoT conferences are in their infancy. IoT conference in Berlin in September.
Daniel: one in Dublin end of November
Carsten: maybe planning for Berlin September event makes sense
Christian: IETF at Prague next summer
Kai: in Europe maybe makes sense
Hauke: RIOT summit with ACM conference in end of September. Will send pointer to the list.
Kai: embedded world is interesting
Hauke: will be at Embedded world. It's in February in Nuremberg.
Kai: would like to attend Embedded world
Tobias: Chaos Computer Conference end of
Daniel: Embedded world 14th to 16th of March
Carsten: will be sending few paragraph summary on the T2TRG mailing list. Recommend to register.
17:47 meeting ended