- iot-wg - mailman.ripe.net

Fwd: CRYPTO-GRAM, May 15, 2018
by Jim Reid 15 May '18

15 May '18

In case some of you don't read Cryptogram (why not?)... > Begin forwarded message: > > From: Bruce Schneier <schneier(a)schneier.com> > Subject: CRYPTO-GRAM, May 15, 2018 > Date: 15 May 2018 at 06:07:08 BST > To: jim(a)rfc1035.com > Cc: Crypto-Gram Mailing List <crypto-gram(a)lists.schneier.com> > > Researchers at Princeton University have released IoT Inspector, a tool that analyzes the security and privacy of IoT devices by examining the data they send across the Internet. They've already used the tool to study a bunch of different IoT devices. Their first two findings are "Many IoT devices lack basic encryption and authentication" and "User behavior can be inferred from encrypted IoT device traffic." No surprises there. > https://freedom-to-tinker.com/2018/04/23/announcing-iot-inspector-a-tool-to… <https://freedom-to-tinker.com/2018/04/23/announcing-iot-inspector-a-tool-to…> > https://iot-inspector.princeton.edu/ <https://iot-inspector.princeton.edu/> > https://boingboing.net/2018/04/23/promiscuous-mode.html <https://boingboing.net/2018/04/23/promiscuous-mode.html>

1 0

updated WG agenda for RIPE76
by Jim Reid 08 May '18

08 May '18

Colleagues, here's an updated agenda for next week. This should be the final version -- famous last words! -- but the running order may change, # # $Id: agenda,v 1.3 2018/05/08 08:56:19 jim Exp $ # 1) Administrivia 2) Report on NCC IoT Activities Marco Hogewoning, RIPE NCC 3) Privacy implications of sewage testing for illicit drugs Elif Sert, Istanbul Bilgi University In smart cities of the future, many IoT devices will be deployed to monitor community behaviour while being designed not to collect personal data in order to preserve individual privacy. This presentation will question this view by examining the phenomenon of sewage testing to monitor community use of illicit drugs in communities 4) RIOT: Networking from the friendly OS perspective Matthias Waehlisch, Freie Universitaet Berlin RIOT is the friendly operating system for the Internet of Things, targeting low-power IoT devices. In this presentation, we will report about the networking stack and deployment scenarios of this open source project. 5) SPIN - Security and Privacy for In-home networks Jelte Jansen, SIDN The SPIN project at SIDN Labs aims to explore - and prototype - methods so improve the security and privacy of home networks with regards to the IoT. Within SPIN, we research several topics, such as device traffic visualisation, automated recognition of (bad) patterns, device descriptions, and abuse handling. 6) Securing Internet of Things Devices: Closing the Gaps Hugo Vincent, ARM A lot has been published about the (in)security of Internet of Things (IoT) devices during the past few years. There is also no shortage of good ideas on how to secure IoT devices and the infrastructure. This presentation gives a brief overview of the comprehensive security approach developed by ARM to secure IoT devices and provides links to relevant software and hardware. 7) Role for the numbering and naming community in the IoT domain Sandoche Balakrichenan - AFNIC Both the numbering (RIRs such as RIPE) and naming communities (domain name registries such as Afnic) play an vital role in the current Internet infrastructure. This talk will focus on how the earlier mentioned communities will play the same vital role in the IoT domain. 8) AOB

1 0

draft agenda for Marseille
by Jim Reid 01 May '18

01 May '18

