From sandoche.balakrichenan at afnic.fr Sun Oct 6 10:38:11 2019 From: sandoche.balakrichenan at afnic.fr (sandoche Balakrichenan) Date: Sun, 6 Oct 2019 10:38:11 +0200 Subject: [iot-wg] =?utf-8?q?=5BReminder=5D=C2=A0Call_for_applications_for?= =?utf-8?q?_the_IoT_hackathon=2C_12-13_October=2C_Rotterdam?= Message-ID: <2eb63079-8543-5672-34d9-6ed1a9709014@afnic.fr> Dear colleagues, As you are aware, RIPE is organising its first IoT hackathon on 12-13 October in Rotterdam, the weekend before RIPE 79. We still have some places and we would be happy if you would like to participate/contribute. There are lots of interesting projects : https://pad.riseup.net/p/IoT-hackathon-keep planned during the Hackathon If you would like to take part in any of the projects mentioned in the etherpad above or propose a new one, please apply before 10/10: https://www.ripe.net/participate/forms/apply/iot-hackathon-rotterdam-2019/ So that the organisers can confirm your participation before the event. You can find more information about the event on RIPE Labs: https://labs.ripe.net/Members/becha/iot-hackathon-at-ripe-79-in-rotterdam Thanks, Sandoche. From jim at rfc1035.com Thu Oct 17 10:36:03 2019 From: jim at rfc1035.com (Jim Reid) Date: Thu, 17 Oct 2019 09:36:03 +0100 Subject: [iot-wg] For information: ETSI releases IoT security standard In-Reply-To: <9E162B1F-E19D-4741-9C23-454890176A53@ripe.net> References: <9E162B1F-E19D-4741-9C23-454890176A53@ripe.net> Message-ID: <6AE7283A-96C7-4100-A4A6-8BBD544E6902@rfc1035.com> FYI colleagues, the connect WG is handling a possible RIPE response to this consultation. If you have any comments or insight to contribute, please take them to the connect WG. > On 21 Feb 2019, at 14:28, Marco Hogewoning wrote: > > The European Telecommunications Standardisation Institute (ETSI), earlier this week released their initial standard for securing IoT devices. The document is titled ?Technical specification - Cyber Security for Consumer Internet of Things? (ETSI TS 103 645), and states that its objective is, ?...to support all parties involved in the development and manufacturing of consumer IoT with guidance on securing their products.? > > While it remains a very high-level document, containing many recommendations our community probably takes for granted, it could be helpful in guiding newcomers towards a more secure implementation of their IoT services and devices. The recommendations include items like, for instance, using non-default passwords. > > Although this is not yet a European Standard (EN) level specification, it is likely that any European standard specification in this area would be developed based on guidance from this document. In this context, a specification like this might also be reflected in product conformity guidelines such as the Radio Equipment Directive, that I posted about last week. > > The specification is available at https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf From marcoh at ripe.net Thu Oct 17 11:08:28 2019 From: marcoh at ripe.net (Marco Hogewoning) Date: Thu, 17 Oct 2019 11:08:28 +0200 Subject: [iot-wg] For information: ETSI releases IoT security standard In-Reply-To: <6AE7283A-96C7-4100-A4A6-8BBD544E6902@rfc1035.com> References: <9E162B1F-E19D-4741-9C23-454890176A53@ripe.net> <6AE7283A-96C7-4100-A4A6-8BBD544E6902@rfc1035.com> Message-ID: <4FC5A478-526B-403F-B65F-B6DBA5E12527@ripe.net> Dear colleagues, Please be aware that the below is a FYI. The Connect WG is currently looking into submitting a response to a BEREC consultation regarding the definition of the Network Termination Point, as part of implementing the recent European Electronic Communications Code. The BEREC draft guidelines are available from https://berec.europa.eu/eng/document_register/subject_matter/berec/regulatory_best_practices/guidelines/8821-berec-guidelines-on-common-approaches-to-the-identification-of-the-network-termination-point-in-different-network-topologies And as Jim mentioned, please leave any comments to the Connect WG mailing list, as this working group is trying to reach a consensus opinion to submit into the public consultation process on behalf of the RIPE community. Best, Marco Hogewoning External Relations, RIPE NCC > On 17 Oct 2019, at 10:36, Jim Reid wrote: > > FYI colleagues, the connect WG is handling a possible RIPE response to this consultation. If you have any comments or insight to contribute, please take them to the connect WG. > >> On 21 Feb 2019, at 14:28, Marco Hogewoning wrote: >> >> The European Telecommunications Standardisation Institute (ETSI), earlier this week released their initial standard for securing IoT devices. The document is titled ?Technical specification - Cyber Security for Consumer Internet of Things? (ETSI TS 103 645), and states that its objective is, ?...to support all parties involved in the development and manufacturing of consumer IoT with guidance on securing their products.? >> >> While it remains a very high-level document, containing many recommendations our community probably takes for granted, it could be helpful in guiding newcomers towards a more secure implementation of their IoT services and devices. The recommendations include items like, for instance, using non-default passwords. >> >> Although this is not yet a European Standard (EN) level specification, it is likely that any European standard specification in this area would be developed based on guidance from this document. In this context, a specification like this might also be reflected in product conformity guidelines such as the Radio Equipment Directive, that I posted about last week. >> >> The specification is available at https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Thu Oct 17 15:03:58 2019 From: jim at rfc1035.com (Jim Reid) Date: Thu, 17 Oct 2019 14:03:58 +0100 Subject: [iot-wg] clarification on BEREC consultation Message-ID: <9FE6F7B4-FC0E-4015-961C-84EC7F85A023@rfc1035.com> Peter kindly pointed out that my earlier mail today on this topic mistakenly quoted an ETSI thing, not the BEREC consultation. Apologies for any confusion. The morning coffee hadn't kicked in when I sent the email. Well that's my excuse and I'm sticking to it. The important thing is unchanged though. The Connnect WG is leading the effort on a community response to the BEREC consultation on identification of the network termination point. If members of the IoT WG have input to that community response, please raise them in the Connnect WG. We can of course discuss BEREC's ideas here. However that is unlikely to influence whatever community response emerges from the Connect WG. From lear at lear.ch Thu Oct 17 18:01:37 2019 From: lear at lear.ch (Eliot Lear) Date: Thu, 17 Oct 2019 18:01:37 +0200 Subject: [iot-wg] clarification on BEREC consultation In-Reply-To: <9FE6F7B4-FC0E-4015-961C-84EC7F85A023@rfc1035.com> References: <9FE6F7B4-FC0E-4015-961C-84EC7F85A023@rfc1035.com> Message-ID: <93d9c620-8de5-a627-0f57-0814df411245@lear.ch> Jim, Do you have pointers to additional information regarding all of this? Eliot On 17.10.19 15:03, Jim Reid wrote: > Peter kindly pointed out that my earlier mail today on this topic mistakenly quoted an ETSI thing, not the BEREC consultation. Apologies for any confusion. The morning coffee hadn't kicked in when I sent the email. Well that's my excuse and I'm sticking to it. > > The important thing is unchanged though. The Connnect WG is leading the effort on a community response to the BEREC consultation on identification of the network termination point. If members of the IoT WG have input to that community response, please raise them in the Connnect WG. We can of course discuss BEREC's ideas here. However that is unlikely to influence whatever community response emerges from the Connect WG. > > > _______________________________________________ > iot-wg mailing list > iot-wg at ripe.net > https://lists.ripe.net/mailman/listinfo/iot-wg > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jim at rfc1035.com Thu Oct 17 18:24:41 2019 From: jim at rfc1035.com (Jim Reid) Date: Thu, 17 Oct 2019 17:24:41 +0100 Subject: [iot-wg] clarification on BEREC consultation In-Reply-To: <93d9c620-8de5-a627-0f57-0814df411245@lear.ch> References: <9FE6F7B4-FC0E-4015-961C-84EC7F85A023@rfc1035.com> <93d9c620-8de5-a627-0f57-0814df411245@lear.ch> Message-ID: On 17 Oct 2019, at 17:01, Eliot Lear wrote: > > Jim, > > Do you have pointers to additional information regarding all of this? Here goes.... > -------- Forwarded Message -------- > Subject: [connect-wg] BEREC consultation: Identification of the network > termination point > Date: Thu, 10 Oct 2019 18:52:21 +0200 > From: Marco Hogewoning > To: connect-wg at ripe.net > > Dear colleagues, > > Earlier this week, BEREC (Body of European Regulators for Electronic > Communications) announced a public consultation on their draft > guidelines for interpreting the ?network termination point (NTP)?. These > guidelines have been designed in accordance with Article 61(7) of the > European Electronic Communications Code to provide national regulatory > authorities (NRAs) with guidance on how to interpret the EU directives > and implement them in their national legislation. > > This consultation is open to the public. While the RIPE NCC has no > particular position on this topic, we think it is important for the > community to consider the impact of these guidelines. They could impact > not only our members? operations, but the RIPE NCC?s engagement strategy > on a number of topics such as IPv6 and IoT security. > > We invite the Connect Working Group to discuss the proposed guidelines > and, should it reach a rough consensus as determined by the chairs, the > RIPE NCC is willing to submit that opinion as a response on behalf of > the RIPE community. As we see pros and cons to either alternative, > failure to reach consensus will mean we will not respond to this > consultation on behalf of the RIPE community, but would instead > encourage individual members to provide their own responses. > > I?ll provide a brief description of the problem space and the potential > impact below, but I recommend reading the draft guidelines as they are > posted on the BEREC website: > https://berec.europa.eu/eng/document_register/subject_matter/berec/regulatory_best_practices/guidelines/8821-berec-guidelines-on-common-approaches-to-the-identification-of-the-network-termination-point-in-different-network-topologies > > Please note that while BEREC?s deadline is 21 November, we would need a > few days to process and file the formal response and we kindly request > the working group to respect close of business on 15 November as its > internal deadline to reach consensus. > > Key Issues > > One of the key questions laid out in the document is whether or not the > CPE or modem is part of the NTP. EU Regulation 2015/2120 states with > regard to Internet access services in article 3(1): > >> ?End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice [?]? > > The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) > provide further guidance on the implementation and state: > >> ?In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users? ability to replace that equipment with their own equipment, i.e. whether it provides ?obligatory equipment?. >> >> Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.? > > Not only is this subject to national definitions and implementations, it > also allows for exceptions under ?objective technological necessity?. > Among other things, the draft guidelines go into a lot of detail with > regards to the consequence of the different options that exist. > > As explained above, the RIPE NCC has no immediate position on which > option is the better alternative. However, it could impact our > engagement strategy in the longer term. > > There are roughly two alternative options: the modem or CPE is > ?obligatory? and as such will be supplied and maintained by the access > provider as part of their network, or the end-user is allowed or even > required to source their own equipment, which needs to be compatible > with the network. > > The two different options would impact, for example, the RIPE NCC?s > focus when it comes to IPv6 adoption. Although we have seen successful > deployments under both scenarios, it is either the ISP that is in > control and has to make the choice (which of course often means our > members are deciding), or we need to somehow create awareness among > end-users and engage more with manufacturers, importers and retailers to > adopt equipment that supports IPv6. > > We also imagine that such a choice would impact the scale and, more > importantly, the speed of IPv6 adoption. > > We also expect that if the prevailing choice would be to allow the > end-user to select their own equipment, there will be an increased > demand for strict standards and profiles to ensure interoperability. > While the draft guidelines recognise that the CPE market is both > competitive and innovative, we expect these discussions to lean towards > additional certification requirements to ensure interoperability. > > In light of the current discussions about IoT security, especially in > household appliances, we also see a big focus on the CPE as providing > some security-related services. Several of these systems, such as SPIN > and MUD/FUD, have been presented to the community. Again, a more > scattered landscape where users select their own devices might make it > challenging for these technologies to reach a sustainable level of adoption. > > More generally, we can expect that greater freedom of choice in > selecting devices would come with some additional security challenges, > where the increased variety could also lead to an increase in the > variety of attack vectors and vulnerabilities. Also, as the CPE would no > longer be in the ISP?s domain, we would lose the ability to quickly roll > out patches and would instead have to trust the end-user or manufacturer > to install updates in a timely fashion. > > Again, this is something where we would expect further discussion with > regards to regulatory measures and (mandatory) certification to ensure > minimum requirements are met and to protect the consumer. > > In either case, we trust the NRAs and the market to make an informed > decision on the most appropriate approach and are happy to bring the > RIPE community?s opinion forward to this consultation. Regardless of the > outcome, we will continue to monitor these discussions and adjust our > engagement strategy accordingly, both towards policymakers as well as > the various market participants and, where necessary, the end-users. > > Regards, > > Marco Hogewoning > External Relations, RIPE NCC From jordi.palet at consulintel.es Thu Oct 17 18:32:07 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 17 Oct 2019 18:32:07 +0200 Subject: [iot-wg] clarification on BEREC consultation In-Reply-To: References: <9FE6F7B4-FC0E-4015-961C-84EC7F85A023@rfc1035.com> <93d9c620-8de5-a627-0f57-0814df411245@lear.ch> Message-ID: <8116E0DF-021C-4F44-A8C2-CE584234A46D@consulintel.es> It looks to me that whatever is the decision regarding the CPE, RFC8585 must be mandated. This way everybody knows that whatever the ISP is implementing as IPv6-only with IPv4-as-a-Service, it will just work. Regards, Jordi @jordipalet ?El 17/10/19 18:24, "iot-wg en nombre de Jim Reid" escribi?: On 17 Oct 2019, at 17:01, Eliot Lear wrote: > > Jim, > > Do you have pointers to additional information regarding all of this? Here goes.... > -------- Forwarded Message -------- > Subject: [connect-wg] BEREC consultation: Identification of the network > termination point > Date: Thu, 10 Oct 2019 18:52:21 +0200 > From: Marco Hogewoning > To: connect-wg at ripe.net > > Dear colleagues, > > Earlier this week, BEREC (Body of European Regulators for Electronic > Communications) announced a public consultation on their draft > guidelines for interpreting the ?network termination point (NTP)?. These > guidelines have been designed in accordance with Article 61(7) of the > European Electronic Communications Code to provide national regulatory > authorities (NRAs) with guidance on how to interpret the EU directives > and implement them in their national legislation. > > This consultation is open to the public. While the RIPE NCC has no > particular position on this topic, we think it is important for the > community to consider the impact of these guidelines. They could impact > not only our members? operations, but the RIPE NCC?s engagement strategy > on a number of topics such as IPv6 and IoT security. > > We invite the Connect Working Group to discuss the proposed guidelines > and, should it reach a rough consensus as determined by the chairs, the > RIPE NCC is willing to submit that opinion as a response on behalf of > the RIPE community. As we see pros and cons to either alternative, > failure to reach consensus will mean we will not respond to this > consultation on behalf of the RIPE community, but would instead > encourage individual members to provide their own responses. > > I?ll provide a brief description of the problem space and the potential > impact below, but I recommend reading the draft guidelines as they are > posted on the BEREC website: > https://berec.europa.eu/eng/document_register/subject_matter/berec/regulatory_best_practices/guidelines/8821-berec-guidelines-on-common-approaches-to-the-identification-of-the-network-termination-point-in-different-network-topologies > > Please note that while BEREC?s deadline is 21 November, we would need a > few days to process and file the formal response and we kindly request > the working group to respect close of business on 15 November as its > internal deadline to reach consensus. > > Key Issues > > One of the key questions laid out in the document is whether or not the > CPE or modem is part of the NTP. EU Regulation 2015/2120 states with > regard to Internet access services in article 3(1): > >> ?End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice [?]? > > The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) > provide further guidance on the implementation and state: > >> ?In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users? ability to replace that equipment with their own equipment, i.e. whether it provides ?obligatory equipment?. >> >> Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.? > > Not only is this subject to national definitions and implementations, it > also allows for exceptions under ?objective technological necessity?. > Among other things, the draft guidelines go into a lot of detail with > regards to the consequence of the different options that exist. > > As explained above, the RIPE NCC has no immediate position on which > option is the better alternative. However, it could impact our > engagement strategy in the longer term. > > There are roughly two alternative options: the modem or CPE is > ?obligatory? and as such will be supplied and maintained by the access > provider as part of their network, or the end-user is allowed or even > required to source their own equipment, which needs to be compatible > with the network. > > The two different options would impact, for example, the RIPE NCC?s > focus when it comes to IPv6 adoption. Although we have seen successful > deployments under both scenarios, it is either the ISP that is in > control and has to make the choice (which of course often means our > members are deciding), or we need to somehow create awareness among > end-users and engage more with manufacturers, importers and retailers to > adopt equipment that supports IPv6. > > We also imagine that such a choice would impact the scale and, more > importantly, the speed of IPv6 adoption. > > We also expect that if the prevailing choice would be to allow the > end-user to select their own equipment, there will be an increased > demand for strict standards and profiles to ensure interoperability. > While the draft guidelines recognise that the CPE market is both > competitive and innovative, we expect these discussions to lean towards > additional certification requirements to ensure interoperability. > > In light of the current discussions about IoT security, especially in > household appliances, we also see a big focus on the CPE as providing > some security-related services. Several of these systems, such as SPIN > and MUD/FUD, have been presented to the community. Again, a more > scattered landscape where users select their own devices might make it > challenging for these technologies to reach a sustainable level of adoption. > > More generally, we can expect that greater freedom of choice in > selecting devices would come with some additional security challenges, > where the increased variety could also lead to an increase in the > variety of attack vectors and vulnerabilities. Also, as the CPE would no > longer be in the ISP?s domain, we would lose the ability to quickly roll > out patches and would instead have to trust the end-user or manufacturer > to install updates in a timely fashion. > > Again, this is something where we would expect further discussion with > regards to regulatory measures and (mandatory) certification to ensure > minimum requirements are met and to protect the consumer. > > In either case, we trust the NRAs and the market to make an informed > decision on the most appropriate approach and are happy to bring the > RIPE community?s opinion forward to this consultation. Regardless of the > outcome, we will continue to monitor these discussions and adjust our > engagement strategy accordingly, both towards policymakers as well as > the various market participants and, where necessary, the end-users. > > Regards, > > Marco Hogewoning > External Relations, RIPE NCC _______________________________________________ iot-wg mailing list iot-wg at ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jim at rfc1035.com Thu Oct 17 18:46:47 2019 From: jim at rfc1035.com (Jim Reid) Date: Thu, 17 Oct 2019 17:46:47 +0100 Subject: [iot-wg] clarification on BEREC consultation In-Reply-To: <8116E0DF-021C-4F44-A8C2-CE584234A46D@consulintel.es> References: <9FE6F7B4-FC0E-4015-961C-84EC7F85A023@rfc1035.com> <93d9c620-8de5-a627-0f57-0814df411245@lear.ch> <8116E0DF-021C-4F44-A8C2-CE584234A46D@consulintel.es> Message-ID: <92B3691C-B137-4F21-B993-5EA65CD11839@rfc1035.com> > On 17 Oct 2019, at 17:32, JORDI PALET MARTINEZ wrote: > > It looks to me that whatever is the decision regarding the CPE, RFC8585 must be mandated. > > This way everybody knows that whatever the ISP is implementing as IPv6-only with IPv4-as-a-Service, it will just work. Jordi, your comments belong in the Connect WG. Please take them there.