IOT Working Group
28th November 2023
At 4 p.m.:
PETER STEINHAUSER: Welcome, everybody, to the IoT Working Group session of RIPE 87. Welcome to Ripe. It's a pity with this beautiful weather outside we are sitting at the basement, we try to make this hopefully Working Group session, I think we have some really, really interesting presentations, hopefully good discussions and let's kick it off.
So, quick overview about what we are going to do today, as usual we have our introduction housekeeping part, then we have Anna Marie Mandalari from the university college of London, welcome back, she was presenting here many years ago already. Something from Eric van Uden from AVM about the META IoT protocol and then Christer Weinigel from Netnod, something very, very interesting about Roughtime, how to handle secure time for IoT devices.
So, first things first, housekeeping. So, we just have two topics here, first one is the RIPE 86 minutes validation and the Code of Conduct.
So the RIPE 86 meeting minutes have been published already and approved by the Working Group Chairs. You can see the link to the minutes in the bottom of the screen, so everybody wants to revisit them have a look, please feel free.
Now, the important part, participation; I mean, I think most of you are already familiar with the process. If you have a question after one of the sessions, please go to the mic, asking your question, please say your name and your affiliation, if you are talking for yourself or if you are speaking as a representative of an organisation or a company, please let us know that.
For those who are participating remotely, you can also ask a question using audio video that is possible using Meetecho. Or you can use the Q&A window to type in your question, we will then read the questions to the audience and to the presenters and ask for their reply accordingly.
Also, stenography is available on Meetecho, and you can also chat with the group, send one‑to‑one messages.
All right. So, any questions about that? I don't think so.
So, let's have a nice meeting and then I hand over to Anna Maria, thank you some.
ANNA MARIA MANDALARI: Hello, everyone. There are 22 billion Internet of things devices currently in use, some devices listen to us, some watches us, others know what we watch, and there is no such tool nowadays that we can use for giving back the control of security and privacy of devices that we have at home to the users. And there is a sort of user infrastructure because privacy and security on Internet of things devices is very difficult to control and it's very hard to protect users from ‑‑
Nowadays, fortunately, or I will say in the end of of this talk, unfortunately, you can buy some security solutions for Internet of things devices, that we call IoT safeguards, so these devices are like external boxes that you can install in your home and they claim to protect you from security and privacy threats of the Internet of things. So this is just an example of the devices that you can buy.
Why we are interested in this? So these devices claim to give control back to the user, they do device detection in automated way, they do intellectual gent profiling and vulnerability assessment, brute force detection, anomaly detection, content fittering, network intrusion prevention, if only this was true. These safeguards currently very ineffective for protecting your home and not even that, the Cloud interaction and data collection operations may introduce privacy risk.
So, we did this study that was published in the security and privacy conference last year and our main goals were threefold: Basically, the first goal of this research was what are the privacy and security implications of the usage of IoT safeguards; do the safeguards really detect threats; and what are the side effects of the safeguards?
It's very challenging to measuring them because they are closed systems so you need a black boxing approach and at the moment it's very difficult to find test‑bed, there is a lack of automation tools and a lack of standard test beds so how with emulation and prospective ‑‑ tools for testing IoT safeguards in real world setting.
User safeguards you can buy basically four types of safeguards. Safeguards are determined by the directly like add on software in your router, so it's like Mcof a fee ‑‑ partnering with router providers like ‑‑ extended box that you install and connect to your router and then you connect to all the IoT devices to the external box, this one defender, safeguards between your Internet service provider and your router or are spoofing for checking all the traffic in your home.
And for measuring them we build an IoT test beds that look at the UCL and we have hundreds of Internet of things devices, cameras, air fryers, anything that you can really buy on Amazon and we use like simple NAT as a bridge between the IoT devices and the safeguards so we are able to collect all the traffic from the IoT devices and we also have a between safeguards on the Internet so we are able to able to collect all the traffic that are extending over the Internet.
For the first goal what are the privacy and security implication of how a safeguard works, we want to understand if these devices are working locally or using the Cloud for operating and also if they use third party services to operate. So we collect all the safeguards network traffic, we check the and then we check the organisation, if the organisation is related to the manufacture then we classify it as first party, if it's related to content delivery network still first party, anything else is non‑first party.
We also collected all the traffic from the IoT traffic so from the IoT devices and then we check if this traffic was correlated with the traffic sent to certain destinations connected from the safeguards.
And we discovered that the majority of the safeguards yes, use the Cloud for and also some third party services like for example of an avira is a tracking service M‑Lab, McAfee, and even some services from an avira that is weird and all of them send basically metadata or data about your home in their Cloud and this imply like additional privacy implications, so Whois like ‑‑ who is violating your privacy it is not only the IoT but also the safeguards that may ‑‑ should basically protect you.
Considering the IoT devices identification this amazing tool they have and they claim to basically automatically identify all the devices that you have at home, for the majority of the cases it doesn't work. Or it's not accurate. You can see for example Avira wasn't even able to identify one of the hundreds of IoT devices we have in the lab ‑ fin box is working out okay still but it was misunderstanding or misidentify some devices and this is all can represent a privacy threat because for example, some of the functionality that these safeguards are implementing are based on identifying the IoT devices, for example theme box claim to mute all the smart speakers that you have at home, so you disconnect them from the Internet but if it is not able to identify properly it, then it means that it is not muting anything right, that it should?
The other research question that we had was like how these devices detecting the threats that they claim to detecting their web page?
What we did, we craft some security threats like for example anomalous behaviour, open port, password, DDoS attacks, contacting malicious destinations like PI I exposure and unencrypted traffic see if they are able to implement DNS over HTTPS and for doing this a methodology in which we simulate the threats we wait 20 minutes to allow the threat to be detected, we check automatically in the safeguards AP app the user got notified, basically the process 30 times. If the threat was detected at least once we say that the safeguards is able to detect that threat and this is the situation.
So basically, we served a number of 100 threats tend to be larger than a number of detected threats. Only 3 safeguards out of ‑‑ only 3 out of 14 threats are detected by safeguards and three out of eight safeguards do not detect any threats at all. And sometimes even if they detect threats, it takes a long time, like between 45 seconds and sometimes 3 minutes. And we test these different in a period of one year, in different periods and we got the same results. So the situation is not improving.
But we didn't stop there, we want also to understand what are the side effects of having these safeguards at home so we studied traffic overheads, if they overprotect us, I really doubt it since they don't even protect us so imagine overprotecting, the privacy implications for protecting we basically just leave the test‑bed without any threats and then check if we didn't simulate any threats for a period of one month, and then check if we get notifying in the app. We check network traffic overhead and privacy policies.
We discovered that they don't overprotect, only once we got a notification from B defender in which malicious destinations were contacted but then we manually checked and that destination was actually legit. So this happens only in a period of one month.
Some of the safeguards introduces some overheads, particularly the ones are using hard spoofing for detecting the traffic in your home, is no less than 10% of the traffic of the IoT devices so yes, there is an overhead. And we also study the privacy policies and we had numerous concerns, like sometimes they retain your data forever in the and then they say sentences like we take your data for, in accordance with legal requirements of the state that they work with third party partners and sometimes they send your traffic over the Internet, not even anonymised etc., etc. So you can see the results in this table.
So, we discovered that we need to strengthen the IoT ecosystem. For doing this, be we need to implement trust between the end points that we have in our home, like our smart hospital and our smart city but in the case case we need interconnectivity and we need tools for making users aware of what are the risk ‑‑ the privacy and security risk of having an IoT devices.
One of the solutions that we came out is doing everything at the edge, so use AI for detecting threats but not using the Cloud, like trying to have all the processing in the smart router. Of so, we basically need to use local traffic for improving the situations.
Another study that we are working on is, so another tool that can help to protect the users from privacy and security threats of IoT devices is regulations so we are working on a framework that is called COPSEC, in Europe you have cybersecurity guidelines and in US you have NIS and also some in the Emirates and like GDPR. But there is a lack of understanding whether IoT devices totally comply with these guidelines and privacy policies, and at the moment there is no enforcement, right, because it's very hard, implementing called the black box approaches S K.
So we propose a methodology for converting security guidelines in something that you can measure, something that you can measure live in the home router. So, we select the security guidelines and privacy regulations, we turn them into metrics, obviously you can cannot do all the security guidelines, some of them are not very really ‑‑ you can not really convert all of them in metrics in majority yes you can. We designed some experiments from the IoT devices and we produce a certification, a label, for the tested device.
We tested just few guidelines enough as in this, in this first that we publish and one is the number of unused open ports that are not used, and as you can see, most of the devices are not compliant with these guidelines, and also the number of protocols that are not recognised, so we have many devices that user protocol that is not standard and we also have some privacy violation like for example, one of our devices were violating GDPR because we are sending personal identifying information like your Mac address completely unencrypted over the Internet.
During our study for converting guidelines we discovered that the ‑‑ seeing there were so many devices that were not using standard protocols to secure the communication, we had a look in the local traffic, and we discovered that some devices were using always the same local traffic for communicating with the smartphone hub for triggering an activity. We developed an understanding for doing, replay of that on IoT devices and also methodology that use AI in machine learning for identifying that the attack was successful.
So what we do, we basically check the local communication, if there is no local communication it means that the guidelines, the security guidelines is already violated because one of the security guidelines say that the devices should be able to talk locally. So, if there is local communication we collect the traffic of the local communication, we then try and machine models for learning the responses and we replay the traffic. Replaying the traffic we check that the functionality in the app was actually triggered or not and later we use the machine learning model that we train on for not even directly the app but looking at the local traffic.
We discovered that the majority, so we studied like 31 devices, we discovered more than half of IoT devices we had in the lab are ‑‑ I mean, replay attacks was working, well working on them. We also test two scenarios, the one in which we switch off the device and we replay the attacks and it's always working except for smart plug in which we discovered when you are starting the devices then they identify ‑ whatever and the replay of attacks doesn't work any more.
We also disclose our fundings, are we ‑‑ the manufacturers, none of them replay except TP link but after 24 hours told us they did far more upgrade now, the vulnerability is not there any more, so we didn't actually test it because it was two days ago but we will test it as soon as I get back to London.
So you see how we are working on these IoTrim app that is working on the smart router and can detect easily vulnerabilities including vulnerabilities and privacy threats, doing IoT devices and what we want to do is releasing these Open Source so that any user how they are using IoT devices can finally be protected and be protected for real.
So, in conclusion, we quantify ‑‑ we basically measure ‑‑ we did an approach for measuring IoT safeguards and analysing the data practice, we develop scaleable methodology for evaluating the effectiveness of the safeguards ‑‑ detection threats for IoT safeguards, and all our software and data is Open Source, we also responsible disclosure our results with the safeguards and the thing is now we are working together with I think if for doing a reon energy optimisation, we are working with BD funder which had some European proposal together for IoT certification, so the good effects of this study was that safeguards manufacture now knows the vulnerabilities and they are taking actions for this.
Thank you very much for your attention, I am happy to take any questions.
(Applause)
PETER WEHRLE: We have microphones here, we can have a look into the Internet. We have the first question here in the room.
SPEAKER: Thank you for the presentation, from RIPE NCC. I have actually two questions. If you go back to slide 11 where you said, you showed which of the safeguards send traffic to the Clouds, I was wondering if you are able to give more insights on what kind of traffic was being shared because I am going to say something controversial, it's not necessarily a bad thing every time you use the Cloud, sometimes it could be for good reason. My second question: How does this play with MUD and all of that ‑‑ how does these safeguards work with the MUD, manufactured usage descriptor ‑‑
ANNA MARIA MANDALARI: No one use manufacture user description. There is no one IoT devices that we have in lab that is using manufacturing usage description and when I talk to them responsible for BD funder box about manufacture user description they didn't know that such standard exists.
SPEAKER: Okay.
ANNA MARIA MANDALARI: For replying to your first question, sorry. So we cannot see the traffic because we use black boxing approach so all the traffic we see and capture is encrypted we want to leave the black boxing approach something that we can use in the future when we don't have many capabilities in the home router but we just correlate the traffic that is sent from the IoT devices to the traffic that is sent from the safeguards so the quantity of bytes. When we trigger a specific action from the IT devices to the traffic that is sent from the safeguards at the same time of seconds later to a specific destination, first party destinations and we saw the number of bytes is very similar so the trends respect basically the trends of the action of the IoT devices, are it means all the traffic is ‑ to the Cloud, this is our assumption. Some safeguards, yes, half of them they send other thing. Some they send metadata, this was confirmed by them when we did the responsible disclosure so they admit they were sending metadata and we also checked this in the privacy policy and it was written.
SPEAKER: Thank you.
PETER STEINHAUSER: Okay. Anna, first of all, thank you so much. I was thinking it's bad, but it's worse.
ANNA MARIA MANDALARI: Yes.
PETER STEINHAUSER: I have one question so Peter Steinhauser, speaking for myself, one question that's bothering me a little bit. If you look at those safeguard devices and software solutions, given the, at least the feeling I have, the inefficiency of the solutions and the privacy implications, so is it ‑‑ what's a trade‑off? So from your research which is say better don't use them?
ANNA MARIA MANDALARI: Do you want a personal or scientific ‑‑
PETER STEINHAUSER: I am happy with both sides of it.
ANNA MARIA MANDALARI: I think that something is better than nothing, but still, we are far away from having full protection in our home and I think the solution as I said in my presentation will be working at the edge so trying to avoid the Cloud at all costs.
PETER STEINHAUSER: Okay. Another question before I give the mic to Michael. So, be what do you think, for instance, the IoT Working Group in RIPE, how can we participate ports, any ideas from your side what we could do?
ANNA MARIA MANDALARI: There is a big problem nowadays in research for IoT that this data, so it's very complicated, so hold the test beds ‑‑ all the study that we did is because we had the resources for doing our own experiments, so we got some money, we build test beds etc. So my idea is to have a sort of federated IoT test beds in which everyone researcher, people from industry, can use the lab for experiments with IoT devices and basically have an open databases on security vulnerabilities and privacy threats that are found everywhere in the world in that moment so, yeah, that observatory for privacy and security threats of IoT and for federated test beds.
PETER STEINHAUSER: Wow. Thank you so much, Anna.
MICHAEL RICHARDSON: So, you just said now, I was going to ask you the question similarly but you said something is better than nothing, but from what I saw in your slides, it looked like most of the safeguard devices were offering nothing to offering to disclose my private information to their Cloud service in perpetuity, so it actually sounds to me that nothing is whatever you are doing and that installing the safeguards sounds to me to be unsafe.
ANNA MARIA MANDALARI: Well, yeah, some of them definitely are because they are not offering any service and not only that you are also paying for these services so they come with expensive ‑‑
MICHAEL RICHARDSON: Isn't that fraud. Isn't that fraud, to be selling me a service they are not providing and then violating privacy? It sounds like a regulatory thing, in the UK has new things coming that are supposed to have labelling on some of those devices so it sounds to me these should be labelled as hostile devices, not protected ones.
ANNA MARIA MANDALARI: Any IoT devices that you can buy now, look at the ‑‑ that we found so this is why we need really this scheme and certification schemes, a tool we will be able to do live monitoring on the devices, in people's homes so something that can work in the IoT gateways and to my opinion this is for my ‑‑ my opinion, this will be the only solution to stop this, right?
MICHAEL RICHARDSON: So the related question is maybe in your lab, how much exercise do the devices get? Like, is there someone walking into the lab and ordering toilet paper through smart speaker regularly or turning the lights on or off?
ANNA MARIA MANDALARI: How many activities we replicate.
MICHAEL RICHARDSON: Do you have to script those.
ANNA MARIA MANDALARI: Everything automated, every time we do experiments we just click ‑‑ we basically run an automated script.
MICHAEL RICHARDSON: On a smartphone to tell it to do something.
ANNA MARIA MANDALARI: The ‑ can connect to the server so it's like an access point that gives connectivity to the devices and also to the phones. The devices can be controlled through the phone so we use AD B shell for clicking in the screen of the phone and controlling the devices, and basically we can repeat this how many times we wish.
MICHAEL RICHARDSON: So you don't have to have some more graduates wander in and ‑‑ do things to make it work.
ANNA MARIA MANDALARI: No, with the smart speakers what we do we connect ‑‑ normal speaker, to the server, next to the speaker, and then we use Google translate for triggering the sentence, what is the capital of Italy? Alexa what is the capital of Italy and Alexa triggers. Everything is automated, this is the strong part about our test‑bed, this is why I want to further it.
MICHAEL RICHARDSON: Cool. Thank you.
PETER KOCH: Also on the potential next steps, did you have, and maybe I missed that part did you but did you have a chance to do some outreach, talk to some consumer protection or other institutions about this? Second question, I am not sure maybe I missed that part, but is your lab environment, would that be able to intercept or interfere with the traffic to like research the effectiveness of such measures?
ANNA MARIA MANDALARI: Thank you for your questions. Yeah, so indeed we talk with many consumer protection organisations like one is consumer reports in US, we ‑‑ you can go online and you will find many blogs that they wrote based on our study and related test‑bed, Ofcom UK I am going to talk to them in January. The reaction when I always get when I do a talk related to these things, surprise like, I don't know looks like so surprised, so there is no really awareness about that he is threats from these devices and this is what we need to create and talk to regulators and what I think is that, unfortunately regulations are done by only lawyers most of the time, right? And this is worrying because the future of what needs to be regulated needs technical experts and this is what I am trying to do also here in Italy where I am part of the part of and talking with the consumers organisations.
PETER KOCH: If I may follow up and get a chance to respond maybe to the second question. But obviously at least in the EU there's a certain legislation around that is ‑‑ maybe comes from the radio equipment like the radio equipment directive and other things, the whole toolbox that usually contains market surveillance and I was wondering whether those institutions would be interested in your findings?
ANNA MARIA MANDALARI: I think so, I didn't talk to them, I didn't have the ‑‑
PETER KOCH: That might be a leader into that because they have the ‑‑
ANNA MARIA MANDALARI: We constantly talk with data protection authorities, with the information Commission officer, the Italian data authority but they don't have really the resources for opening cases at the moment.
PETER KOCH: They may not but the market surveillance is a strong tool there, they are after like these dangerous baby dolls that call back home and do stuff ‑‑
ANNA MARIA MANDALARI: Would be interesting, sure, definitely, thank you.
David: I am speaking for myself. So have you had any exchange with Open Source projects like, for example, AS blocking platforms like Pi‑hole to see what technologies they are using ‑‑
ANNA MARIA MANDALARI: We did a paper two years.
MAHESH AGGRWAL: That is blocking non‑essential destinations for IoT devices and what we discovered, so we did an automated methodology for understanding what are the destinations that are essential for the devices to work and what are the destinations that are not required for the devices to work, we did all these in our test beds and we tested 40 devices and 61 of the destinations contacted by these 40 were non‑essentials. We then take these destinations and compare with the blocking list that you have in Pi‑hole, mother board and other lists that are basically used for web browsing and we saw the majority of the destinations we saw from the Internet of things devices, they were non‑essentials were in ‑‑ weren't there because it's a completely different infrastructure and so destinations are really different so we did this study.
SPEAKER: Thank you very much.
PETER STEINHAUSER: Thank you, everybody. Great questions. I think Anna Maria is around and she would love to follow up, I am quite sure.
(Applause)
Then, now Erik will tell us a little bit about Matter IoT.
ERIC VAN UDEN: Good afternoon, everyone. If you are thinking now I have a deep dive into Matter, I have to disappoint you. That's not the goal of my presentation. However, we had a long discussion with Peter about what's happening in the world and why does it matter that we talk about Matter in this audience?
Because Matter is, I see there's a bridge into the Internet world and there's a lot of protocols where it would, in RIPE there is a lot of talking of and we said let's give a short introduction and some discussions, what we should do there, and why make it sense to have a deeper insight on it.
Just for this few who doesn't recognise who is we are the manufacturing of the FRITZ box, this small CPEs you find mainly here in Europe, for all technologies. And that's our main business but anyway, besides the connectivity, we have in our products, we see there's more hooked on, hooked on in several devices, hooked on in Wi‑Fi devices and from the part of smart home devices, that's why we said, okay, we have to do something, we have to go in a broader environment, so not only the connectivity or the FRITZ box but also the inhome world in this case, so what I'm doing in houses.
The interesting part is that because a lot of people ask me why are are you doing smart home using DECT‑ULE, there's a very simple reason: Most FRITZ boxes we produce have DECT on board and we use that technology for just telephone systems. And then the chip vendor from, in this case talked to us, are you aware with those chips you also can use smart home? And we are talking about years ago, what? Smart home. I already stated we are producing routers, we are not coming from the smart home world.
With this, we said, we built this very simple power plug, and this power plug was very successful, if you look to the figures, to the German institute for marketing research, we were successful. The reason for that is because we have so number of FRITZ boxes in the field and this makes it very simple that you can correct your devices to the Internet and switch it on and off so simple as it is, so simple as I described it, and for this, as already said, DECT‑ULE was at that time and at that time in fact the perfect protocol, because in this case we are not forced to introduce a second radio into the products, at this time, we had several options, I will come later on to that.
DECT‑ULE is a very simple protocol, but one of the big benefits, it operates in a regulated environment and regulated frequency band, instead if you compare with the 2.4 gigahertz band everyone can do and play in those bands what he likes to do, this is not the real solution, we think, and if you look to the ‑‑ one of the benefits this is power consumption and bear in mind we are years ago, so this is not something from the last years, it's a long time ago, so power consumption is really important for devices, battery operated devices, and of course for the power plug it is irrelevant but if you look to radiatore knob, it has ‑‑ you need something with less power consumption and really easy to connect and is a stable connection, does something what we used and we thought okay this is the right approach, is it the right direction? We already had the chip in the router so it was easy to use the chip for the same functionalities, in this case for telephony but smart home, that's the whole reason we used the DECT for smart home connectivity.
With this we created our own world, and this is important because this is the FRITZ world, and all the devices you will see in this slide are FRITZ devices, and goes from lamps to radiator to knobs, several versions, to door sensors and so on and so on, but all those devices are AVM or in this case FRITZ devices. Looks interesting, looks nice but relatively small world. So it's very hard and if you look to the world of smart home it's much wider than just those elements because in fact everything on the slide you will see that's it, are that's the only thing we have from AVM. Very easy, very simple, but you want to have more.
What you like to do is open yourself for third party manufacturers. So for this we made a next step and we built two new products. And the next steps are products with ZB interface we have gateway and a new upcoming router somewhere early next year with Zigbee included, we already said in the beginning, we are now entering the world of the Zigbee and with this we can connect more devices to the FRITZ world, but it's only one direction. We need also something that you have the smart home world can connect to the FRITZ world. So, there is it is. We think, within AVM this is the solution to open ourselves so, we are open from the world and we can connect, the Matter world can control the FRITZ world. To switch on, to switch off, to do all the things and not on the proprietory solutions as you find in the past and a Meta protocol, all the cards were for those solutions.
What is Matter, it's new, the final protocol was finalised last year so it looks promising, there are big companies like Amazon, Apple, Google, and so on, it is simple, are and it's necessary. It's open, it's royalty‑free, and this makes it very interesting protocol for entering the world and have ability to connect, control us to the FRITZ world. Only the fact we step into this market segment.
It should be very easy, Matter devices should work with other Matter devices. It's based on security protocols. It's very energy‑efficient and Matter is designed to have this, also intra‑operability to existing devices and I show you later on how this is done.
And maybe I am a little bit too positive but Matter is expected as the standard for smart home connectivity within homes but this is a little bit under discussion let's say it nicely but I think it still has the best guards for that.
How does it work and that's why I have to say we is in this case Peter and I, you see a lot of protocols running up and we know all those protocols have Working Groups within the RIPE community. So protocols like IP version 6, protocols with TCP and of course UDP, there's a lot of talk about this. So from my point of view, you have to think about it, what's happening and what is the influence within my routers, what is the influence of the traffic and we just had the presentation of ‑‑ before, we see what IoT devices might and can do within your environment and now we make it even bigger, even more devices and a lot of devices we connect to this world.
The interesting part, if you look to the layer 1, that is based on Wi‑Fi on threat and threat is in fact, I hope you don't shoot me, I see threat as Zigbee protocol with TCP so forgot the layers with ‑‑ from the Zigbee environment, it's just under layers are the same and on top you have the standard IP layers. As well Bluetooth energy, this is be used for the first adopt and as already said standard Wi‑Fi protocols so it is really integrated in your router, in your standard protocols. That's why we said we have to do something with it. And just thinking.
We did from AVM we said let's first of all introduce the gateway and the gateway is only from the FRITZ world to the Zigbee world in this case to make connectivity, but the gateways as well, our enters into the Matter world but this will be the bridge so we can connect from a Matter controller to a FRITZ world, as we always said we need both directions, I need to connect from my FRITZ world to a Zigbee world, as well as I need standard interface where I can control all my DECT‑ULE devices from a Matter world. That's the only approach we think it's relevant and only thing we think this is the right solution.
The interesting part of this is that the Matter stack finalised in the end of '22 so we are still, as far as I see it, in an experimental state, we show this Meta solution the first approach on the E files in Germany and Berlin, it looks promising but we were not there as an industry, also in the protocol and I learned something and the plenary presentation about secure timing and so on, it's not there, not finalised and whole Matter protocol is still open so there's still work to do, which means we as a manufacturer still have work to do, we are not there at the end.
To make it very clear, to make it very simple, this is the only thing we do, this is the approach we see and this is the approach what we think is the first step so you can control everything from your well known applications, as an example Google home you can control, now direct and without connectivity to the Internet, you can control your FRITZ world because this is also interesting part, Matter can work without an Internet connection. In the past you had a lot of solutions, the only work if there is ‑‑ are Cloud based so the only thing you can control is switch on and off your lights if you have Internet connection. When your Internet connection is broken and there are a lot of solutions on this world you can't control your smart home world any more. And with Matter there is no need to have an Internet connection, you can do it from your local network and we think this is the better approach, exactly the same as we always did within the FRITZ world so even without an Internet connection you could control and manage your smart home, that's the way it should work and that's the way it should ‑‑ from my point of view, I can't sell it to my wife if it doesn't work that day.
I took a little sidestep. Why ‑‑ I am involved in broadband forum and there are latest discussion we had a few weeks ago, there was discussion about the protocol TR‑369 or well known as USP, and from my point of view, from my vision, we have to do on both sides something, because USP is a protocol where we can monitor and control a lot of elements within the smart ‑‑ in your home, not only in the smart home but including from Wi‑Fi but as well as from smart home. So, this way, there is a lot of discussions between the broadband forum and maybe you know the CSA as Zigbee alliance, that is the same company, about what's happening, what are we doing there, are what do we need on 369 and already what about privacy? Do I want to know that a customer switches on and switches off his lights? On the operator's side. So this is something we ‑‑ we have to talk about this, we have to think about this, because we already learned privacy is relevant and we can't ignore it. So yes, you need something to do to make it easy, to make it more intra operable and make it more, how do you say, convenient for your end customers but don't forget privacy. So, there are a lot of talkings. They are absolutely not finalised yet, they just started, and this is something what I think it will be continue and I don't see on a really short notice here and solution or correction but anyway, we are there, it's happening, and let's wait and see how this will continue.
With this, I show you, in fact, what we can do. This is the whole world what we can connect, this is we can do from the FRITZ world and with Matter we make it more expendable ‑‑ extendible is a better word and you can control everything including smart home devices, that's what I ‑‑ my statement here. This might be interesting to follow up.
As already said, if you like to deep dive please visit those links, you find a lot of information about all the protocols as well as the AVM, feel free to send me an e‑mail, I probably will forward to development but anyway, it's worth and also what I had with Peter, let's do it also on the mailing list because I think this will be relevant for the RIPE group to have, to realise what's happening in this world and to realise what we are doing over there, so I hope ‑‑ I give you a little bit of impression what's happening over there, as already said it is just a quick and short and brief overview, but it's just for me is the wake up call, be aware what we are doing there. Thank you for that.
(Applause)
PETER WEHRLE: We are now open for questions, especially also the 19 people on the Internet so take also the chance before you do it, do deep dive on your question. And got answers straight ahead.
Tom Hill: I am an employee of British Telecom, I am also personally a user of FRITZ box at home and I quite enjoy your stuff so I say this with a lot of love. But I think you may have missed some of the standards work going on in this area, the Snack Working Group in the IETF in particular and it fans out into a couple of the other Working Groups, I think there's fundamental definitions that are being made there that will inform the broadband forum in the CSA in a fashion and certainly would inform the work that you are doing with the CPE, in particular one of the things that ‑‑ two things in particular, one Matter should be IPv6 only which is great, we love this, but also stub networks in particular shouldn't be transit networks so I was looking at your diagram with the interactions between them and I was thinking okay, does that fall under that definition and I wasn't sure. I'd love to have a chat with you about v6 only transition stuff but it's out of the context of this. Please do and get involved in the Snack Working Group because I this would benefit from your input.
ERIC VAN UDEN: Thanks for that, for my preparation with myself and internal I refocus on the CSA work, that's correct, so I had a lot what's happening I A T, what's done here, and absolutely correct, I then looked into the IETF what's done in this case, so you are absolutely right. Thanks.
MICHAEL RICHARDSON: We should actually do ‑‑ we should actually have a presentation next time on Snack, that's actually a good idea into this Working Group, whether it's me or him or Ted or whatever we can figure something out: But what I was excited to see your TR 369 interaction and in the 1B COP we did a number of years ago, that's actually like what we we wanted to be able to do, we wanted to be able to say, hey, there's this protocol, you should use it, that's the best current practice and we discovered ‑‑ so, that's how sounds you are actually finally doing that and I think that's really exciting and I would love to hear more as it goes forward into here, I think the broadband forum work is mostly open, the CSA Matter stuff is not and you said it was royalty‑free and I don't think that's quite true.
ERIC VAN UDEN: What I find on their own website
MICHAEL RICHARDSON: It's royalty‑free to download the spec but in order to go through the compliance mechanism you must be a member and they have a bunch of stuff in there, some of it involving Blockchain, that basically compels you to remain a member forever, so not just like the IEEE where you get your OUI and you stop paying, no, you are going to have to keep remaining a member. I think it's difficult for many manufacturers that are not Google scale to do that and maybe you will find where it is. But I'm still really excited about the merge, about the overlap and come tell us more.
ERIC VAN UDEN: Based on, I heard two elements. First of all, on USP Stack, what we we learned from the CPE environment we are a little bit surprised because we introduced USP and I have to look to my colleague, one‑and‑a‑half years, two years ago more or less, as one of the early adapters within the USP environment and we had some vendors and some chats with them as well and also ‑‑ I said you are quite far ahead, and it surprised us ‑‑ I absolutely agree with us that USP is something very important because we get rid of the old‑fashioned TR69 and we move into the modern world with a little bit more possibilities, but it surprised me. Of course we are not ready yet completely, don't misunderstand me, we have a lot of work to do within the USP stack.
MICHAEL RICHARDSON: From what I understand there's a fair bit of I am going to say disagreement, market opportunities for different encodings, different transports and whether this is your CPE talking to your ISP, which is tier 69's real thing or to what extent your mobile phone now gets to talk to your CPE and therefore control the DECT devices and that's the part I think is exciting and I think it's probably less mature because other guys are looking at ISP inter operations and they just hate soap, tier 69 was all soap and everybody hates that. Thanks a lot.
ERIC VAN UDEN: The second question is your remark based on the programme, I have to be very careful. But let's say this way: If you look to the Wi‑Fi standards, you have the IEEE, with the Wi‑Fi alliances, we listen to the IEEE for the Wi‑Fi implementation, maybe this answers your question with the...
PETER KOCH: First of all, congratulatione to Michael for mentioning Blockchain. And
MICHAEL RICHARDSON: It wasn't in a good way.
PETER KOCH: Without a reason then. Thank you for coming and sharing this, I think it's important to connect these worlds and I think with these pointers in the direction of the IETF one mission of the Working Group is already accomplished like connecting these things, pun intended. On the other side, I ‑‑ I don't know anything about Matter, I would like to learn more and maybe go into some details and then Peter mentioned doing something until the next meeting. May I make a suggestion that if you have a time and there's interest in the group, that you may be able to, because other Working Groups have been successful with having an interim session of an hour or so or Zoom or something, that, if you are willing and have the time, that you explain in a bit more like technical detail where in this whole protocol stack Matter is having the roles, that might be interesting and might inform the discussion in the connection with what happens in the IETF and elsewhere.
ERIC VAN UDEN: I would love to but I need some preparation for that but this is exactly the thing was said. Okay, what can you have in one slot here? So ‑‑ but I need a little bit more, technical details and I would love to do it but I need some preparation and I can offer this. Peter, my offering is there.
PETER KOCH: Thank you so much.
PETER WEHRLE: I started quite new and the group was quite quiet in the time between the meetings and maybe that is a chance to bring in a little bit more blood into the discussion, especially if you are just compared the topics for quality standards and security, there's a new standard coming up and so, combining that things and learn from each other would be a very great thing and we are maintaining the mailing group as well so whenever somebody feels that there can be something for the topics so just use the mailing group to make each other aware and be happy to have online session in the middle of this and the next RIPE meeting. So, it's up to you to join, so we have 18 people on the Internet so we still had not yet a question out of the Net, Peter, how it looks like?
PETER STEINHAUSER: Not yet, but I have a quick comment speaking for myself. I think it's important that you mentioned the privacy situation T R 369 so the specifics about T R 369 are that you can have several controllers, so also the device, the home user himself is using or herself is using to control the home network can use this protocol, but from the ISP side, frankly speaking I don't want the ISP to see what's happening in my home network, and here, I think in the BBF it's very important to figure out what would be the actual use cases for the ISP, what is the interest of the ISP because I mean, the ISP is supposed to provide networking, that's the job of the ISP, not digging into my private data at home.
ERIC VAN UDEN: That's correct and the direction goes more or less and also here, that, how you say it, the connectivity, the switching world and the ‑‑ maybe the status world and there's had in the plenary, we were moving more and more and data analysers and it looks very promming and from the BBF digging into entering to have better connectivity and learn from the whole environment and so on and so on.
And including myself, I have the big question‑mark what about privacy? I do understand the goals and the visions but what about privacy? That's also from my personal ‑‑ I agree.
MICHAEL RICHARDSON: The ISP mostly has no business in any of it but they may have a rendevous role, and a specific case, my mother lives about 100 kilometres from me, it's really inconvenient to go and fix her computer, particularly her home router because that's the rest broken, and that's a good example of where, actually, you know, you are basically dealing more with care for other relatives or other places and you need to do something and, you know, actually, it is useful to find out if your mother's left the stove on, your 90‑year‑old mother has left the stove on when you know she is at your house, right? That turns out to be a valuable thing for things, and well the ISP has no involvement, they do have a rendezvous but they are the only one who knows where my mother's home is or what IP address I got today, right?
ERIC VAN UDEN: I see one addition to that, if you look to what's in the Matter protocol it's talking about IPv6, it's an IP device and we learned in the previous presentation okay it's now my cooker a ‑‑ a device, is it jamming, I think it makes worth it, we know in the protocol because that is one of the abilities in the USP protocol, we see who is communicating, this is, this is bullshit coming over, that we can control it, and that's the approach we think it might be relevant to have a look on it. But look about privacy as well.
PETER STEINHAUSER: Okay, thank you so much, Erik. Thanks a lot.
(Applause)
Now, handing over to Christer from Netnod.
CHRISTER WEINIGEL: So, hello. I work for Netnod in Sweden. And as a bit of background, I work quite a lot with embedded devices, mostly on Linux, not really on tiny devices, IoT ‑‑ or really very small, I haven't worked that much on devices like that but I have a background in sort of working with hardware so I sort of understand them but I haven't worked with Internet connection small devices.
So, let's get into it. I am going to talk about time and sort of accurate time is important, there are lots of protocols on the Internet that depend on accurate time, you have DNSSEC, TLS, and TLS is the basis of a bunch of other protocols, both DNSSEC and TLS they need to within a few minutes to within a few hours because you want to be able to validate the certificate. What's the risk if you don't have good time? Well, if somebody can trick you into using really old certificate it might use old, by now broken encryption algorithms or assigning algorithms that it's possible to break them just brute force them because MD 5 today isn't secure any more. Any problem might be you might be tricked into using old information or leaked information, if somebody gets access to a backup tape from your bank they might be able to trick you into believing they are the bank, if you don't know what time it is.
And then you have other examples, application itself might need time, so at a hotel like this if they have a door which is supposed to be open at 8:00 in the morning, because there are always people there at 8:00 in the morning in the reception, well if you can trick them into opening the door at 6:00 in the morning somebody might get in and steal stuff. There are other reasons why time might be important. If you want to start syncronising industrial processes you might need time, milliseconds, good sort of accuracy.
So how do you keep time? Just about any device can keep time when it's powered on so you have a time interrupt so you can always count if I get 100 ticks per second a second has passed but what do you do when your device is powered off? Some IoT devices may not have a realtime clock, you might need an external chip and an external chip costs money so when you are building lots of devices, millions of devices you might want to cap down on the hardware. There are other other devices that do have a realtime clock in the hardware,Raspberry Pi, that doesn't come with a battery, you otherwise every time you power off your Raspberry Pi it loses time. There is something can go you pull the tab, connect the battery to the device and it has no clue at all what time it is. It might have been sitting on a for a year or five years, there's also another problem related to sitting ten years on a shelf, when you start up, does any of the infrastructure you rely on still exist? TLS, route CS certificates they might have expired, the DNSSEC root keys might have expired, I believe DNSSEC has sort of a solution where you can follow a chain forward in time, I don't know if TLS has the same thing. So, especially for IoT devices that might be sold on a shelf, there can be issues with the current protocols.
So, if you need time, how do you solve this? Well, since we are talking about IoT we are talking the Internet you can usually connect to the Internet and talk to server somewhere and we have the good old NTP protocol, that has been around since at least 1984, I believe that's when the first sort of specification of NTP arrived. The problem with that is it lacks security. There are some attempts at security NTP but they don't really scale to Internet sizes, they scale to tens of thousands of devices, key management is a pain and you can't do this with millions of devices. Another problem ‑‑
Another problem, there was a protocol key and basically it's not safe enough, the people who did it, built that protocol didn't know enough about security to make it really secure. So, here comes NTS, something I worked on with the ‑‑ or worked to make it into IETF protocol so NTS adds security, it does that using TLS and this gives us a bit of a boot strapping problem because if TLS relies on time and you need TLS to get time, where do you start? There are ways to get around it, you can say well, we will ignore the time when we do the first check, then we get time, then we go back, look, does this look reasonable? But it's cumbersome and it adds a bit of ‑‑ it adds complexity and is not foolproof either.
And another problem with NTS is since it relies on TLS, many IoT devices, small ones, don't have TLS or don't have TLS which is sort of new enough, has all the features we might need for NTS so if you look at IoT devices, if you have a fight between features and adding security, most manufacturers will go for features because that's what sells the product, the security is just a problem when you have a security failure or you have a break in.
There are also other protocols that could be used, use HTTP because there is a date header, you can ask the server give me a web page and I will get the time, that's part of the response, you have the same problem HTTP doesn't have any endescription or security, if you use TLS you depend on TLS again.
Another related problem or related problem to time, is what do you do if you have a single point of failure because a lot of devices today where you can specify an NTP server you can only specify one and if that one breaks or is comprised then you have an issue because you can no longer trust time from that single server. So, how do you get around that?
So, what I want to present is a possible solution, it's called Roughtime, it's an IETF draft by a bunch of people. I got involved sort of two, three years ago so I don't really know about the beginnings of Roughtime but as far as I know, it started out as a way to solve the boot strapping problem so the goal wasn't to replace NTP, the goal was to give ten second accuracy so you can validate TLS certificate and then you can start getting time some other secure way, when you have TLS DNSSEC, all that infrastructure is up and running.
It is secure, it has very low CPU usage, very low footprint so it's probably suitable for small resource constrained IoT device. Some of the concepts in Roughtime is that you use ED 252519, you use that to sign the responses from the server, that way the server has a private key, can sign, there's responses and the clients can verify using public key. This makes sort of it ‑‑ key distribution a bit. It also uses Merkle tree but I will get back to that.
You have keys that live forever. This takes away the boot strapping problem because if you have those hard coded keys and the names for those servers in your firmware, well, then you ‑‑ you already have them, you don't have the issue where you have to use somebody else or follow, look at root CAs, you have all the information you need. This is a bit of a trade ‑‑ it's a bit of a trade‑off because what you do is you replace the boot strapping problem with a key distribution problem and key distribution is hard or hard to do well. But the basic idea is you have a bunch of Roughtime servers, probably add sort of the names and keys for 100 servers, put them in your firmware and what you do when you boot up you take your list of 100 and choose ten of them and ask for time and if enough of ‑‑ if you have a consensus, if a majority of them let's say five of them also give you the same time you say this is good enough, I can probably trust this time because even if one server has got compromised or one is broken and because the clock is bad it gives out the wrong time well, if you see five servers agreeing on what time it is you are probably good to go.
So this removes the single point on failure and this is also sort of how you solve the ten‑year on a shelf problem, that the bet is that in ten years, enough of those 100 servers will be still up and running so we can get time from five of them.
I am not sure if this is a good but that's sort of the idea of Roughtime.
Another important thing is that Roughtime is intended for devices where you can update this list so, when you have boot strapped your device the first time, have a secure connection you can download new list or worst case you could say I want download new firmware because you are going to need for your TLS stack anyway. The idea is if you can update the firmware this is good enough because you can update the firmware and get a new list and if the list is a few years old when you boot up the first time it doesn't matter and you get an updated list.
So, one thing to note here is Roughtime, the concepts here could be applied to other protocols, so it doesn't have to be rough time but Roughtime is right, a draft, it's out there, so that's what we are building on right now.
Roughtime has a few rather neat ideas I'd say. One of them is that you have a nonce, so you have a unique identifier so you fill in with random data and you hand this unique identifier with 32 bytes to the server and this is to avoid replay attacks that we have heard about before. This is necessary for security I'd say, so it's basically free. And if you have a 32‑bit sort of block of data well it doesn't have to be random, for example if you want to you could say let's take a document I will, using secure algorithm, I get 32 byte hash, I can hand this hash to the server as to nonce or the unique identify fear, the server signs this together with a time stamp and I get it back and I have a signature from somebody else which says at this time point in time I had this document, I had access to this document. So if I sign with the company says you are not allowed to share information you have received from us, I can actually prove that I had access to this document before I signed and and A with you so I am free to share this information which could be very useful. There could be other users for this kind of time stamping, it's called stamping authority, there are other protocols for it but Roughtime could be a very light wait type if you want to.
Another thing you can do is to say my document is actually the signed response I got from a different Roughtime server, so you can start changing those, get the next server to sign that reply, get the next server to sign another reply and I am not going to say in Blockchain but the idea is that you can have a chain of replies and they should all come in sort of increasing time order if you look at the order between the signatures you have, well they should be in order because otherwise something is broken and if one server is disagreeing, if the time you see from one server and ten servers on the other side of it disagree, you can probably quite certain that this is server is actually broken. This server is either compromised or the clock is broken so this gives you a way of auditing or having accountability for Roughtime servers. So, if you want to remove a server from the list because you say this server is bad, it's giving bad time well, then you have a cryptographic proof you can hand to the maintainer of the list and say, hey, I have proof, take it off, no discussions needed.
Next thing I want to talk was Merkle tree, is a way of saying well, we are going to hash multiple documents, we get one signature at the top, so with Merkle tree you can actually sign requests from multiple clients with one ED 25519 because it is kind of heavyweight so if you can sign multiple requests with one signing operation this will use the CPU load on the server and this is a good thing if you want to scale up to billions of IoT devices talking to you wanting to use Roughtime.
And Roughtime has evolved a bit now, so I'd say it's a pretty decent generic time protocol. It has changed, it has now a lot better accuracy than ten seconds so the time stamps are down to micro, it can run on really resource constrained devices and NTS sort of has problem with that, and it still solves the original problem to solve the boot strapping problem and for me, this adds a bit of complexity, and this is a bit of a trade‑off, so some of these ‑‑ this complexity conflicts with original goals of Roughtime, since you have microsecond accuracy at the time stamps, when you are doing sub‑second accuracy you need to think about leap seconds because if you add or remove seconds, if you care about fractions of a seconds that's quite a lot. If you only care about ten seconds you don't need to care because it's within the error margins. Roughtime has atomic time which is UTC without the leap seconds. Useful for a scientist mostly. Roughtime has support for UT1 which is solar time which is useful for astronomy. And none of this is really necessary if you need ten second time stamps so, do you really need this? Personally, me, with my embedded hat on, I like having microsecond accuracy. I don't see the need for TAI or ‑‑ I can't really justify the need for UT1, that feels a bit ‑‑ that's my opinion ‑‑ unnecessary, and I don't know. So, what do we want to do with Roughtime? Well, Roughtime development right now has stalled. For example, our guy who ‑‑ guy who is associated with Netnod has been working Roughtime he is doing his PhD he said come back after Christmas, I don't have time right now. Other people have been kind of busy with other things. Another problem with Roughtime it's kind of fragmented right now there's draft version 4, 5, 7 and 8 and they all are incompatible, they don't talk to each other. Right now it's a pain to try to implement Roughtime. So, we have got funding from RIPE to actually work in Roughtime to try to bang it into shape and what we want to do going forward is basically get help from you, we need help with our requirements. What is actually needed in a protocol like Roughtime and one of the sort of groups or interest groups we see could be interested in Roughtime are people doing IoT, resource constrained devices. This Roughtime, the draft the way it is written right now, does it fulfil your requirements? Have we missed something? Could we drop things like UT1? I don't know. And since I'm sort of embedded, Linux not really time devices I have my opinions but I might be totally wrong so we really need input. Our goal or our plan is basically, well, let's write a requirement document and get input from all you, take that requirement document, feed it into the draft and try to opt it to draft so we fulfilled the requirements and maybe drop things if people don't need them. After that of course work on implementations, get those into shape so everybody who has been ‑‑ everybody who has done a Roughtime implementation get them to support the latest version on the draft and after that, make it into ‑‑ get people to implement it and then of course try to submit it to the RFC at IETF and make it into proper IETF standard ‑‑ or standard isn't right word but close enough.
So, here are some resources about this. You can find the latest version of Roughtime on IETF. I have a working implementation of Roughtime version, 4, 5 and 7 running on real devices so we do have working code. I am going to implement version 8 pretty soon but it's pretty new so I haven't had time yet. Netnod we run Roughtime servers that we plan to keep running as long as people are interested in Roughtime. Markus has written the Roughtime we are using on the server side, he runs Roughtime.se, Cloudflare who were driving, they were part of people who actually started out with Roughtime, they have a bunch of blog posts about the background, what the goals were for Roughtime. And of course finally, it's me, so my mail address, so if you are interested in this, either talk to me here or shoot me a mail because I would really like to get input so we can get started and kick‑start this.
I think this was all from me. And any questions?
WOLFGANG TREMMEL: Wolfgang Tremmel, I would love to see this on ESP 32 and on ESP home
CHRISTER WEINIGEL: Here is ESP 32. And the Sort Code is [indicating].
SPEAKER: I was just wondering how did you get the accuracy to go down from 10 seconds to micro seconds and is that still work in progress?
CHRISTER WEINIGEL: It's the resolution of time stamps. So, originally it was ‑‑ I think they used whole seconds. Now the fields for the time stamps are micro seconds. And you are basically, the accuracy is up to your network. If you have a sort of roundtrip time of 100 milliseconds you probably will not get micro second accuracy but if you are using local network you have a millisecond ping time average time, and you believe that your latency going to the device on the latency coming back, if it's sort of the same in both ways well, do a bit of averaging and you can actually get really good accuracy at the end.
SPEAKER: Marco Davids: Thank you for the presentation. Just a simple question I suppose. But you said there is a list of Roughtime servers in the software, in the firmware, is that based on DNS names or IP addresses? The reason for asking you might still have a boot strapping problem ‑‑
CHRISTER WEINIGEL: Good question. I don't know, right now in my implementation it's just a string and you do name lookup or ‑‑ my C code, I put in IP addresses but it's actually, it does it in lookup so it would work with names. I'm not sure. I mean you could say well we will use plain old DNS without any security to look up the IP addresses, the thing that we ‑‑ that makes it secure is that we have the public keys so somebody who can interfere with DNS they can always do a denial of service attack but they can't trick you into getting the wrong time but if you can do denial of service attack on ‑‑ you can probably totally disrupt communication anyway so open question, and I think it's up to the implementer, do you want to bet that the IP addresses are stable and still be the same in ten years or do you bet on the names being stable and DNS still working in ten years? So I don't know, actually.
SPEAKER: Thanks.
PETER STEINHAUSER: So we have ‑‑ we have three questions from the Q&A session. So the first question is Niall O'Reilly, RIPE vice‑chair:
"How best to give input to Roughtime requirements, information on GitHub?"
CHRISTER WEINIGEL: I am not sure, I believe the mailing list may be the best place to start, there are a couple of different Roughtime projects on GitHub and there is one which contains the current ecosystem for Roughtime which is basically the list of existing servers. That might be a good place if we want to start adding issues, but that's sort of ‑‑ I am not sure. Start with the mailing list or mails to me and we will see where we end up.
PETER STEINHAUSER: Right. The second question, I mean I will read the question and the other comment, I struggle a little bit with figuring out what Karen wanted to say, from Karen O'Donoghue, and NTP Working Group co‑chair how does this work align with the NTP version 5 work ongoing in the IETF, is it possible some of these features could be there? And she said: Apologies for putting questions here it seems to have bounced from the remote queue, good work.
CHRISTER WEINIGEL: Roughtime is right now a totally separate protocol from NTP, it's a separate, it doesn't have anything to do with NTP at all. As I said before it might be possible to actually take these concepts from Roughtime apply them to NTP so it has trade‑offs because NTP has issues and one of the goals was to solve some of the issues with NTP but you could take the same principles with multiple servers, 5529, could apply to and work perfectly fine but won't solve the current issues. NTP version 5 in the works which people working on within the NTP Working Group in IETF and the same ideas should probably work quite well with NTP version 5. So, I am not sure if the protocol would be Roughtime in the end, but right now, Roughtime is what we have and I think if we can get, make the requirement document and say hey, these are the requirements, we are in much better position to say we need a new protocol or maybe could do some NDP as well. I don't want to distract from NDP works and we have Roughtime right now and let's talk about that. It would be fairly easy to make me change my mind.
PETER STEINHAUSER: Karen is following up with asking: What I was wondering was is it possible to improve NTP instead of creating a third times synchronisation product including NDP? I think you already answered that.
CHRISTER WEINIGEL: The answer is yes, right now.
SPEAKER: RIPE NCC again. I might have a question, could be complete rubbish so sorry in in advance, if we want to use the Roughtime we should have access to this list of public servers or whatever
CHRISTER WEINIGEL: Yes.
SPEAKER: Is it possible to replicate this within a private set‑up, these big factories that might be using private LTE to run these IoTs or whatever without exposing them to public servers?
CHRISTER WEINIGEL: Definitely, it's just a public list of keys, you could use a can bus if you want to or you could use Laura 1, it is just a packet with time stamps over UDP, over a datagram protocol, you sign the response with a private key, and then you check the response against a hard code list of public keys you could do on UDP, on any data protocol, over TCP if you wanted to and you could ‑‑ there is nothing stopping you from saying I have my own private Roughtime infrastructure, if I'm in a car using can bus I could say my master control in my car is a Roughtime server, has a private key and all my devices are configured with a private key for that server and that's totally separate from everything else. You can use a protocol like Roughtime.
SPEAKER: In that case we have to work with the manufacturer to get the list of my private Roughtime server ‑‑
CHRISTER WEINIGEL: You have the key distribution problem which is a hard problem to solve but it's a trade‑off and I think it's actually ‑‑ I think it's a decent trade‑off but since it's public key system, a manufacturer could actually publish say that our control is from our company, they use this public key. Or they might say every car has a unique public key and when you configure your device to work in the car you have to configure the private key for this specific car and it will work with this specific car and then it's locked down.
SPEAKER: Thank you.
CHRISTER WEINIGEL: Once again that's requirements, please give me input, is this a use case which is important? We should put in the requirements document so thanks.
PETER WEHRLE: I think we can close the Q&A session so we are slightly over time but I think it was worth it. And just to think about, get active in the community, get active in the mailing round and so hopefully we can have one or two intermediate sessions to progress on certain things, while we have the emerging things on security, we have new standards growing up, we have new ways we want to go and so I think it's interesting to keep each other aware and not just half a year, from time to time, to use it more often and then this will be the right forum.
PETER STEINHAUSER: Yeah. Nothing to add from my side. Something out of scope of this session, I was asked to inform you that the PC elections are open since 4 p.m., you should have received e‑mails with that, so just keep in mind to vote. With that, thanks, everybody, for the participation, thanks so much to our speakers, good discussions today and I hope to see you all on RIPE 88. Thank you.
LIVE CAPTIONING BY AOIFE DOWNES, RPR
DUBLIN, IRELAND
