Update on NIS 2: Proposed amendments by the Parliament alter scope on (root) DNS
Dear colleagues, We'd like to inform you that some changes have been proposed to NIS 2 that would accommodate some of the concerns raised by the RIPE NCC and the RIPE community. As a quick recap: the European Commission proposed an update to the Network and Information Security Directive, commonly referred to as NIS 2, which would bring the DNS root servers into scope of the directive, resulting in regulatory oversight of the DNS root server operators. Following our response on the NIS 2 proposal in the public feedback process, we reached out to a number of parties involved in the legislative process, including some members of the European Parliament, drawing attention to our concerns. The ITRE committee, which is leading this dossier in the European Parliament, yesterday published its initial report listing a number of proposed amendments. We are happy to see that it has taken on board the concerns we and other community members have raised. In particular, the committee proposes amending the scope of the directive to include: "authoritative domain name resolution services as a service procurable by third-party entities”. We realise this leaves a substantial part of the DNS in scope; however, this change would address the concerns we raised in our response by removing from scope: - DNS root operations - Small and non-commercial operators, such as people running their own DNS servers We are pleased to see these amendments and appreciate the rapporteur, MEP Groothuis, addressing our concerns. The full report is available at: https://www.europarl.europa.eu/doceo/document/ITRE-PR-692602_EN.pdf (The relevant changes are on pages 6, 27 and 57.) As a next step, the ITRE committee is provisionally scheduled to discuss this report on 27 May. We will continue to track the legislative process and keep you informed about the progress. Regards, Marco Hogewoning Manager, Public Policy and Internet Governance RIPE NCC
Marco Hogewoning wrote on 07/05/2021 11:12:
We will continue to track the legislative process and keep you informed about the progress.
Hi Marco, [cc: routing-wg] Thanks for the work y'all have been doing to sort out some of the DNS scoping issues. This is really worthwhile and it looks like it changes the proposed text from something which was completely unworkable to something which isn't entirely unreasonable. I had a quick skim through the rest of the document and came across Amendment 13:
(54a) In order to safeguard the security and to prevent abuse and manipulation of electronic communications networks and services, the use of interoperable secure routing standards should be promoted to guarantee the integrity and robustness of routing functions across the ecosystem of internet carriers. Justification Interoperable secure routing standards are for example Resource-PKI.
I'm quite concerned to see this thrown into the proposed directive at this time. Speaking as an operator who implements RPKI in multiple contexts, I'm not confident that it's matured as a technology to the point that it would be advisable to codify it in legislation. There are several reasons here, e.g. protocol limitations, implementation limitations and potential future scope creep. The protocol limitations relate to the fact that RPKI currently only deals with route origin validation, and it is trivial to bypass the security gains it provides. Geoff Huston has written a couple of articles on this over the last while, and while there are legitimate reasons to want to deploy RPKI, it's also important to understand what it can and cannot do at the moment. In particular, it lacks any scope for routing policy management, which is an integral part of routing security. Operationally, there are still significant problems relating to RPKI TA availability and integrity, and there's been a good bit of discussion on the ripe routing-wg and at the ietf about local cache synchronisation problems. In terms of scope creep, I'd be concerned that if legislators feel that RPKI is appropriate to name in legislation, they may also feel that there might be benefit to other protocols which have been defined with the aim of addressing routing security. BGPsec would be one of these. I totally get why legislators would feel that adding routing security into the cybersecurity directive would be a good thing to do, but I don't think we're there yet with the technology side of things. Would it be possible to see whether there's consensus on this position, and whether we could present some of this to the EUPARL committee in the same way that the DNS proposals were handled? Nick
Dear Nick,
Marco Hogewoning wrote on 07/05/2021 11:12:
We will continue to track the legislative process and keep you informed about the progress.
Hi Marco,
[cc: routing-wg]
Thanks for the work y'all have been doing to sort out some of the DNS scoping issues. This is really worthwhile and it looks like it changes the proposed text from something which was completely unworkable to something which isn't entirely unreasonable.
I had a quick skim through the rest of the document and came across Amendment 13:
(54a) In order to safeguard the security and to prevent abuse and manipulation of electronic communications networks and services, the use of interoperable secure routing standards should be promoted to guarantee the integrity and robustness of routing functions across the ecosystem of internet carriers. Justification Interoperable secure routing standards are for example Resource-PKI.
I'm quite concerned to see this thrown into the proposed directive at this time.
Personally I am not that worried about this particular amendment. IMHO the way it is worded leaves it fairly open as to what technologies to deploy, with RPKI being just flagged as an example. Important as well is that changing the recital like this, doesn't alter the scope of the directive. In that sense it only stresses the need for entities that fall within the scope to think about routing security and take appropriate measures to prevent the risks in that area. And I think we can all acknowledge that those risks do exist, so would be hard to argue against. We are not in scope for the current directive, so I have little knowledge on the details, but I have understood that similar requirements are already in place for entities within the scope of the current NIS directive. Where the requirement is to "secure against routing attacks" and deploying RPKI is seen as one, but not the only, way to satisfy that requirement and be compliant. In other words: "I do RPKI" is an acceptable answer, but you can also argue that you have other measures in place that would remove or reduce the risks and be compliant with the directive. The amendment introduces new text, but I don't think it actually introduces new requirements compared to the proposal as-is or the way the current directive, as it is in force, is implemented by the national authorities.
Would it be possible to see whether there's consensus on this position, and whether we could present some of this to the EUPARL committee in the same way that the DNS proposals were handled?
If you have a consensus position to bring forward, it is always worth reaching out to the people involved and see if there still is a possibility to make changes. But I would recommend to take into consideration that striking the text altogether might be quite a big "ask" at this stage. Probably easier if an alternative text could be found that would remove the community's concerns, whilst still addressing the need to secure routing. As it mentions RPKI only as an example, would there be others to add or alternatives that would produce the same result? Because it might actually help if you can list several alternatives, as a way to stress that legislation should be agnostic on technologies. Best, MarcoH
Dear all, first - I personally agree with Marco's assessment of the potential impact which the proposed new recital 54a would have. Second, I would like to ask if maybe an update on the state of play regarding the EU Cybersecurity Strategy could be a topic of general interest for the upcoming RIPE82 meeting. IIRC the Cooperation WG does not have an agenda for this meeting yet. Kind regards Sabine Sabine Meyer _________________________ 312 - International Coordination Telecommunications Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen Tulpenfeld 4, 53113 Bonn Phone: +49 228 14-3128 Mobile: +49 172 7084686 E-Mail: Sabine.Meyer@bnetza.de Internet: www.bundesnetzagentur.de -----Ursprüngliche Nachricht----- Von: cooperation-wg <cooperation-wg-bounces@ripe.net> Im Auftrag von Marco Hogewoning Gesendet: Freitag, 7. Mai 2021 16:31 An: Nick Hilliard <nick@foobar.org> Cc: cooperation-wg <cooperation-wg@ripe.net>; routing-wg <routing-wg@ripe.net> Betreff: Re: [cooperation-wg] Update on NIS 2: Proposed amendments by the Parliament alter scope on (root) DNS Dear Nick,
Marco Hogewoning wrote on 07/05/2021 11:12:
We will continue to track the legislative process and keep you informed about the progress.
Hi Marco,
[cc: routing-wg]
Thanks for the work y'all have been doing to sort out some of the DNS scoping issues. This is really worthwhile and it looks like it changes the proposed text from something which was completely unworkable to something which isn't entirely unreasonable.
I had a quick skim through the rest of the document and came across Amendment 13:
(54a) In order to safeguard the security and to prevent abuse and manipulation of electronic communications networks and services, the use of interoperable secure routing standards should be promoted to guarantee the integrity and robustness of routing functions across the ecosystem of internet carriers. Justification Interoperable secure routing standards are for example Resource-PKI.
I'm quite concerned to see this thrown into the proposed directive at this time.
Personally I am not that worried about this particular amendment. IMHO the way it is worded leaves it fairly open as to what technologies to deploy, with RPKI being just flagged as an example. Important as well is that changing the recital like this, doesn't alter the scope of the directive. In that sense it only stresses the need for entities that fall within the scope to think about routing security and take appropriate measures to prevent the risks in that area. And I think we can all acknowledge that those risks do exist, so would be hard to argue against. We are not in scope for the current directive, so I have little knowledge on the details, but I have understood that similar requirements are already in place for entities within the scope of the current NIS directive. Where the requirement is to "secure against routing attacks" and deploying RPKI is seen as one, but not the only, way to satisfy that requirement and be compliant. In other words: "I do RPKI" is an acceptable answer, but you can also argue that you have other measures in place that would remove or reduce the risks and be compliant with the directive. The amendment introduces new text, but I don't think it actually introduces new requirements compared to the proposal as-is or the way the current directive, as it is in force, is implemented by the national authorities.
Would it be possible to see whether there's consensus on this position, and whether we could present some of this to the EUPARL committee in the same way that the DNS proposals were handled?
If you have a consensus position to bring forward, it is always worth reaching out to the people involved and see if there still is a possibility to make changes. But I would recommend to take into consideration that striking the text altogether might be quite a big "ask" at this stage. Probably easier if an alternative text could be found that would remove the community's concerns, whilst still addressing the need to secure routing. As it mentions RPKI only as an example, would there be others to add or alternatives that would produce the same result? Because it might actually help if you can list several alternatives, as a way to stress that legislation should be agnostic on technologies. Best, MarcoH
Dear Sabine Thank you for your topic suggestion. You recall correctly, and the RIPE82 Cooperation WG agenda is yet to be published next week. Since we already had an informative and a very interactive session on NIS2, followed by a submission on behalf of WG members, we accept that there might be more room needed for discussion of EU Cybersecurity Strategy. Also, for example, the recently passed legislation to remove and block access to "terrorist content". For RIPE82, we currently plan to cover The Digital Service Act legislative initiative, as well as some novel approaches with regards to the eIDs - electronic identification schemes. We welcome and invite all members to suggest any topics of interest or any preference they may have not just for the RIPE82, but also for the ongoing Coop WG meetings, so that we could include them in our annual work-plan and post RIPE 82. Desiree — on behalf of Coop WG Co-chairs
On 7 May 2021, at 15:43, Sabine.Meyer@bnetza.de <Sabine.Meyer@BNetzA.DE> wrote:
Dear all,
first - I personally agree with Marco's assessment of the potential impact which the proposed new recital 54a would have. Second, I would like to ask if maybe an update on the state of play regarding the EU Cybersecurity Strategy could be a topic of general interest for the upcoming RIPE82 meeting. IIRC the Cooperation WG does not have an agenda for this meeting yet.
Kind regards Sabine
Sabine Meyer _________________________ 312 - International Coordination Telecommunications Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
Tulpenfeld 4, 53113 Bonn Phone: +49 228 14-3128 Mobile: +49 172 7084686 E-Mail: Sabine.Meyer@bnetza.de Internet: www.bundesnetzagentur.de
-----Ursprüngliche Nachricht----- Von: cooperation-wg <cooperation-wg-bounces@ripe.net> Im Auftrag von Marco Hogewoning Gesendet: Freitag, 7. Mai 2021 16:31 An: Nick Hilliard <nick@foobar.org> Cc: cooperation-wg <cooperation-wg@ripe.net>; routing-wg <routing-wg@ripe.net> Betreff: Re: [cooperation-wg] Update on NIS 2: Proposed amendments by the Parliament alter scope on (root) DNS
Dear Nick,
Marco Hogewoning wrote on 07/05/2021 11:12:
We will continue to track the legislative process and keep you informed about the progress.
Hi Marco,
[cc: routing-wg]
Thanks for the work y'all have been doing to sort out some of the DNS scoping issues. This is really worthwhile and it looks like it changes the proposed text from something which was completely unworkable to something which isn't entirely unreasonable.
I had a quick skim through the rest of the document and came across Amendment 13:
(54a) In order to safeguard the security and to prevent abuse and manipulation of electronic communications networks and services, the use of interoperable secure routing standards should be promoted to guarantee the integrity and robustness of routing functions across the ecosystem of internet carriers. Justification Interoperable secure routing standards are for example Resource-PKI.
I'm quite concerned to see this thrown into the proposed directive at this time.
Personally I am not that worried about this particular amendment. IMHO the way it is worded leaves it fairly open as to what technologies to deploy, with RPKI being just flagged as an example.
Important as well is that changing the recital like this, doesn't alter the scope of the directive. In that sense it only stresses the need for entities that fall within the scope to think about routing security and take appropriate measures to prevent the risks in that area. And I think we can all acknowledge that those risks do exist, so would be hard to argue against.
We are not in scope for the current directive, so I have little knowledge on the details, but I have understood that similar requirements are already in place for entities within the scope of the current NIS directive. Where the requirement is to "secure against routing attacks" and deploying RPKI is seen as one, but not the only, way to satisfy that requirement and be compliant. In other words: "I do RPKI" is an acceptable answer, but you can also argue that you have other measures in place that would remove or reduce the risks and be compliant with the directive.
The amendment introduces new text, but I don't think it actually introduces new requirements compared to the proposal as-is or the way the current directive, as it is in force, is implemented by the national authorities.
Would it be possible to see whether there's consensus on this position, and whether we could present some of this to the EUPARL committee in the same way that the DNS proposals were handled?
If you have a consensus position to bring forward, it is always worth reaching out to the people involved and see if there still is a possibility to make changes. But I would recommend to take into consideration that striking the text altogether might be quite a big "ask" at this stage. Probably easier if an alternative text could be found that would remove the community's concerns, whilst still addressing the need to secure routing.
As it mentions RPKI only as an example, would there be others to add or alternatives that would produce the same result? Because it might actually help if you can list several alternatives, as a way to stress that legislation should be agnostic on technologies.
Best,
MarcoH
Marco Hogewoning wrote on 07/05/2021 15:30:
Personally I am not that worried about this particular amendment. IMHO the way it is worded leaves it fairly open as to what technologies to deploy, with RPKI being just flagged as an example.
ok noted.
Important as well is that changing the recital like this, doesn't alter the scope of the directive. In that sense it only stresses the need for entities that fall within the scope to think about routing security and take appropriate measures to prevent the risks in that area. And I think we can all acknowledge that those risks do exist, so would be hard to argue against. Yep, definitely no intention to argue against the principal. We all - community, legislators, etc - agree on the importance of routing security. The only concern I had was whether codifying specific ways of handling this was advisable, but if they're not being codified, that's fine.
Nick
participants (4)
-
Desiree Miloshevic -
Marco Hogewoning -
Nick Hilliard -
Sabine.Meyer＠BNetzA.DE