On June 23, the Canadian Radio-television and Telecommunications Commission (CRTC) announced its decision to require Canadian telecommunications service providers (TSPs) to block botnets on their networks. Before deciding on the detailed requirements of a botnet blocking framework, the Commission has submitted a variety of questions to the CRTC Interconnection Steering Committee (CISC) for review. The CISC is comprised of representatives from various companies in telecom industry and was established by the CRTC to assist in developing information, procedures and guidelines to support regulatory activities.
Drawing on our expertise as operators of the .CA top-level domain and as a provider of DNS-based cybersecurity services, CIRA provided a submission to the CRTC’s 2021 Notice of Consultation, which expresses our views on the subject of botnet blocking. Overall, we’re in favour of many elements of the CRTC’s decision, but we also recognize that there are a lot of details to be worked out by CISC in the coming months to determine exactly how these new regulatory requirements will play out. We plan to participate in the CISC process to help determine the best possible framework for addressing botnet activity on Canadian networks.
Guiding Principles and Scope
In our submission, we urged the CRTC to adopt transparency, non-discrimination, necessity, and proportionality as the guiding principles behind a framework for blocking botnets. Fortunately, all these principles are reflected in the language of the decision. We’re especially encouraged by the Commission’s focus on necessity. The decision states that the framework is to be applied exclusively for the purpose of cyber security, and the Commission is clear that it has no intention of requiring TSPs to block other forms of illegal activity or to employ blocking for commercial, competitive, or political purposes.1
We also cautioned strongly in the submission that a framework for blocking traffic to maintain network security must not be used as a justification for content-blocking or filtering. Several other respondents echoed this sentiment, and the decision makes it clear that the CRTC shares this view. As it sits now, the body of policy which empowers TSPs to block traffic for security purposes is contained in Telecom Regulatory Policy 2009-657, which addresses internet traffic management practices, but does not provide a detailed prescription for handling network security threats in particular. As a result, we noted that it will be helpful for the Commission to carefully define the specific circumstances under which TSPs can lawfully block traffic for network security and integrity purposes.
In its original notice of consultation, the CRTC limited its focus to the issue of blocking botnets. However, the submissions by TSPs and other players in the network security space make it clear that there are other equally concerning indicators of compromise (IOCs) that TSPs currently mitigate by blocking traffic. The decision notes that “botnets, malware, and computer intrusions are intertwined, making it impractical and inefficient to block only botnet traffic and not block other types of IOCs,” and that “the policy justification for blocking botnet traffic (i.e., the harm caused to Canadians by cyber threats) applies equally to other IOCs.”2 The parameters of this decision remain limited to botnets, but we won’t be surprised if the CISC report recommends that a blocking framework include other categories of cyber threats.
Jurisdiction
Much of CIRA’s submission was dedicated to the question of whether the Commission has the authority to mandate that TSPs are required to block certain types of traffic. Through our analysis of the Telecommunications Act, we concluded that it provides jurisdiction for a network-level blocking framework only, on a non-mandatory basis. We submitted that the Commission grant TSPs limited permission to block malicious traffic, but we did not reach the conclusion that the CRTC has the authority to mandate that TSPs block traffic. CIRA was not alone in questioning the CRTC’s jurisdiction on this front. Bell Canada, Eastlink, INFOSECSW, the Internet Society, the ITPA/CCSA, RCCI, TCI, and Xplornet all went a step further than CIRA and argued that regulatory intervention is wholly unnecessary, as many ISPs are already sharing botnet and malware IOCs through the Canadian Security Telecommunications Advisory Committee’s (CSTAC) working groups and other industry forums. The CRTC, however, finds in this decision that it does indeed have the jurisdiction to require TSPs to block traffic. In support of this decision, the Commission notes that the evidence submitted by TSPs demonstrates that there is no uniform approach to blocking IOCs across TSPs in Canada, and very few available metrics from TSPs indicating that they track blocking events or infections. The Commission also does not consider the Canadian Security Telecommunications Advisory Committee (CSTAC) to be an adequate forum for sharing botnet or malware IOCs, favouring instead a regulatory approach that provides a baseline level of filtering across the board.
Centralized vs. Decentralized
We argued that a decentralized approach to botnet blocking which avoids a single point of failure is the best option, and that the various blocklist providers under such a framework would need to comply with certain service standards and requirements. This method would reflect the current multi-stakeholder approach to tackling cybersecurity issues that is widely adopted in the network operator industry.
The Commission, however, contends that “a centralized blocklist is the most efficient and effective option,”3 but also that “complete centralization is not necessarily required.”4 Several submissions suggested that some form of centralization with an independent third party with expertise in cyber security is preferred over leaving it up to individual TSPs to design solutions for their own networks.
CSE and the CCCS suggested CIRA as a candidate for this role. That’s an open question, and a further detail to be worked out over the next nine months with CISC. In CIRA’s view, any third –party acting as a centralized authority for compiling IOCs would function as a convener and compiler and be reliant on the existing cybersecurity threat feed ecosystem.
Opt-in vs. Opt out
In the Notice of Consultation, the Commission asked whether users should have the option to opt-in or opt-out of a botnet blocking regime. In its preliminary views laid out in the decision, the CRTC expressed a preference for a “block-by-default” model. Stemming from our concerns about jurisdiction, we believe that the CRTC does not have the authority to mandate a blocking regime one way or the other; instead its role should be to approve or deny any blocking frameworks proposed by individual TSPs. As a result, we advocated for the CRTC to approve models with an “on-by-default” approach where users have the ability to easily opt out of their TSP’s threat-blocking regime.5 Nevertheless, the CRTC stands by its preliminary views to block botnets by default without an opt-out mechanism, and notes that users would still have the option of using VPNs or alternative DNS resolvers outside of their TSP to bypass their ISP’s threat filtering.
Clarification
Finally, we’d like to clarify an assertion made by the CRTC in the decision that relates to CIRA’s Canadian Shield service. Paragraph 63 notes that CIRA recently entered into a partnership with Mozilla Firefox, by virtue of which the service is enabled by default for users of the web browser. The paragraph states:
“Under the partnership, Canadian Mozilla Firefox users’ web traffic is filtered by default by CIRA Canadian Shield blocking infrastructure. This initiative has been deployed over the course of this proceeding. It began in July 2021 and had reached 100% of Canadian Mozilla Firefox users by late September 2021.”
While it’s correct that Canadian Shield is enabled for users of Mozilla Firefox, the in-browser tier of service does not filter for cybersecurity threats. The option enabled in the Firefox browser is the first tier, or “Private,” option of Canadian Shield, which resolves DNS queries via DNS over HTTPS (DoH), but does not include botnet protection. Tier 2 is the “Protected” option, which filters for malware, phishing, botnet and scam protection. Finally, tier 3 is the “Family” option, which augments tier 2 capabilities with the blocking of pornographic content. Users can enable Protected and Family options by adjusting their DNS settings to point to CIRA’s resolution service.
Next Steps
We’re glad that many of the recommendations in our submission to the consultation were reflected in the CRTC’s decision. CIRA’s mission is, after all, to build a trusted Internet for Canadians. The rigorous application of threat mitigation by network operators is integral to building trust in the security and stability of the internet in Canada. A framework for limiting botnet traffic will help achieve this, but threat mitigation must also be balanced against the principles of necessity, transparency, and proportionality. We’ll be pursuing participation in the CISC Network Working to help propose the basic technical parameters of the botnet blocking mechanism to limit botnet threats in Canada.
1. CRTC, Telecom Decision 2022-170, June 23, 2022, Appendix 1 https://crtc.gc.ca/eng/archive/2022/2022-170.htm
2. Ibid., para. 131
3. Ibid., Appendix 2
4. Ibid., para 110
5. CIRA, Intervention of the Canadian Internet Registration Authority in CETNC 2021-9, March 15, 2022, para. 83 https://static.cira.ca/2021-03/CETNC%202021-9%20-%20CIRA%20intervention.pdf