Colleagues, here’s the draft agenda for the WG meeting at RIPE76. Please note this is likely to change between now and then. See you all in Marseille. # # $Id: agenda,v 1.2 2018/05/01 13:23:25 jim Exp jim $ # 1) Administrivia 2) Report on NCC IoT Activities Marco Hogewoning, RIPE NCC 3) Privacy implications of sewage testing for illicit drugs Elif Sert, Istanbul Bilgi University In smart cities of the future, many IoT devices will be deployed to monitor community behaviour while being designed not to collect personal data in order to preserve individual privacy. This presentation will question this view by examining the phenomenon of sewage testing to monitor community use of illicit drugs in communities 4) RIOT Matthias Waehlisch, Freie Universitaet Berlin 5) SPIN - Security and Privacy for In-home networks Jelte Jansen, SIDN The SPIN project at SIDN Labs aims to explore -and prototype- methods so improve the security and privacy of home networks with regards to the IoT. Within SPIN, we research several topics, such as device traffic visualisation, automated recognition of (bad) patterns, device descriptions, and abuse handling. 6) Role for the numbering and naming community in the IoT domain Sandoche Balakrichenan - AFNIC Both the numbering (RIRs such as RIPE) and naming communities (domain name registries such as Afnic) play an vital role in the current Internet infrastructure. This talk will focus on how the earlier mentioned communities will play the same vital role in the IoT domain. 7) AOB

1 0

Agenda items for RIPE76
by Jim Reid 26 Mar '18

26 Mar '18

RIPE 76 is 6-7 weeks away. Yikes! Plese send your suggestions for speakers or agenda items for the WG to iot-wg-chairs(a)ripe.net.

1 0

Fwd: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT
by Michael J. Oghia 26 Mar '18

26 Mar '18

This might be relevant to this list as well. Best, -Michael ---------- Forwarded message --------- From: Sander Steffann <sander(a)steffann.nl> Date: Thu, Mar 22, 2018, 12:52 PM Subject: Re: [ipv6-wg] Invitation to supply feedback on ITU draft Recommendation on IPv6 address planning for IoT To: ipv6-wg(a)ripe.net <ipv6-wg(a)ripe.net> Hi, > We are happy to announce that ITU Study Group 20 has responded positively to our offer and have decided to share the current working draft with us, for the purpose of review and for RIPE community to provide feedback. > > As it is quite big, the text of this draft Recommendation Y.IPv6RefModel “Reference model of IPv6 subnet addressing plan for Internet of things deployment” has been made available on the IPv6 WG pages: > > https://www.ripe.net/participate/ripe/wg/ipv6/documents/itu-ipv6refmodel > > We kindly invite you to provide feedback and comments on the contents of this document via this mailing list or of course the RIPE Forum web interface. The RIPE NCC has agreed to ensure that the comments will be collected and made available to the ITU via response to the Liaison Statement below. Thanks! As the document is indeed quite long I will give feedback by mentioning the page number, section and quote the particular bit I'm commenting on. I assume, as there are still editorial notes in the document, that minor issues such as grammatical errors don't need comments and will be fixed in a future updates. > Page 3, Introduction: "The current ISPs practice tend to allocate /48 or /64 prefixes to regular customers (e.g., homes) and up to /29 for companies registered at RIRs." There are two issues with this text. The practice of assigning only a /64 goes against the best practice documented in RIPE-690. While I agree that it happens, this should be noted. Also, the "up to /29" text is plain wrong. There are plenty of examples of larger-than-/29 allocations. I guess it means to talk to enterprises that become an LIR, and I don't know any examples for that specific subset. (I'm explicitly NOT going into the difference between allocations and assignments. That doesn't bother me in documents like this) Suggested text: "The current ISPs best current operational practice advises to allocate /48 or /56 prefixes to regular customers (e.g., homes) and up to /29 for enterprises that become LIRs themselves." I think this also better aligns with the scope defined later in the document. > Page 9, 4 Abbreviations and acronyms Might want to add LIR here as well. > Page 13, 9 IPv6 address structure, "Larger networks owners, such as large companies, can get up to /32 global routing prefixes." This contradict the text on page 3. Suggested: "Larger networks owners, such as large companies, can commonly get up to a /29 global routing prefixes." > Page 14, 10 Subnet address requirements, "a smooth transition from IPv4, to dual stack environment (IPv4 and IPv6) and finally to IPv6 only deployments" It might be noted here that IPv4 -> dual-stack -> IPv6 is often no longer the preferred transition path. Technologies like SIIT-DC and NAT64 make it increasingly preferable to skip the dual-stack step. Both to save the cost of an extra transition step and to reduce the complexity caused by the dual-stack phase. > Pages 15&16, 11 Reference model for IPv6 subnet addressing plan I'm not mentioning specific sentences here because I don't agree with the concept behind the whole section. I understand the incentive to map IPv4 prefixes to IPv6 prefixes in the short term. The problem with that strategy is that the given approach results in a very bad IPv6 addressing plan. And it won't be applicable unless the IPv4 addressing plan already conforms to a whole set of conditions. If the IPv4 plan deviates even slightly from the proposed plan then it can't be used. That realistically only makes it deployable in greenfield, in which case there are much better addressing plan possible. Some unrealistic constraints on the IPv4 plan: - the organisation uses a /16 split into /24s - the "categories" subnets have to be kind of hex-aligned (DMZ=0-31, Servers=32-63 etc) And then it creates a suboptimal IPv6 addressing plan: - it is aggregated by building - but the "IPv4-mapping" part is completely unaggregatable - which causes overly complex routing topologies - which causes overly complex firewall rules Without the IPv4 mapping the addressing plan would be close to what the SURFnet addressing plan document recommends (note: I'm one of the authors of that document). In short: this suggested plan is likely not deployable on existing networks, and greenfield networks could do much better. I therefore think this is not a good recommendation at all. > Later sections While there is some sense in the general structure of section 11 (except for the IPv4 mapping), the whole concept is wrangled to pieces in the subsequent sections. For the /56 it's still understandable, but applying this to a /36 is really not even close to a best practice anymore. Networks of that scale just aren't organised in the way that this paper assumes. Furthermore, it also is assigning more than a /44 to a single site, which would violate RIPE policy unless explicitly approved by the RIPE NCC IPRAs. And with a badly structured plan like the recommended one I just can't see that happening. That makes the plan undeployable. So, in summary: it is great that the ITU is helping organisations with deploying IPv6. This plan however seems too far removed from operational reality to be really usable. It looks like an academic exercise without operational experience. It does not feel right to me to publish this as a recommendation unless the shortcomings of the /48 plan section are addressed, and the sections that talk about larger address blocks take common architectures of larger networks into account. Cheers, Sander

