RIPE 92.
Side room. 2 :00pm
IoT.
PETER STEINHAUSER: All right. Good afternoon everyone and welcome to the IoT working group session here at RIPE 92. So, let's have a quick look at our agenda. So as usual we start with introduction housekeeping, going over some stuff, formalities we have to handle, then we have a couple of talks. And at the end we will talk a little bit about the co‑chair selection, my term is ending with this RIPE meeting so we will handle this as well.
For the housekeeping part, we first do the RIPE 91 minutes validation, go with the code of conduct and talk shortly about how to participate in person and remotely. OK, so the ‑‑ there's a typo, no worries. The IoT working group minutes from RIPE 91 have been published on the IoT working group website, you see the links at the bot some to review for everybody interested in that. Our code of conduct, as you know, we try to be, to make everybody feel welcome here, so there's be polite, treat everybody with respect.
How to participate in person. So if you are here and have questions after the talks, please go to the mic, ask your question, say your name and your affiliation, maybe also a hint if you are here for a company but you are expressing your personal opinion an just say, OK.
I am speaking for myself, not for my company. Just to make things clear.
The remote participation is handled by Meetecho. You can ask your questions directly using audio or in the chat. Here, the same situation with the affiliation, make that clear. What is also important, if you are attending remotely and want to use your mic, we would appreciate you using headphones. We had some issues with feedback loops that were a little bit annoying and the technical team might cut you off in case.
And with that, I would like to start with our first speaker. And here I will hand over to Anna very quickly with the mic.
ANNA MARIA MANDALORI: Thank you Peter. OK, so so our first speaker is Jim Mozley from Infoblox talking about DNS and DNS security.
JIM MOZLEY: Thank you. Yes, you can hear me, good. I am Jim Mozley from Infoblox. I am wearing a hat of an IETF draft author along with a number of other people. Sorry, is there some strange echo I can hear. OK.
All right. So what I want to do is talk about the draft that we have done based on the research work done by UCL in INRIA and as I say, I am here with an author hat on, a DNS hat on if you like, but the work here is based on some research that was done and presented at RIPE 91. There's a paper as well that you can obviously look at that documents all of that research and isle come to a couple of examples of that.
This resulted in us creating a draft code IoT DNS security and privacy guidelines. And it's been adopted by the IETF IoT ops working group, try saying that after the whiskey BoF. We have got to the stage where the IETF DNS directorate has reviewed this and we issued another draft a couple of weeks ago. You might think of the IETF DNS directorate as a Glasgow nightclub bouncer that says you can't come in here with trainers, but, in fact, they are very helpful people and we thanks Patrick for his review.
Right, so I said I would do a couple of of examples of the research findings. And this just kind of illustrates really the issues around IoT devices and their DNS behaviour. So the research showed that 40% of the devices that were part of the study actively overrode the DNS servers they were given by the network operator. So, for instance, they were using Google's open offer, that's clearly an operational issue if those open resolvers will unavailable, it might be a security issue if a network is configured such that you don't query those open resolvers.
The other thing ‑‑ and I pick this because not because I am paid for a particular kettle manufacturer, but because it illustrates a point very well, out of those 35,000 devices, four of them had very poor DNS transaction ID generation.
And really they should have looked like the swan Alexa kettle on the right, though why anybody would want to connect their kettle to the internet, I have no idea.
So why use a draft to fix this? Well, we talked about and thought it was a good neutral place to provide guidance but obviously the IETF is a place where the DNS standards are develop and there's talk of the DNS camel so many RFCs and bringing this together into one place that can provide guidance for manufactures and to an extent network operators, although networks do vary. Would be a good thing to do to bring it all together in one place.
And one of the goals there was so that it could be referenced by regulators. There's increasing attempts to do certification around IoT devices, this kind of thing, whether it's jurisdictional or sectoral or whatever, this would provide guidance around that.
So I wanted to go through some of the key things in the draft. I am not going to send everybody to sleep after lunch by quoting RFC numbers, so I just thought I would go through some of the key areas. And this is probably the way this diagram is the way that everybody's sort of learned DNS; when you query something like how does DNS work, get this kind of a picture of a stop resolver, the advice in this case, querying the resolver and finds answers down the DNS tree and then caches that and returns that to the client.
And if we think about the draft, the context of that, the first and obvious advice to manufactures is please, please, please conform to the RFCs that are there and we highlight conformance based on the findings of the research, things like do use IP addresses you have been given, do randomise source port and transaction ideas on the TTLs, etc.
The next part is really about encrypting traffic between the device and the resolver. The encrypted DNS protocols, DNS over HTTPS TLS QUIC and cope is a possibility within the IoT world. Can be used by those devices. Now of course there is some trade offs there for device manufactures. Encryption is going to require more compute, more power, and in the world of constrained devices, that may be a challenge we are, we are not saying a must in IETF draft terms, we are saying it should.
So that will obviously prevent snooping, etc, on the traffic there. But yeah, we acknowledge the trade offs.
The other thing that can be done is put PKI around DNS, I expect r heckles or questions around DNSSEC later of course, we have got that in the draft. Many manufactures can sign the zones, of course, and that would be clearly be a security improvement. The IoT devices can check the DNS AD bit to check that query has been verified; it implies implicit trust in the resolver. We have allowed in the draft for the device to do its own validation, that's out of completeness and based on feedback we have got really rather than a kind of expectation that that will be done by devices but it is an option.
The other things that manufactures can do, apart from sign their zones is actually publish what management zones they use, things that are used for device control configuration, data collection. Network operators of certain types of network way want to constrain those networks, where they are so dedicated to IoT devices to only query those domain names. There may be environments such as a hospital running dedicated networks to IOT devices, obviously different to a large service provider servicing home networks where things would be open.
And the sort of response policy zone type approach could be used to help secure networks, other network security is available of course, and that would be useful from a sort of digital forensic response point of view as well.
There is one thing based on the feedback around content delivery networks there. These management zones might reference that, that might be a complication.
So how can you help us. That's really what I'm here to ask today. We definitely welcome comments, support via the IETF IoT ops email list. I am happy to discuss that in person as well.
Certainly advice and thoughts on mitigations with references to real world issues that you have seen in your negotiations, whether you can share those sort of publicly or privately, anything that might inform our draft going forward would be good there.
Also if there's anyone in the manufacturing area, we definitely love to speak to you about the implications of this draft, how it would improve your device security, could you even use it as a stamp to say our swan Alexa kettle is better than your swan Alexa kettle. Seriously, I would love to speak to you if you are manufactures and with that, that's what I had.
So thank you very much for listening and I would welcome any questions.
PETER STEINHAUSER: Thank you so much, Jim.
(APPLAUSE.)
OK, Jim you are getting a question from Jim.
JIM REID: There aren't enough Jims at the meeting. Jim Reid, no affiliation. Interesting talk, Jim. I am concerned about what one of these aspects you mentioned in passing about DNSSEC. I think it's a bigger problem with IoT devices, not just DNSSEC, in terms of the power they have both in terms of compute capability and energy consumption, so I wonder how realistic it is to expect IoT manufactures to offer DNSSEC support so we can validate answers and also consider using encrypted DNS transports an as a way to solve security concerns around the use of DNS with IoT devices. How realistic is it to expect these things to be found in a central network in your house?
JIM MOZLEY: I think that's something we'd like to speak to manufactures about; it depends on the type of device, whether it's permanently plugged in, what its processing capability is and the power that's available. At its simplest, these devices can check the answer has been validated by a resolver they trust, that would be one way in which DNSSEC could be used without really impacting on the device itself. That doesn't cover the encrypted transport, and there I suspect it's going to be whether the manufacturer is designing their device to be used on the network where it is, for instance, more open, more susceptible to snooping or whether it's going to be something in the more OT realm that's typically deployed on a network that's closed or maybe they are even using COPE or something like that. So yes, there are definite trade offs there.
JIM REID: Unquestionably and I think the difficulty is trying to find out from the vendor where they see the boundaries existing.
JIM MOZLEY: I think the important point here is set the bar to deal with these risks and mitigate them. If you set the bar to a certain level and people have let's say conscious and considered reasons not to conform to that, then at least we know what those are. Whereas if we try go to the lowest possible common denominator, we don't shift the bar very high.
JIM REID: Yeah, I was thinking, when in a domestic setting, if you are relying say for example on having a full service validating resolver somewhere in the house, that may also be an unrealistic expectation, you might find the CPE of the device is providing you with your internet connectivity. ..it's quad 1 or something like that and there's nothing on the device doing the DNS validation.
JIM MOZLEY: It might be DNS masking, or it might be configured to do that. Again, route capability, but really what we do in here is providing something that could be, could pull in quite a lot of situations I suppose. So in some deployments, all of the comments will be valid; in some, it will be less so.
JIM REID: Thanks. Cheers.
SPEAKER: Hi Jim, good talk, thank you, great tools. How realistic do you think any of this stuff is going to be? If there's a company, Hoover, whoever churning out a million toasters, they have got to get a chip set from somewhere, they have got to buy in the capability, are they going to pass the cost on and to the, I just don't know what the economics of the whole thing are going to be, if you look at CPEs in homes, they have been a perennial problem for using ancient chip sets and not ‑‑ they don't support any of the modern stuff we would all assume they would and they are not going to get updated, why so would IoT devices?
JIM MOZLEY: There's going to be a long tail of these things getting updated, video cameras are streaming encrypted pictures, encrypting DNS packet to send over DOH maybe, a fraction of what it's actually doing so again I think it's about raising that bar and then organisations that are perhaps moving towards certification sort of incorporated in these, the likes of ETSI or whatever.
SPEAKER: I guess if you don't try, nothing will happen.
JIM MOZLEY: The do nothing argument isn't useful from a security perspective so yeah. Raise the bar and see who can meet it.
SPEAKER: Thank you.
JIM MOZLEY: Thank you.
SPEAKER: Alistair Woodman, in particular case probably speaking on somebody who has worked with a CRA stuff at the moment so I don't know if he mentioned Ed C just, Ed C and Sen Sen in a have got the responsibility setting standards inside the CRA relayed to devices that need, that are going to get posed on the European markets, these devices are such things, the right way to go deal with this is to get standard flowing flew them as European entities so we can take this off‑line, that there is a legal mechanism where you can get this inserted relatively quickly into new products.
JIM MOZLEY: That would be great, multiple regulator authorities could insert it.
SPEAKER: Right, I will find you afterwards and we can talk about the politics of how you might achieve that goal.
JIM MOZLEY: A layer 8 problem. Thank you.
PETER STEINHAUSER: All right. Then thank you so much, Jim.
(APPLAUSE.)
ANNA MARIA MANDALORI: Thank you again, Jim. And now let's go on with the next speaker, Robert Thomas from the Global Cyber Alliance, he's the head of engineering there, and he will talk about how to built an IoT honey pot.
PETER THOMASSEN: OK. All right, yes, I am Robert Thomas, head of engineering at the Global Cyber Alliance, you may know as as secretariat MANRS, this talk covers the architectural challenges we face building honey pot proxy pot over the last seven years, context on proxy pot capabilities sports on real devices... and serving protocol emulations along with full packet captures. This is my first time presenting at RIPE, second time attending. So thank you for having me. If it goes badly, you can find and blame my colleagues.
OK, so proxy pot aims to... supporting eight of the most targeting protocols and 15 if you include variations such as HTTPS and FTPS. If you look at the hit count which is maybe, it is up there, look at that, so in our global cluster, we typically see the majority of hits over Telnet and SSH, they swap places pretty frequently, in March 2026 we received 17 million hits and for SSH, 12 million. The count is actually likely higher than that, we are currently experimenting with down sampling to handle the data we receive.
Getting back to the protocols themselves, Telnet is still everywhere on embedded and latency devices as you are probably aware given you are here, particularly IoT devices, given its flexibility and simplicity as a protocol, SSH... you have been inundated with failed log in attempts, FTP still active across the web, despite people thinking otherwise and simple and DNS both frequently exploited for command I can control, amplification of and da at that exfiltration.
It's actually protocol specific behaviour, each protocol attracts a different attack of goals, right? An SSH attacks... and happens to to reboot what they are doing, SMTP attackers typically one and open relay for phishing and spam campaigns and DNS attackers, want an open resolver for data exfiltration. A single protocol deployment which a lot of honey pots typically cover, don't provide a, sorry, they don't just give a partial picture, they give a biassed picture, they typically over represent noisy unsophisticated actors who are most likely just basic scripts and so not the most meaningful attack traffic.
And it doesn't adequately represent IoT threat landscape.
Realism, it's non‑negotiable for honey pots. When an attacker probes a device before committing, obviously they are specifically looking out for a low fidelity response, things like usually restrictive algorithm availability in the SSH negotiation, or things like Sen to say commonments in an otherwise Debian environment and of course if a honey pot fails the sniff test, we only capture surface level data, we miss out on the meaningful things like file drops from malware, and commander control call backs and lateral pivots. Protocol negotiation response time must be correct. But thankfully that's the easy part really.
So let's touch on how ProxyPot started as many projects do, it started with a narrow scope, it was intended to be a passive proxy in front of real devices, capturing traffic and observing without any emulation and if you are familiar with software project, scoping grew with time to include full decrypted packet captures, widening protocol supporton top of the already existed Telnet SSH, and of course each protocol that was implemented adds a session model complexity and new attacker patterns for us to consider.
And then 2022 happened, which was a first large scale deployment.
Let's go to the next line. Reality hit. Yes. So this specific deployment had many infrastructural limitations, placed upon it due to the sponsor party strict requirements, for example it required a site to site VPN tunnel which was a pain to say the least. But they provided us with 15 IP dresses, more importantly 116 IoT devices. Things like Smart TVs and door bells. And I don't need to tell everyone in an IoT working group what the devices are. It cracked up the pressure, we severely underestimated the type and amount of traffic we would receive. We had done lab tests prior to deployment and we had a third‑party operated carry cluster, carry being an OpenSource honey pot. But even with all the context and informs we had there, we were a little under prepared.
So ProxyPot struggled under the immense load to the point of crashing and in our deployment a single node meant a single point of failure, so any crash took everything offline, which meant we had gaps in our data and not a great thing when you really care about the data, additionally, we had no path to scale, if we needed to increase capacity, it was difficult because it's not the way we built the technology. There was no co‑ordination between the nodes, it was completely manual and any failure required an operator to fix it, which is often me at 4am.
Yeah. So we also had a completely lack of control over session state, we couldn't reproduce an attackers exact environment, obviously with a real IoT device you wouldn't have that anyway but specifically for data analysis, it's great to be able to recreate the exact environment to understand perhaps what they are targeting and trying to achieve.
So this thought us a lot about the page points in our previously knowledge and it guided to us to a complete ground up rewrite, which I know is every software engineer's favourite thing.
So, jumping forward to 2024, onwards, so we inevitably rewrote our entire C plus plus scope text in Go, for consistency with other projects that we operate. But also to allow us rapid interative development. As a fun fact, I mentioned this is my second RIPE, I actually implemented DNS support in ProxyPot between presentations at RIPE 91.
So it's very quick and easy ‑‑ reasonably quick and easy for us to enhance the existing capabilities.
So, as of 2024, we have 200 plus globally distributed sensors supporting both IPv4 and IPv6, our previous technology only supported IPv4 or IPv6 through proxying, this replaced our third party carrier deployment that was operated by third party, which provided us with completely control and operational flexibility. So the threat landscape is ever evolving and it's important for us to be able to react to those changes, if there's a new type of attack, that we are seeing we need to, it perhaps exposes gaps, we need to be able to react to that quickly without having to rely on potential configuration changes in calorie at the time which obviously wasn't quite as flexible.
We also automated sense of provisioning and considered ephemerality, we treat senses as crops, not house plants. I appreciate you typically harvest crops, but just work with me here for this metaphor. So the way we intended it to, it doesn't matter if a census dies, it should be ephemeral, it should start fresh, it shouldn't require manual ops. We do not have an ops team to manage that otherwise.
And then directly off of that point of course observability is critical as well, right. If things are failing ‑‑ well, we expect nodes to fail to some extent, if they are failing reliably, and consistently, that exposes an issue, something we clearly need to fix, so observability and traceability is absolutely critical for us so we have that insight and we can react.
And similarly to that, our data pipeline must also tolerate dropped delay and duplicate submissions without losing fidelity. So most honey pots don't generally consider packet captures as a critical or necessity. We strongly disagree given the kinds of attacks we often see in our cluster.
Now, the problem is while it worked very well in local tests, and sensing a pattern here, once we deployed at scale, we started receiving hundreds or thousands of requests a second, we found we were only capturing less than 20% of the attacks.
And the reason this ended up being that basically we were opening a Linux kernel capture handle for each individual attack and you basically we were exhausting our file script budget, now of course we could increase that but this felt like a better opportunity for us to improve technology because again we wanted to treat census as em em ral and we have to make changes to census to accommodate sudden bursts in traffic and it's not so good.
So our solution for this was to basically build a packet routing engine, now we are ProxyPot starts up it opens a single capture handle, no longer exhausting our budget and then internally we have a packet matching engine that basically when an attack opens, we create a matching rule and packets get routed directly to that session capture. With this we improve our capture success rate to 99.7%, the remaining one percent is being one of pings or packets, the way the capture starts, a packet comes in, we open the session and there are no more packets and nothing to capture, we could fix that with a packet buffer but don't feel it's meaningful data for us to capture.
As part of the rewrite, we also noted, a few instances we weren't correctly setting DSB headers for packet decryption, this will fix that.
Then we get to another hard truth, emulation is really bloody hard. So we modelled the majority of our emulations around a typical Linux system. I mentioned that we supported SSH Telnet andHHB and all that stuff, some protocols are easier, DNS, even HTTP to some extent, they are pretty eeasy protocols to fake and capture that traffic, but a shell is actually very complicated and it's something we were perhaps naive about initially, I mean me, I was naive. We were initially doing simple command matching so when an attacker runs free or something like that, we know what it should roughly look like and we also need to do arguments and flags and environment variables and there's also sub shells and process substitution and it goes on and on. It's really, really complicated.
And so after building this for a few years as a subset of a functionality of ProxyPot, we said hey, maybe there isn't viable long‑term and also remember that attackers are targeting a range of embedded devices, right, so commands don't always function the same across every system, particularly for embedded devices which are typically running, utilising busy bots or something like that. For every command we implemented, we had to have a variation support so that it was believable and not like the honey pot.
So what comes after emulation, the obvious answer would be a real system. And obviously this is something we considered initially but the concern there being resource overhead, right.
Spinning up a number of sessions in purely in code is lightweight, thousands of requests a second where we we require isolated embrace per connection is really lightweight, whereas if we had a real operating system behind them like container or KVM ‑‑ it would be significantly heavier ‑‑ we are exploring different options here, we have had really, really great results with hard and container run times but I would definitely be open, be interested if anybody has any other suggestions.
Operational reality, so running a global honey pot is really all the hard parts of distributed systems but the traffic is always hostile, right, you are not just expecting some traffic to be host file, it's all of it. And you can't utilise many common guards like rate limiting because that traffic is really important still, there's no such thing as just noise, all that data is meaningful in some capacity.
Node failure, not if but when. Nodes will fail and it's something we have had to learn from going back to crops, they should grow automatically.
Observability, so we distributed tracing and protocol level logging is as critical as the capture pot plan itself, right, it's all well and good to have log in to see a session started here and ended here and a problem occurred at this time but if we can't see into the what the protocol is doing, we are probably going to miss the point so every new protocol adds a whole new layer of traceability that we had to consider.
There's a lot of data and session span, behavioural clustering is expected to...... each new protocol adds completely new failure modes, educators and observability apps, protocol produced fundamentally different session data, right. What does an SSH session look like compared to an FTP or session? Or an HTTP session? Where do we draw the line of a session? With persistent protocols there's a time out of after five minutes and the client gets disconnected and there's a boundary, with number system protocols, it gets trickier because where does the session end and stop.
But also the data just looks very different, right, so it's difficult to find or so implement a Schema that we can stuff the data in for for every protocol and sometimes the protocol introduce completely new data that doesn't fit anything so analysis becomes tricky. Then the IoT attack surface is uniquely device, an industrial sensor all differently attackers know that. It's important we match those from a fidelity standpoint. The last slide, seven years of lessons, what the last seven years taught us, multi‑protocol support is essential loo to adequately capture the breadth of the IoT threat landscape, resources must be carefully monitored and again pulling back to crops an ephemeral, it's important to avoid outages that affect everything, emulation is really, really hard, automation and ephemeral is not optional. Manual operations don't work so we can't afford to spend time there. And observability is critical, distributed debugging without tooling is just guess why, why did this fail, I don't know, maybe it was X, Y and Z, no we need to know exactly why it failed and that's everything, that's the end of my slides.
(APPLAUSE.)
PETER STEINHAUSER: Thank you.
SPEAKER: Thank you, this was a great presentation, things like SSH and Telnet and FTP, do you allow any user name or lock it down?
PETER THOMASSEN: Yes, we learned from... there for sure, we have, we experiment definitely and look at the data we see. But no, we don't allow anything, the minimum requirement is usually route and something, we actually have experiments as well with having ‑‑ if the same attacker comes back, it will only allow the exact password last time, it has had some good success.
SPEAKER: I remember years ago when people tried to build protocol emulators and as test tools and they quickly discovered that once you had written the protocol emulator, you had effectively written an implementation of the protocol, that was more valuable. What you have doing here is incredibly ambitious, you could probably right now produce toasters, DDRs, you know, the hot pot you just ‑‑ so have you considered, so the other thing is I know they are not updated very often but in theory, the software on these things could get updated, they could fix problems, and there's no way you can keep up with that. Have you considered maybe changing your whole model and offering a service to these device manufactures where they give you a device with some instrumentation and so what if you drop 90% of the traffic if you are able to get a full session showing the exploit because presumably these exploits jump from chain problems with one protocol with another, so it's not just all a Telnet thing, had it's a Telnet and FTP so it seems like emulation this just seems incredibly ambitious and it just seems like it would be easier if you had like walls and walls of devices with some instrumentation to capture and maybe you could market that to the device manufactures or require like when you go to get your UL listing, you have to send to device, something like that. I am just, obviously it's easy to critisize, it's a very impressive effort. But it just is amazing that you are trying to emulate all these things.
PETER THOMASSEN: Thank you very much. An excellent question. Yeah, no, it was certainly an ambitious undertaking over the seven years we have worked on it, some of the protocols are significantly easier at the least and you are absolutely right, at that point it's not really emulation, it really is just implementation of the protocol. I think for when we say SSH and Telnet, we are more referring to the shell environment, right. Obviously the protocol is one thing, that is pretty straight forward at least for us, but emulating the shell is the really complicated part. But it's an interesting question. I don't think we have considered it, we are a non‑profit, I looked to my CTO just in front of you there for her reaction to your question. So yeah, thank you.
SPEAKER: We have the problem in the different side, we have to the problem with IoT devices the customer designed and sending out a lot of traffic we do not want to handle, that's why we decided to route our private IP space to a honey pot for all the customers and try to respond to the IoT devices in a manner so that they become quiet and stop working or stop becoming route. We should have a coffee together. Thank you very much.
PETER THOMASSEN: I would love to have a coffee with you. Thank you.
SPEAKER: Hi, Lucas from... and we are running a couple of honey pots inside of our university network to like detect attackers inside our network. And I was wondering whether it was possible to run an instance of ProxyPot inside like internal networks and if you have considered that.
PETER THOMASSEN: It's a question we have been asked over the years. So I think I may have removed it from the slides in the end. ProxyPot is intentionally closed source for obvious reasons, right, because looking at calorie, attackers know what to expect and footprint for, whether we can operate in more infrastructure, definitely but I think again look to my CTO behind you, we can definitely have a conversation about it, for sure.
SPEAKER: Thank you.
PETER STEINHAUSER: So I think we have a remote question, I hand over to Anna,
ANNA MARIA MANDALORI: We have a question from Michael Richardson, do your SSH honey pots announce they do password log ins? Notice that most of..when turned off. So should a honey pot be realistic for a high value forget and hand it off or should it guess guess in order to...
PETER THOMASSEN: Terrific question. We actually accept ‑‑ I mentioned we run a few different experiments in our global cluster, so we accept pre‑defined configureable credentials, we also accept SSH keys as well and store the keys that are sent. We have done explorations with completely open emulations so no authentication required and we found the data to be less interesting to see to say but it is interesting to operate both side by side authentication lists in a smaller capacity.
PETER STEINHAUSER: One more question and after that we are closing the mics.
SPEAKER: The aforementioned CTO that Rob has brought up, just so that people see me, I want to draw a distinction that Rob is talking in large part about the ProxyPot technology and the deployment he is describing mostly is as a generic global honey farm, keep in your minds the distention between trying to collect generic attack traffic such as the kinds of things you see out of rest proxies versus setting up particular deception against individual characteristics in IoT devices, which is also possible.
PETER STEINHAUSER: Thank you for the clarification. All right.
Thanks a lot, Robert, great talk. Thank you.
(APPLAUSE.)
ANNA MARIA MANDALARI: Our a next speaker is Francois deKeersmaeker. He is an expert on characterising smart home IoT communication. Francois.
FRANCOIS DE KEERSMAEKER: OK, so hello everybody. Yeah, I am Francois and I am ‑‑ just finished my PhD like three weeks ago, the topic of my research...
(APPLAUSE.)
I forgot to state PhD on the slides but yeah.
So the topic of my research was about smart home networks communications, and I characterised their communications and developed a security system. So let's jump right to it.
So this is a smart home environment, I guess you are quite familiar with it. It's composed of domestic devices, such as the one circled here including smart plugs, smart lamps, etc and the added value from typical like default home environment is that you have IoT concepts that are applied to it, the two main ones are that they have sensors equipped, which manage, which allows them to sense their environments and their internal operation and an example is for smart plugs to measure their energy consumption and then the most important for us here is the communication part, which allows them to communicate with remote machines and to be controlled remotely for example from smart phones.
Now those environments are becoming very popular; for example, in the US alone you have 7 million households which are equipped with at least one of those devices. And the fact that there is such big change means the security is very critical and security is let's say a global concern but which can be precise in practice, at least two practical concerns, the first one being the safety because since this is an environment close to the users and to its personal belongs, like if there is a failure a burglar might be about to come inside and then there's always the privacy concerns because this kind of devices have access to your personal information and you do not want them to leak. So we have been working on that and more precisely we have r focused on a specific subset of smart home devices, which we call the purpose‑driven devices, which are the ones having few identifiable functions, such as the ones depicted here, for example again for smart plug, you can turn it on and off, for a smart lamp you can do that and maybe make change the colour and brightness but not much more and this kind of devices have abounded behaviour which means that you can analyse them nearly exhaustively and this is also translated to the network traffic they issue. On the other hand you have the devices that have unbounded capabilities, which we call the hub‑like devices which include the speaker hubs such as Alexa and the smart televisions and those in general can be extended thanks to third party apps and integrations which means their behaviour is quite complicated to accurately describe, lets say. We'll focus on the first category and since they have bounded behaviour, we can apply security in a quite precise way. But by utilising busy bots profiles, so I would explain that, let's say that you are in a local network and you have a, you want to run a security system on the access points connected to the device, you can configure this with a profile that will characterise the traffic that is issued by the smart plug. Here we have one traffic like we count as one pattern of traffic, in practice we characterise it with the host, the port, etc. Typical network attributes.
And then we can configure a small ‑ only the traffic that is specified in this profile, it's basically a hello list security
In the case of the smart plug, if it issues the traffic complying with the profile, it will be accepted, but if we have a profile for a smart lamp with two other traffic patterns, if the smart lamp issues a pattern that does not comply with the profile, then it will be rejected by the security system.
So, we have three steps in this workflow. Basically, the first one is to have a format for this kind of profile. Then how to in practice translate those into a r practical firewall. And finally, once we have that, we want to know if it's possible to automatically generate these kind of profiles so let's hop in the first one.
There is actually already a stand out that existed for that by the IETF which is called MUD, so it's a good first step in that direction, and basically it has basic capabilities so it supports traffic features at the layers three and four, like IP addresses, host names and port numbers, etc.
Now, a point is ‑‑ it's quite limited as is because for multiple reasons, firstly it does not support higher layer protocols, for example, even an encrypted one such as an encrypted DNS or HTTP which are still widely used in IoT, that's a shame but it is like that.
Then you have no support for traffic statistic like the duration of a traffic pattern, the number of packets, the packet rate, etc. And most importantly for the reality of today's smart home networks, this cannot support interactions between devices, which I will explain in more detail. So let's take the example of typical smart home deployment that you have configured for turning on a smart lamp when a motion sensor detects that you enter your home. In practice, this scenario will be translated into two sub sequent patternes, the first one when the motion r sensor detects the motion, it will issue the pattern to the configuring cloud that motion was deteched and then the cloud will process it and issue the second pattern which will in practice turn on the lamp, not the plug.
And so basically you have two sub sequence patterns and if you want to allow boast of them with the match tendered, you have a profile which will contain both of them but individually, you cannot state that one should occur after the other.
OK. And so that's something that we want to address because there are some cases where the patterns might occur if you do not want them. For example, if there is a rogue device in your network. This device might want, might try to turn off the lamp with a spurious command and this pattern is actually equivalent to the pattern B that turns on the lamp. So in that case, it happens without pattern A occurring beforehand, and that is something that you my not want, but it's something that you cannot express in the MUD standard, that's why we have developed al new standard based, inspired by MUD but with an enhanced syntax that takes the existing features of MUD that will enhance it first with new application layer protocols, why not and then we have more expressiveness, we also added traffic statistics. And as I stated, the more important part is the support for interactions between, devices so subsequent traffic patterns, and in practice, how can we do that. Well, inside a profile we can have references towards other fields. For example, in the case of yeah, two patterns from the same devices that should occur one after the over, we can draw reference to that. But the most important and the one that I presented is the example is to have a profile for the motion sensor for the lamp that will reference the pattern in the profile for the motion sensor and this allows us to state that pattern A should occur before pattern B and that pattern B should be blocked if pattern A did not occur. So that is for the profile, now we will see how we translated into into a practical firewall and we used the default Linux based firewall NFTables which is the new generation of IP tables basically, so I will explain in practice how it works.
We implemented that on open... and this one being the Linux is split in the kernel space and user space. When packets arrive, they go through the network stack and inside the network stack, you have what are called hooks, so they are basically call‑back functions that will do something when the packet arrives and to this hook register are NFTables firewall that will be a first line accenting or dropping packets based on the routes. The point is the actual capabilities of NFTables are basically the ones of plain MUD, so it's not enough for us, but it's like still like a first line ‑‑ if we only need basic matching, we can use it, but in most of the case, we will need additional matching and that's where we leverage library of NFTables which is called F FQand basically this is a user space programme that we can send the packets through for further processing and basically this allows us to do further matching implementing all the additional stuff that we brought compared to plain MUD, including the interaction between devices that are basically implemented as finite
State machines so note that's how it works but since I am doing research, I have to evaluate that and so we deployed a real test bed network with off‑the‑shelf devices that you can get from retailers that are widely used. And the most important stuff that we want to measure is the delay that is incurred by the firewall, because if it were expert, it incurs significant delay, it's really annoying to use, even more for users that are not tech savvy, it will be annoying for them so we measured the delay that the firewall incurred compared to the base case without firewall and those are the results so we see that yes, basically the line contains 95% of all data points and you see that we evaluated that when the firewall is active for only one of our devices and then for six of our devices. And we see that compared to the base case, the delay increases, of course because we add more processing.
Now, I want you to look at the scale and here we are way under the milliseconds and this is actually not perceivable by a user and yes, we are in a smart home setting here, so we do not really care about high speeds network network traffic basically and the only thing we want is that the user do not notice that we add delay and in this case, it's impossible for a human person to notice that because it's way under the milliseconds bar so even if we add more delay because of more processing, it's still impeer receivable by the user, we take that as a win and then since it's supposed to be a secure system, we also Val waited the fact that when there are packets that should not be accepted, so let's say attacks that we simulated, we also measured at and this is on the upcoming ref and here we see there's no difference between the case without any attacks and the case with simulated attacks so it means that even if the firewall has to drop substantial amount of packets, this has no effect on the legitimate packets, they will still pass with comparable latency so it means that it works as a security system.
Yes, that's for the evaluation, I will move to the third step which is the automatic generation of such profiles and I will take an example of a smart home network.
In such a network you can control your smart lamp with an app running on your phone an let's say the typical network patterns looks like that, it stays in the LAN, which is good, but what if it does not work. What if for some reason this pattern with not succeed. There might be other patterns, for example, one going through the cloud which is more convoluted you, but it manages to still succeed the action here turning on the lamp, even in the case of network patterns not succeed, so that's a good point. And we want to actually extract all of those patterns because existing works in general were quite superficial and only focused on the patterns visible by default but did not try to go deeply and that was actually our objective to being able to extract automatically also patterns that you do not see all the time.
And for that we developed a complete framework I will present step by step. So we automated the interactions between the app on the phone and a smart device by using a DB, a tool to script and write phones basically, this will produce packets that will go through the network access points, yes. And basically we do that multiple times. We do that 20 times, around 20 times, to have meaningful corpus of data, OK.
Once we have the packets for all 20 event executions, we check if the event was actually successful. And for that basically we check with an API for the device, if the state of the device was correctly changed for a smart plug, it would be did it correctly turn from off to on or the converse. If the event was not successful, it means that we can stop our framework because we reached a point when yeah, the event cannot succeed any more. But if it was successful, we continue processing and we have a list of basically 20 PCAPs for 20 situations. And then we run that through the extraction of the network signature which basically takes the intersection of networks flows to extract only the ones that are really linked to the execution of the event because you can have some traffic that occurs from time to time but not all the time, and it means that it's probably not required for the event to succeed.
From this we will extract the flows and here we take concept of flow which is actually enhanced compared to typical network fivable flows because we add also application layer information, if it's available, to have yeah more expressiveness basically.
And then we will do that interactively and we will store the results in a tree structure and basically so we will add the current flows as children of the current node in the tree and why are we using a tree? It's because since we want to detact a new flows, we will process it in a way that we will take the flows that we have up served since then and configure the firewall which is actually modified version of the one I presented before but instead of being an... list was it's a block list one, deny list one, such that we will see if new network pattern will occur when we block some of those.
And so this is a loop, we do that in a loop, until new no network patterns are detected or the event does not succeed any more. At the end we end up with a profile for the whole communication of the device, including patterns that will not occur by default. And yeah, so again, we have to evaluate that and so we deployed a similar test bench as for the first, for the previous valuation but there are some divergencies in devices but basically it's the same idea. And the most important stuff that we want to analyse and evaluate is do we actually discover more patterns than existing because that's the main part of our work, we compared with existing work and we are the hat to bar basically, here with compare with one work that's characterised devices at the device level so the device as a whole, and we see that in two cases we discover way more patterns than them and in one case we discovered the same patterns, so in general we are more thorough than them. And we compared to other works that do the same but at the events level, more fine grains, and we are again, the hatch to bars, and we see that again we discover in this case way more patterns than existing work, which means that our objective of being more thorough is met.
And finally I want to give another insight about our work, is the fact that we want to assess how does hidden patterns to so the ones that occur only after blocking some other ones are a good measure of the devices robustness, and so we will measure the number of hidden patterns that occur in a tree like that and basically those are the ones ‑‑ all the ones that occur in the tree are the depth of two or deeper and it means that yeah, those are the ones that appear only upon the blocking some traffic beforehand.
And we measure that and so we measured all flows that occurred but with a focus on the ones that are hidden, and here is the corpus for all events that we surveyed and we see that ‑‑ so the grey bar on top of the black bars are the flows that were hidden. And we see that for most devices, we have at least one hidden flows that occur, it's already good and for some of them we have even more than one hidden flow that occurs which is a good point, it's motivating because it means that there are quite a lot of devices that actually take that into account, that provide flows that provides back up flows to make up for when there are network outages etc, so that manufactures made sure that the events can still succeed even when, yes, the network conditions are not the best.
So this is something that is quite interesting and it's something that's in the more regulatory point of view, it's quite interesting and it will be a good idea to have this kind of measure as written inside the smart home devices manuals to state, OK, we have tested our devices in multiple conditions and we have kind of a robustness course that states that yeah, our devices can work in, even in inhospitable network conditions and this is a discussion that we push a bit further in our papers, I can give you the links if you are interested, but I think it's already time to conclude.
So as a summary, during my research, I have worked on different steps to add situations to smart home networks and analyse them in‑depth, starting from a format to express the network patterns allowed for network communication of smart home devices, then developed a practical firewall solution based on those and then we worked on how to automatically generate this kind of profiles by going more in‑depth than existing work to, yeah, extract more traffic that does not appear by default; and all of that with the same goal of enhancing the security of smart home networks with profile‑based approach.
So yeah, that's the end of my talk. Thank you very much for listening.
(APPLAUSE.)
PETER STEINHAUSER: Thank you Francois, mics are open for questions.
SPEAKER: Yes, thank you for that amazing talk. Lucas again from Dusseldorf. I was wondering whether you thought about like publishing the firewall routes you obtained by this procedure and making them available for users to like actually use them in their homes? I have seen you have been using like Open WRT and OpenSource router firmware stuff and maybe there's a way to continue with this...
FRANCOIS DE KEERSMAEKER: Yes, so everything is OpenSource which is a requirement in our university. I don't know if it's the same in all universities, but I think should be maybe. So yeah, everything is OpenSource, come see me I will give you the links. But basically you can find ‑‑ my Github profile is basically, so on screen, F and my last name, that's my Github profiles. And everything that's research related is in an Github organisations which is smart home network security. But come to me, I will give you the links directly.
SPEAKER: One step could be to provide an online database to easily search for your device and see if there's a firewall profile available.
FRANCOIS DE KEERSMAEKER: Yes, there are some databases like that for MUD profiles. I have taken that as a base for our own research. You know the point is that including interactions makes the profiles quite ad hoc for a specific smart home deployment, so that's one of the questions and and our research question that is still ongoing, is it possible to still automatically generate including interactions of these kinds. There are works that have been doing that but they are tied to to a specific deployment.
SPEAKER: Last remark, I wanted to ask whether you know about OpenSource project like the PQ M... that tried to get rid of commercial bridges and replace them with OpenSource equivalents which makes them probably more controllable and deterministic in terms of network flows?
FRANCOIS DE KEERSMAEKER: For a smart home, you have Home Assistance and Open Hub, basically you have that and they tend to stay local only if possible but there are some vendors like Tua, which is a very popular IoT smart home platform. But they are ‑‑ nearly all r communication goes through the cloud, so you are a bit limited in that, Home Assistance is very good, very cool, I think the best one.
SPEAKER: Thank you.
SPEAKER: Greg Choules, ISC. Have you considered commercially available maybe closed source like for example locks on and other closed systems? I know they are maybe not directly monitorable, but there will be some network communication at some point.
FRANCOIS DE KEERSMAEKER: You mean for my tool to distribute it commercially?
SPEAKER: No, I meant for the, whether you have detected communication in your, on such closed systems and maybe contacted the manufactures themselves and said hey guys, you know, we see all this stuff leaking out and it probably shouldn't.
FRANCOIS DE KEERSMAEKER: OK, that's not really the scope of our work. Because in our case the point was to, yeah, basically analyse the communication on flow level basically and then design a security system, but there are a ton of work that do that, about information, leaking information, outdated protocols, etc, so I have not done that, but there are a lot of researchers that do that. And I think that's ‑‑ Anna might know a lot of them, so you cannot go to her to ask for publications about that.
SPEAKER: Thank you.
SPEAKER: ... I have a question about some IoT devices are more dynamic than others, the profiles might change over the lifetime of the device, especially in the ephemeral update. Have you faced the problem of keeping the firewall in sync with the profile and do manufactures have to update their profiles in order to pass through the firewall?
'
FRANCOIS DE KEERSMAEKER: I have actually stumbled upon this problem and I had to manually change the firewall configuration so the profiles ‑‑ no, in the best of words, this should be automated too, like there should be like regular periodic audit of the devices communications and then automatic updates of the profiles such that they account for firmware updates and a new traffic patterns so yes, of course this happens. Yes. This happens. Yes.
SPEAKER: Thank you.
PETER STEINHAUSER: Thank you so much for the questions, maybe a quick remark. The profiles you are creating are really related to the individual set up, it's not like a general device profile that can be distributed to any place, so this is the major difference.
FRANCOIS DE KEERSMAEKER: Indeed that's the point but it comes to from the interactions themselves, because if you do not consider the interactions, you can have profiles for a device and those would be generic amongst all the devices of the same model but as soon as you introduce interactions, it becomes yet tied to a specific smart home deployment. Yes.
PETER STEINHAUSER: Perfect, thank you so much. Francois and congrats. (APPLAUSE.)
ANNA MARIA MANDALORI: OK. Thank you, such interesting talks.
Now, the last one is from Michael Richardson, that unfortunately is not here in person today, he will present remotely and if you can connected, here we are. Hi Michael.
MICHAEL RICHARDSON: Hello. Did I get identify control? Yes I did, thank you very much. Sorry I couldn't be there, it looks like fun. And a great talk so far, just an update on something that happened since last year on this forum, I talked about it last year and I am going to give you some updates and invite you to join us. OK. So what is it we are talk about it and tell you about progress and the stencils. And I hope that people have some feedback and I would love to hear more from you about that specifically.
So what is it? Last year we started, we, the IOT security foundation, started the device identity forum. And the inaugural meeting was last year during the RIPE meeting. And we have been meeting since. We are looking for a new co‑chair, if you might be interested, that would be great. Richard has moved on to another job. This is not just technical, this is some marketing and technical content. And we actually would love more marketing communications people involved at this point.
So what is it? The goal of this is to kind of come up with better models and advice on doing device identities. They are growing and ‑ but often unknown. And one of the things that many of us have lived through this kind of thing has been that it's hard to communicate no one uses the same terminology, people talk about what they are doing, there's either NDAs, you think oh well, that's OK, I have an NDA with my supplier, we talk to them, and that's great. But your customers don't have an NDA with your suppliers and so they can't ‑‑ you can't tell them what you are actually doing there and then add another two or three layers of integration, and you discover a lot of things, as some of the previous speakers, both speakers, talked about dealing with IoT devices which are not sourced, for instance, directly built by the developer or the manufacturer, but some are two layers down. So you want to know what some platform does, then you may be completely unable to do it and the manufacturer may be unable to tell you because they are NDA, this is part of the how do we know what's normal if no one will say what they are doing.
Finally, if people know more about what's going on, not only what's normal but realise, hey, maybe I am actually falling behind here and this is a thing that we need to do.
So what are we doing? We are going to put together ‑‑ we are putting out a number of different, call them white papers of success stories, the idea is to say hey what we are doing there, dealing with the NDA and this kind of stuff, you don't have to invent the hamburger yourself, we have a lot of different res piece for them. And you can probably go up and say I would like a hamburger without onions and you will probably get what you wanted, even though your particular, you know, recipe might be private to you but 97% is public, so that's something you can talk about. And among this thing is actually the visualisation of how do we do this, device identity, what do we call them, what images to we use and a lot of the stencils and images out there are in consistent, confusing and just outright wrong.
So we are looking at six documents that we are looking at, some of these slides are from the slide, deck five we actually go through every meeting very quickly to make sure that we haven't done something, and there's a GoogleDrive at present ‑‑ it may be in the cloud in the future ‑‑ where they keep the documents and you are welcome to join us for that.
Who should join us, I said that before. So many of the people in this room, you will all be in there and you are involved in this and you are making things and you are operating things. Very interested in that, chip vendors, certification authorities, but also I am interested in marketing, communications staff, operational staff, how do you communicate things, what are you going to do, how are you going to make them say I am part of the group that's actually doing something sensible, how are you communicating, internally, externally this kind of stuff. I have been in a bunch of start‑ups, we have spent way too much marketing money educating customers why technology is important and at the end of the day, our competitors come along and leverage all the work we did and it's always been kind of sad. But this is sad for us, great for them. We all have a kind of raise the converse a little bit.
So we meet typically on the first Tuesday of the month. Our next meeting is June 2nd I believe it is, the details are up there. And we, in fact, move our meeting ‑‑ I will talk about that a little bit there, to ‑‑ so what are the results and is stencils. And we had a number of conversations, a number of back and forths up and and down and we pursued a bunch of, I would guess we call them rat holes, places that's not really the way to go and things like that, and one of the conclusions was that we tried to get change ‑‑ change the description of, the visual descriptions of how people talk about devices and device, I am trying to avoid the word key, I want to say PKI, I would rather not use the word K in there because I think it's very confusing, some people agree and some people are a little bit more on the fence about that.
One of the things we did include was that we need the fundamental thing we want to talk about are not keys but signatures and that's really what we are interested in, in the end, what are what are we doing with these things and what are they doing, ,so a whole bunch of different notions of stencils and stamps and seals and connections to things like rings and seals and things like that going back both in western European history but also going back thousands of years in Asian and Chinese history and we had a conversation about which names could we adopt and are there cultural appropriation we need to worry about, and we haven't gotten through all of that process yet.
But one of the things that comes out of that, is that if you have the seal as the signature then you say what is it I am trying to ‑‑ how do I produce this? And the answer is, well, it's a stamp or a ring that produces it and suddenly that transforms at least for us, transforms ‑‑ well, actually the image for the private key now, you keep your stamp in a lock box or on your finger or on a necklace virtually there and you keep that private, you don't share it with other people and hoping that that may actually result in people understanding that difference between that. By never calling that secret part a key again, maybe we can avoid people actually thinking oh, I don't know what difference between a public and private key, I will send you everything because I don't want to have another interaction with this.
And a number of people who have sent me their private keys over the years who should have known better, it's really, it's outrageously crazy amount and I think some of it is just they couldn't tell the icons on their screen. How do we represent the public part, this is where we are still struggling a little bit, the best we have been able to do a magnifying glass that let's you view a signature, that's fundamentally what a public key is, it is again I have no better term for this at this point, it's a thing that let's you verify the signature, does it look right, it signed by the right thing, that's going on and some of the images you are seeing on the slide right now were actually put together by David has lamb from a variety of sources and that magnifying glass, that we have to get rid of that image obviously but re‑draw it, it's not an image we can intelligently use. We need these images to be distributable under creative comments, 4.0 r probably, and I have been seeking a graphic artist, if you have one or one internally you could donate, that would be really fabulous.
And in an age of little driven bots and image creation, I really want a person on this and I'm a little bit surprised that I am getting so few bites from the graphic artists that I have reached out to.
And it's not that people said oh just do that this way and I am like, well, it's not that I can't drive inkscape, I can do that just fine, but knowing exactly how rounded those corners need to be is not something I know or I think LLMs know anything about this. And whether I am infringing on someone's culture is also something that I don't necessarily have the skills to do. I don't think anyone else does and that's why we want someone really to be involved in this
And maybe you have some ideas that you want to share, maybe this is helpful for you, maybe this is completely unhelpful for you, but I am 40 years into asymmetric you know cryptography graphy, is it really time to change anything and I would say yeah, we had it wrong for so many years or confusing for so many years there. The bottom is some images of what you might see about a seal or something and we realised for instance and I am not showing the image I hate of a r diploma with the blue ribbon on it, it's the not the diploma that we hate or the seal, it's the blue ribbon that's wrong, we kind of stay away from that, get away from in an imagery and go on to something else.
I'd love to take questions about this now or later, because really I am pretty much done.
Next thing so how is it going? We get about ten people per meeting, new people joining and coming and going, they don't attend every single meeting, we are having a couple of arguments where people said I want to lead this and haven't followed through and I hope they come back and we have a kind of regular series of about 15 to 25 minute presentation in many of the meetings from people who are doing it, who are doing device identities, some are called..Cisco calls it psuedi and other people call it other things and CSA matter has it called ‑‑ I can't remember what the word was, it's another word. And so we are going to hear in June from secure I C who builds hard macro cores and provisions things into it there.
And it's now Tuesday morning's at the 10am eastern, 4pm Paris. We moved that to accommodate the California people or whatever. That's about it.
Any questions? Discussion? I would love to hear your feedback and I will go back to that slide if you like.
PETER STEINHAUSER: Thank you very much, Michael. Any questions to Michael from the audience? (APPLAUSE.)
OK, so apparently no questions yet, Michael, but I am quite sure some people will reach out to you, thank you so much.
MICHAEL RICHARDSON: That would be fantastic. And even if it's to tell me this is a really stupid thing and I hate you, I would love to hear that because then at least you are paying attention and have some opinions, so thanks.
PETER STEINHAUSER: All right, thank you so much, Michael.
ANNA MARIA MANDALORI: OK, thank you again, I would like to thank all the speakers, fantastic presentations today and thank you very much to all the participants for the great questions.
As you know, Peter's term as a co‑chair came to an end. And of course we would like to thank him for all the work that he was doing during the years. I am sure that you are share these thoughts.
(APPLAUSE.)
And we got a candidate as co‑chair of the working group Romana Marfievici; unfortunately due to last minute arrangements for this, she cannot be here. She had a clash organising another workshop. But I know her personally and so we got some support from the mailing list to support her as co‑chair and we also got support from the room. And Ramona worked in Digital Catapult, a non‑profit in the UK, it breaches academia with industry and she's in the field of IoT since or even before she started her PhD. Now she's working at principal IoT engineering at Digital Catapult, so she'll be an amazing addition to this group and I am sure she'll do amazing work.
Thank you again for this, for everything, and see you in the next meeting.
Thank you.
PETER STEINHAUSER: Thanks everybody.
Thank you.
ANNA MARIA MANDALORI: Before closing, I was reminded to remind you that the voting from RIPE NCC closes at 7 ‑‑ no, at 5:00 today, so please vote. Remember to also rate the talks. Thank you again.
(APPLAUSE.)
End of session.