Part of what we will now be doing is a scoping exercise. It will never be complete and it never has to be. Part of that exercise though can be dealt with top-down by looking at the items identified elsewhere and looking at whether we think they fall within our area of interest. Your presentation this morning on the ITU and on AIOTI can help there. As indeed can Jim’s post about the call for papers. These kinds of thing can give us a sort of taxonomy of issues within which we can pick and choose in setting the initial scope of the WG. But another part of the exercise can better be dealt with bottom-up, by helping us produce a “rich picture’ to help us test our proposed scope. I don’t think it useful to produce a list of all the bad things out there. That list would be never-ending! But identifying some real world items would definitely help. We had Mirai as one sort of starting point. That was a particular concern to people in this community as devices were being reprogrammed / repurposed to perform a dDoS attack. Whether Mirai was seen as a big problem for owners of those compromised devices is an interesting question. Indeed there were suggestions towards the idea that an access provider could make it their problem! Persirai is similar but different. It uses some of the Mirai code but it has not (yet) been involved in a dDoS. I might imagine that the owner of such a device having been told that it has been hijacked, and that we do not know why, may be more concerned. So are Mirai and Persirai both within scope or only Mirai? Or neither? If only Mirai then we may be sort of heading towards a partial wait-and-see by the access provider.Only when a dDoS is reported does the access provider look a out-going traffic, maybe do some analysis - DPI? - and then intervene. If both then are we looking at the access network equivalent of a spam / malware filter? Trying to block the compromise, independent of the purpose, in the first place? I hesitate to suggest here that an access provider should run one big firewall for all its users! As a sort of throwaway question I also mentioned Shodan. I don’t know about it. We had talked about tracking things on the home network in various ways. Is this part of the picture? I am of course aware of gaps and unanswered questions in the above. But that is where I think we are. Gordon —— https://twitter.com/internetofshit Blake @mullins Oh goody, a firmware update for my ceiling fan!
On 11 May 2017, at 14:58, Marco Hogewoning <marcoh@ripe.net> wrote:
Thank you Gordon,
May I again urge the participants to try and not only focus on the problems or particular incidents.
While of course these examples help and can be used to learn from, I would really like to focus on wha this community can contribute towards solutions. Of course there is still a pretty wide spectrum of options from education to some smart technical solutions that could recognise and filter bad traffic.
While I am pretty sure we can’t fix everything, I personally still believe there are things where we, the operational community, can add to solutions. But for that to occur we do need to look slightly beyond the problem itself.
- What are the common causes - What can be improved - Who can make these changes
We are certainly not unique in recognising there is a problem, but we some unique expertise and a very open model, which I think we could put to good use. But the message should be slightly more advanced than pointing out they are doing it all wrong…
MarcoH (no hats)