3 5

Save the date & call for sponsors: RIOT Summit 2018
by Matthias Waehlisch 14 Mar '18

14 Mar '18

Hi, for those who don't know: RIOT is a modern open source operating system for low-end IoT devices, https://riot-os.org/. Initially developed by folks from academia, the RIOT community now consists of companies, makers, and hobbyist, distributed all around the world. The RIOT community meets annually f2f at the RIOT Summit. The next RIOT Summit is scheduled for September 13-14, 2018 in Amsterdam, locally supported by RIPE NCC. The RIOT Summit aims for bringing together RIOTers, beginners and experts, as well as people interested in the IoT in general and decision makers who plan to deploy RIOT in the future. The event combines plenary talks, hands-on tutorials, and demos. All details are available at https://summit.riot-os.org/2018/. To make the RIOT Summit 2018 a successful event, we need your help! Please consider the following calls: * https://summit.riot-os.org/2018/blog/call-for-sponsors/ * https://summit.riot-os.org/2018/blog/call-for-contributions/ If you have questions, feel free to contact me directly or via summit(a)riot-os.org. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl

1 0

Fwd: Call for new ENISA Expert Group on Transport Security
by Marco Hogewoning 13 Mar '18

13 Mar '18

Dear Colleagues, Please find below a message received from ENISA regarding the creation of an expert group on transport security and resilience. Although quite far away from RIPE’s mission and mandate, with the ever increasing importance of Internet technology and the IP transport layer, it might be of benefit to bring expertise on these areas into that dialogue. At this stage RIPE NCC does not envision to take part in this group directly, although we will try and keep track of progress and any outcomes that might relate to the interests of the RIPE community. Regards, Marco Hogewoning Senior External Relations Officer RIPE NCC Begin forwarded message: > > Dear Experts, > > I trust this email finds you well. > > We would like to bring to your attention a call for applications for a new ENISA Experts Group on Transport Security and Resilience. > The focus of the group will be air, rail and water transport and you can find more information here: https://www.enisa.europa.eu/news/enisa-news/call-for-experts-for-transsec-t… > > Please feel free to share with your networks. > > Best regards, > -Apostolos > > ------------------------------------------------------------------------------------------------------ > Dr Apostolos Malatras > > Network and Information Security Expert > European Union Agency for Network & Information Security > > Address: 1 Vass Sofias Str, Marousi 151 24, Attica, Greece > E- mail: Apostolos.Malatras(a)enisa.europa.eu<mailto:Apostolos.Malatras@enisa.europa.eu> > Office: +30 2814 409 630 > Mobile: +30 6985 051 401

