Fwd: Re: BEREC consultation: contribution
I have only partially absorbed all aspects of the BEREC document and EU Article61, but my impression is of some important missing elements. In particular, I have not noticed references to co-habitation of multiple NTP in one customer site. The subject of resilience seems missing. BEREC has given us a simple model on which to comment, with three levels of NTP. Rather than defining what an NTP must always be, I prefer to consider what a customer needs from the NTP regardless of its logical location. Given that we are RIPE, and given the absence of any bidirectional Public Data Communication Network other than the Internet, I focus my comments accordingly. Summary Whatever the point of delivery of the Network connection, there must be clear signalling of whether or not the provision of Network connection is functional. For Internet Access the NTP must indicate the status of its connection to the Internet. The form of the indication is considered next for each of the BEREC logical Termination Points. *BEREC connection point C:* (Where the NTP has a routing function or NAT, IP aware) The NTP must indicate via its customer port, using IETF standard routing protocol, what connections it is offering /{list of minimum customer selectable protocols?}/. It must withdraw those routing announcements as quickly as the standard allows in the event that its peer router in the network becomes unavailable. *BEREC connection point B:* (Where the connection is provided at a modem port, Ethernet or WiFi) The network must provide signalling of its status to the user. The user must be provided with: * visibility of the adjacent router(s) by routing protocol announcements from the operators router(s). The list of offered routing protocols being a required part of the service description. * the IP address delegated by the operator for the CPE, manually or by DHCP. * the permanence of the IP address delegation (Static or Dynamic) * the IP address of the adjacent router(s) in the provider's network, to enable security filtering *BEREC connection point A:* (Where the connection is by wired, optical or wireless Ethernet) The Network must offer DHCP for the customer's delegated address, and the address of the available Network router. The Network may offer IP routing protocols, as for connection point B. The physical Signal must be withdrawn at the physical layer when the Network is otherwise unable to communicate loss of routes ( for comparison consider removal of dial tone). *Other Requirements:* 1/ In cases B and C, user-configuration of the characteristics of the user port must be supported. Including Local MAC address, Local IP address, Local default router, Local routing protocol, as applicable. 2/ It must be contractually clear whether an Internet Connection service at an NTP is fully open, or in some way restricted.A fully open Internet Connection will have a public IP address capable of end to end communication with any other public Internet address on the same version of IP. This would facilitate the customer in supporting an Internet Server, if they so choose. Restrictions that make the connection less than a fully open Internet connection must be disclosed in the documentation of the connection service, and include: * Network Address Translation, either in the network (CGN) or on supplied NTP. * Blocking of access to some Internet addresses (as has sometimes been the case for open DNS resolvers). 3/ Power Supply resilience for network devices becomes increasing important. Consideration should be given to regulation of common low power battery backup supply connection for all NTP. Rationale Most homes in the EU have more than one Network by which to access the Internet, commonly one fixed and one or more mobile. The NTP of each Network must allow for the existence of others and must enable the customer to program decisions about which Network to use. Automated resilience of Internet connectivity becomes increasingly important as: * home working becomes more prevalent * critical devices such as medical appliances and alarm systems are connected in the home via the Internet Therefore resilience for Internet connectivity must be considered in regulation with respect to both Network selection and power supply resilience, as follows. *Network selection:* On the PSTN the existence of Dial-tone has been the indication of availability at the NTP. A home can easily have more than one PSTN NTP, and more than one fixed line connection to the Internet in addition to mobile. Therefore, customer owned equipment must have the opportunity to be able to directly determine, in an automated fashion, whether or not connectivity via each Internet Connection Provider is functional. Methods are dependent on the chosen logical Network Termination Point and are proposed in the Summary above. *Power supply resilience:* Logical termination equipment (e.g. modem) may be required for some physical access media. If power is not supplied from the network then the customer's domestic supply may be used. In the latter case the regulator must give consideration to backup supply standardisation. The proliferation of individual AC to DC power converters and the need for Inverters to get back to AC supply levels from battery backup is not energy efficient. Standardisation of low power DC supply to NTP devices would reduce electrical wastage and could reduce the number of manufactured components required where devices are permanently powered with DC. Steve Nash Writing my personal opinions, with the Sponsorship of NETSCOUT. On 10/10/2019 17:52, Marco Hogewoning wrote:
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/regulator...
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
_______________________________________________ connect-wg mailing list connect-wg@ripe.net https://lists.ripe.net/mailman/listinfo/connect-wg -- Steve@nashfamily.me.uk is now my personal email address.
I am trying to absorb Steve Nash's comments have not yet gotten to absorbing the original BEREC text :-) {Or, in IETF microphone speak. "I haven't read the draft, but..."} My high-level take (which I haven't managed to formulate) is that we must ask/counsel that in the different connection points, what the expected ownership of liability is. Maybe that's a "US"-centric point of view, so my understanding is the European view would ask: "who does the regulator fine". Steve Nash <Steve@nashfamily.me.uk> wrote: > *BEREC connection point C:* > (Where the NTP has a routing function or NAT, IP aware) > The NTP must indicate via its customer port, using IETF standard routing > protocol, what connections it is offering /{list of minimum customer > selectable protocols?}/. It must withdraw those routing announcements as > quickly as the standard allows in the event that its peer router in the > network becomes unavailable. So, *today* the list of "IETF standard routing protocol" in the home is DHCPv4. That's all. I.e. you either get a default route or you don't. And, if DHCPv4 is withdrawn, all communication in the home tends to cease, because despite IPv4 Link-Local addresses (169.254.0.0/16), many devices consider the lack of DHCPv4 to mean the network is useable. In particular phones, which means you can't talk to the lights with the phone app. In an RFC7084 situation with IPv6, we expect IPv6 to continue to function, and withdrawal here means no longer advertising a GUA (ULA only) via RA. In a HOMENET future, this can mean BABEL and HNCP too. I don't know whether this belongs in a RIPE response. I do think that that there more interesting question is who has the liability in each case. > Rationale > Most homes in the EU have more than one Network by which to access the > Internet, commonly one fixed and one or more mobile. The NTP of each Network > must allow for the existence of others and must enable the customer to > program decisions about which Network to use. > Automated resilience of Internet connectivity becomes increasingly important > as: > * home working becomes more prevalent > * critical devices such as medical appliances and alarm systems are > connected in the home via the Internet > Therefore resilience for Internet connectivity must be considered in > regulation with respect to both Network selection and power supply > resilience, as follows. I agree with this statement, and RFC7084 is really bad for doing this. HOMENET aimed to solve this; do you think that there is something a regulator can do to make this better? > *Network selection:* > On the PSTN the existence of Dial-tone has been the indication of > availability at the NTP. > A home can easily have more than one PSTN NTP, and more than one fixed line > connection to the Internet in addition to mobile. > Therefore, customer owned equipment must have the opportunity to be able to > directly determine, in an automated fashion, whether or not connectivity via > each Internet Connection Provider is functional. > Methods are dependent on the chosen logical Network Termination Point and are > proposed in the Summary above. Sure sounds like HNCP and BABEL is required :-) > *Power supply resilience:* > Logical termination equipment (e.g. modem) may be required for some physical > access media. If power is not supplied from the network then the customer's > domestic supply may be used. In the latter case the regulator must give > consideration to backup supply standardisation. Agreed...! > The proliferation of individual AC to DC power converters and the need for > Inverters to get back to AC supply levels from battery backup is not energy > efficient. > Standardisation of low power DC supply to NTP devices would reduce electrical > wastage and could reduce the number of manufactured components required where > devices are permanently powered with DC. That would be awesome. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
On 23 Oct 2019, at 22:04, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
My high-level take (which I haven't managed to formulate) is that we must ask/counsel that in the different connection points, what the expected ownership of liability is. Maybe that's a "US"-centric point of view, so my understanding is the European view would ask: "who does the regulator fine”.
Dear colleagues, Just to say thank you for all the positive responses I received both here on list, as well as In private conversations, much appreciated. I also would like to thank those who have made comments to the contents of the draft, making suggestions towards a possible response. Partially responding to Michael’s question above and some other things raised over the course of last week. Let me try and clarify a few points. First towards the process, me and my colleagues are of course available to help with the drafting, serving in our role as secretariat. I’m also happy to chime in on this list with some on-the-fly editing or too summarise responses, if the community appreciates that. But of course, as explained in my presentation, we need some clear guidance from the community on the contents to start this drafting process. To Micheal’s question and some other comments regarding the expected outcome. I don’t think at this stage BEREC is aiming to get a single solution, the draft lists a few different options and I expect that most will remain in the final version. My current assessment is that they are mostly seeking feedback on the rationale for the different scenarios and the criteria under which diversions from a particular ruleset are allowed. I don’t feel this is about “who to fine?”, obviously in the end this is about regulation and there might be repercussions for entities that are found in breach of the law. However this is not in BEREC’s mandate at the moment. The aim for this process, and BEREC’s role here, is really to create some consistency in interpretation of this directive and the resulting legislation, also in how to resolve conflicts with other texts. Especially since it rubs against some other directives, most importantly the net neutrality one, which might be a source of conflict where one directive says A and the other says B. The EECC in this context I think is a bit more loosely defined than the net neutrality guidelines, which appear a bit less open to interpretation. At the same time, the current draft guidelines on the NTP to seem to take the account the “technical realities” a bit more, where it tries to identify reasons why diversions would be allowed. Hope this clarifies and looking forward to your feedback on the text. Regards, MarcoH
EXEC SUM: ** I think that you are looking for text that addresses the net-neutrality and ** privacy implications of each attachment point, and leave it to legislators to ** figure out which one is best. Marco Hogewoning <marcoh@ripe.net> wrote: >> On 23 Oct 2019, at 22:04, Michael Richardson <mcr+ietf@sandelman.ca> wrote: >> >> My high-level take (which I haven't managed to formulate) is that we must >> ask/counsel that in the different connection points, what the expected >> ownership of liability is. Maybe that's a "US"-centric point of view, so my >> understanding is the European view would ask: "who does the regulator fine”. > To Micheal’s question and some other comments regarding the expected > outcome. I don’t think at this stage BEREC is aiming to get a single > solution, the draft lists a few different options and I expect that > most will remain in the final version. My current assessment is that > they are mostly seeking feedback on the rationale for the different > scenarios and the criteria under which diversions from a particular > ruleset are allowed. Yes, I understood this was the goal. Thus my difficulty in figuring out how to get from what I care about, to what they care about. That's why I'm coming at it at big wrong. I care about: 1) protecting the right for the resident to connect any home router. 2) protecting the view that the home router must be controlled by the resident. 3) the home router has to be involved in securing the home, and this means disclosing to the home router a list of all devices in the home... so privacy. 4) the universal deployment of IPv6 Note that I said home router, while the term "CPE" is usually meant to mean a device owned and controlled by the ISP. (Their demarcation point) For many IPv4-centric non-gamers, they would be perfectly fine having a full router CPE, with their own home router behind that, doing double NAT, and no IPv6. IPv6 users and those who want good gaming response, the lack of UPnP and IPv6 is a big deal. Unfortunately, RFC7084 does not mandate DHCPv6-PD on the LAN side of the router, and short of a full-homenet HNCP/BABEL deployment (which I would dearly like...), this means that IPv6 will not flow into the second router. Some solutions are: 1) don't have stupid two-layers of routers. Let the resident into at least some part of the CPE, perhaps involving containers (maybe even Trusted Execution Environments) to isolate the different concerns. 2) write a document mandating LAN-side DHCPv6-PD for all CPEs. 3) mandate CPEs support L2-passthrough, effectively splitting the "modem" and the "router" parts. Each of these solutions provides much clearer view as to "who to fine" as well. > I don’t feel this is about “who to fine?”, obviously in the end this is > about regulation and there might be repercussions for entities that are > found in breach of the law. However this is not in BEREC’s mandate at > the moment. The aim for this process, and BEREC’s role here, is really > to create some consistency in interpretation of this directive and the > resulting legislation, also in how to resolve conflicts with other > texts. Especially since it rubs against some other directives, most > importantly the net neutrality one, which might be a source of conflict > where one directive says A and the other says B. There must also be some privacy directives that conflict. Having DNS lookups in the ISP-controlled device could be a privacy breach. Having a list of devices in the home in a ISP-hosted database (via TR-069) has got to have privacy implications. Putting the boundary in the right place solves these. I am not at all an expert on these other directives. I am good at wrangling text, but I don't think that I can read up on the directives in sufficient time to address them directly. ** I think that you are looking for text that addresses the net-neutrality and ** privacy implications of each attachment point, and leave it to legislators to ** figure out which one is best. I just want to see progress on the direction of who is liable for attacks by rogue Things, so that the relevant parties can be persuaded to make the right investments. In particular, the ISPs have not had a good track record in the past of actually investing in security patches for their devices. prplFoundation had a meeting this week in Berlin, which I did not make, and I wonder if they had an opinion. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
Dear Colleagues, Thank you Michael for the summary and of course everybody else who provided feedback, both here as well as via private channels. From what I gathered so far, the neutrality bit seems to be one of the more important parts. But I think that is also reflected in the draft guidelines, which to me at least read as saying that freedom of choice should be the default. There is obviously a reason why the document is expanding quite a bit on the circumstances under which this should not be the case, by providing examples of “objective technical criteria” that would be acceptable as a rationale to ignore the net neutrality part. Taking it back to my initial question: should we provide input on behalf of the RIPE community? I am not feeling that confident that there has been sufficient feedback at this stage to submit anything as reflecting the broader opinion of the community. As the secretariat I am in your hands and I am happy to take guidance from the chairs. But if as a group we feel this is important, we need to start drafting some text that is to the point of addressing the contents of the draft guidelines. Did somebody take the time and look at the criteria in the draft, do they make sense from an operational perspective? Of course, we can also submit something along the lines of “RIPE community has a strong preference for XYZ”, but to make such a statement on behalf of the community, we probably need a bit more than the few voices we have heard so far. Finally, as I mentioned before, the process is still open for people to file individual responses. So if there is no consensus on a collective submission, not all is lost. And of course, we will keep monitoring this process and alert you when other opportunities to provide input arise. Best, Marco Hogewoning External Relations, RIPE NCC
On 25 Oct 2019, at 20:12, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
EXEC SUM:
** I think that you are looking for text that addresses the net-neutrality and ** privacy implications of each attachment point, and leave it to legislators to ** figure out which one is best.
Marco Hogewoning wrote on 12/11/2019 11:27:
Did somebody take the time and look at the criteria in the draft, do they make sense from an operational perspective? Of course, we can also submit something along the lines of “RIPE community has a strong preference for XYZ”, but to make such a statement on behalf of the community, we probably need a bit more than the few voices we have heard so far.
Marco, often there isn't a clear divide between who controls or who needs to control the CPE. For example on DSL networks, it's fine for the customer to own and have full control of the CPE, but on a DOCSIS network it doesn't work like this. The DOCSIS protocol requires that the provider maintains substantial control over the CPE both in order to properly manage spectrum utilisation on the cable segment, but also to do things like QOS. I.e. if you buy a 100M downstream/10M upstream package, the DS rate limiting is performed by the CMTS, but the 10M upstream rate limiting is done by the CPE. So if the end user were to get full control of the CPE in this situation, then they would be able to give themselves as much bandwidth as was available, or they could sniff the cable segment, or inject malicious frames there, or whatever. Of course it would be possible to use CPE-owned devices, but the provider will still have substantial control. Also, the provider wouldn't necessarily be able to offer the same level of service or support, e.g. the ability to log into the modem and start diagnosing cable signal problems. This distinction is not really clear in the BEREC document, and the DOCSIS situation indicates that this is a subtle and important issue. Nick
participants (4)
-
Marco Hogewoning
-
Michael Richardson
-
Nick Hilliard (INEX)
-
Steve Nash