2 1

some suggestions on "work items" for the WG
by Jim Reid 16 Feb '18

16 Feb '18

Here are a few random thoughts about the sorts of things the WG might do. I hope these will spark some discussion. Please note I’m not saying the WG will or won’t adopt any of these suggestions. Or that these are the only topics of interest. This is just an attempt to get everyone to think about the WG’s activities and come forward with their own suggestions. 1) Interaction with SDOs and industry fora How could/should the WG engage with these? Do we want updates from (say) AIOTI, IETF, ETSI and so on? Are any members of the WG involved in the IoT work at these sorts of organisations? 2) Liaison with government/regulators What is and isn’t appropriate here? 3) Advice/support to the NCC The NCC gets asked about IoT. They are going to want the WG to provide advice or present the consensus view (if any) of the RIPE community. 4) Academia We had a few IoT themed presentations at RIPE75 from academics. Does the WG want more (or less) of that sort of thing? What’s the best way to collaborate with academia and what does the WG want to get from that? 5) Training & Documentation Should the WG try to develop training materials/tutorials on IoT, white papers, use cases, best practices and so on? [Probably yes.] If so, what should these focus on and are there any volunteers to help produce these? 6) IP(v6) Addressing Issues What are the main issues around IP(v6) addressing/subnetting schemes for IoT devices and networks? 7) Security Anyone interested in the security aspects of IoT, both in terms of the edge devices and their potential role in DDoS attacks like Mirai? Could the WG develop some recommendations or advice? 8) Policy Making What sort of policies (and on what) could the WG develop for the NCC to implement? 9) Tools and toys Does anyone have new/interesting tools for playing with IoT devices or have useful development environments for them, say for writing/debugging code on a Raspbery Pi or even cheaper chipsets? 10) Anything else? Er.... Let’s hear what you all have to say about the above. Or other things I’ve either overlooked or forgotten about. Over to you...

12 15

mailing list etiquette
by Jim Reid 23 Dec '17

23 Dec '17

What’s this? Have we been teleported back to the late 1980s? :-) Could I remind everyone to use meaningful and relevant Subject: headers when posting to the mailing list. In particular, *PLEASE* do not reply to message digests. It’s inconsiderate and unhelpful to reply to message digests. So don’t do that. Thanks. Replies to message digests create unnecessary and easily avoided problems. Here are the main ones: [1] It messes up the article threading used by everybody’s mail clients. [2] It’s not clear which message(s) in the digest are being replied to. [3] The list archives contain completely useless Subject: headers (like "iot-wg Digest, Vol X, Issue Y”) which make it difficult when browsing the archives to find out who said what and when. Item [3] becomes a real nuisance if/when there’s a need to consult the list archives to verify a consensus decision or review the development of things such as policy proposals.

1 0

Second Part of RIPE Atlas as IoT Devices - The RIPE Atlas Architecture
by Mirjam Kuehne 19 Dec '17

19 Dec '17

Dear colleagues, Here is the second part of the story about RIPE Atlas as IoT Devices. This time we we give some insights into the overall architecture of the RIPE Atlas network and how we manage secure communication with our probe flock. https://labs.ripe.net/Members/kistel/ripe-atlas-architecture-how-we-manage-… Kind regards, Mirjam Kühne RIPE NCC

1 0