ICANN’s KSK Rollover: What You Need to Know

By Erin Scherer

ICANN is planning to roll, or change, the “top” pair of cryptographic keys used in the Domain Name System Security Extensions (DNSSEC) protocol, known as the Root Zone KSK. This will be the first time the KSK has been changed since it was initially generated in 2010. Changing these keys is an important step to take to ensure security, similar to how changing passwords is considered to be an important safety measure.

According to the ICANN website, “Maintaining an up-to-date KSK is essential to ensuring DNSSEC-signed domain names continue to validate following the rollover. Failure to have the current root zone KSK will mean that DNSSEC-enabled validators will be unable to verify that DNS responses have not been tampered with and thus will return an error response to all DNSSEC-signed queries.”

What does this rollover mean?

Rolling the KSK means generating a new cryptographic key pair and distributing the new public component to everyone who operates validating resolvers.

Once the new keys have been generated, network operators performing DNSSEC validation will need to update their systems with the new key so that when a user attempts to visit a website, it can validate it against the new KSK.

Who will be affected?

According to ICANN, about one-in-four global Internet users, or 750 million people, could be affected by the KSK rollover. That figure is based on the estimated number of Internet users who use DNSSEC validating resolvers.

ICANN is encouraging you to test and check your systems prior to the KSK rollover to confirm what action is needed. They have provided a free testbed to help you determine whether your systems can handle automated updates properly.

Network Operators who update DNSSEC-enabled resolver trust anchor configuration manually should ensure that the new root zone KSK is configured before October 11, 2017.

Anyone who writes, integrates, distributes or operates software supporting DNSSEC validation that correctly follows the RFC 5011 automatic trust anchor protocol does not need to take any action.

Do you need to change anything with ARIN?

No. There is no action that you need to take with us. We are simply passing this message along to ensure our community is aware of this impactful change. We are not involved in the rollover itself, nor will anything here at ARIN change as a result of the rollover.

When is the rollover taking place?

The change will occur in a phased approach. The important dates to be aware of include:

  • 11 July 2017: New KSK published in DNS
  • 19 September 2017: Size increase for DNSKEY response from root name servers
  • 11 October 2017: New KSK begins to sign the root zone key set (This is the actual rollover event)
  • 11 January 2018: Revocation of old KSK
  • 22 March 2018: Last day the old KSK appears in the root zone
  • August 2018: Old key is deleted from equipment in both ICANN Key Management Facilities
Want to learn more? Check out these resources from ICANN:

Have a Question?
Send an email to globalsupport@icann.org with “KSK Rollover” in the subject line to submit your questions.

The post ICANN’s KSK Rollover: What You Need to Know appeared first on Team ARIN.

Read more here:: teamarin.net/feed/

vMX Lightweight 4over6 Virtual Network Function – Juniper and Snabb in a Docker Container

As service providers accelerate the migration of their core networks to IPv6, they need to ensure uninterrupted access and service continuity for all existing IPv4 users. This white paper describes the IPv6 transition challenges service providers are facing, and how Lightweight 4over6, as presented by the IETF RFC 7596, can help.

Read more here:: www.lightreading.com/rss_simple.asp?f_n=1249&f_sty=News%20Wire&f_ln=IPv6+-+Latest+News+Wire

NTIA Issues RFC, Asks for Input on Dealing With Botnets and DDoS Attacks

By CircleID Reporter

NTIA issued a Request for Comments today asking for broad input from “all interested stakeholders, including private industry, academia, civil society, and other security experts,” on actions against botnets and distributed attacks. “The goal of this RFC is to solicit informed suggestions and feedback on current, emerging, and potential approaches for dealing with botnets and other automated, distributed threats and their impact.” Although the department has expressed interested in all aspects of this issue, it has indicated particular interest in two broad approaches where substantial progress can be made. They are:

Attack Mitigation: “Minimizing the impact of botnet behavior by rapidly identifying and disrupting malicious behaviors, including the potential of filtering or coordinated network management, empowering market actors to better protect potential targets, and reducing known and emerging risks.”

Endpoint Prevention: “Securing endpoints, especially IoT devices, and reducing vulnerabilities, including fostering prompt adoption of secure development practices, developing practical plans to rapidly deal with newly discovered vulnerabilities, and supporting adoption of new technology to better control and safeguard devices at the local network level.”

Follow CircleID on Twitter

More under: Cyberattack, Cybersecurity, DDoS

Read more here:: feeds.circleid.com/cid_sections/news?format=xml

Blocking and Filtering in Collaborative Security Context – A Reflection on RFC 7754

By Olaf Kolkman

The other day, I planned to take my 15-year-old son to the movie theatre to see “Hateful Eight” in 70mm film format. The theatre would not allow him in. Under article 240a of the Dutch penal code, it is a felony to show a movie to a minor when that movie is rated 16 or above. Even though I think I am responsible for what my son gets to see, I understand that the rating agency put a 16-year stamp on this politically-incorrect-gun-slinging-gore-and-curse-intense-comedy feature. All this is to say that in the (liberal and democratic) Dutch society, blocking and filtering communication is a fact of life even in contexts outside the Internet.

On the Internet, there are many reasons why blocking and filtering of communication takes place. Some of us use ad-blockers because we get tired of kitchen utilities ads on every single page we visit, simply because we’ve been surfing online recipes. Parents may want to block adult content for minors. Companies may want to ensure their confidential trade secrets don’t leak. All of us want to keep viruses and malware off our computers and networks. Other reasons to block communication include copyright protection, preventing illegal trade (pills, handbags, gambling), public safety, health, and/or moral concerns, the latter triad often being a motivation for the type of blocking and filtering we call censorship.

It may be useful to separate the Internet infrastructure and its content: Many times the motivation for blocking and filtering is based on content. A notable exception is the case of captive portals where the purpose of blocking is to get users to pay for accessing the network as a whole. Herein I am reflecting on blocking and filtering as tools to implement a policy about the content carried on the network. When defining this kind of policy and when translating policy into a technical implementation our Collaborative Security framework, while perhaps not fully applicable, provides input for an approach.

The five key elements from the Collaborative Security approach suggest that during the policy-technology translation, one should:

Foster Confidence and Protect Opportunities. This results in a requirement to be transparent about the policies followed and to make sure that the result of the implementation does not negatively impact the opportunities of those not directly involved. For example, recently the Internet Engineering Task Force specified the use of a specific error code that allows blocking entities to provide information about the reason for blocking specific information, the transparency gained with these Error 451 messages is expected to help foster confidence.

Take into account Collective Responsibility towards the Internet as a whole. Related to protecting opportunities, the blocking party should be aware that there is a responsibility towards the system. Some techniques may adversely impact the way the Internet is collectively managed. Sometimes the impact may be secondary. For instance, users will try to work around the blockage and their methodology may cause damage.

Honor Fundamental Properties and Values. The most obvious set of fundamental values being Human Rights, but also the Internet Invariants such as integrity and global reach, features of the technical architecture that, if impacted significantly and long term, would adversely shape the course of its future.

Take into account Evolution and Consensus. The way to express the policy requirements and detailed methods to implement them are both evolving. The technology-neutral expression of the policy requirement needs to involve a broad set of stakeholders and should include technological specialists in order to assure there are no side effects negatively impacting other key aspects mentioned here.

Think Globally, act Locally. Local blocking and filtering can have global effect (e.g. by local changes to the routing system impacting traffic flows around the globe). On the other hand it may well be that blocking close to the edge, as local as one can get, minimizes global impact.

A recent Internet Architecture Board publication, RFC 7754 – Technical Considerations for Internet Service Blocking and Filtering, provides advice to inform those that translate policy requirements into implementations and helps to address some key aspects mentioned above.

The document looks at different design patterns that can be applied in the policy-technology translation and assesses features like scope, granularity, efficacy, and security of various approaches. The discussion of scope tries to answer the question of whether blocking and filtering can be localized enough to target a given jurisdiction or policy realm and does not have more than local impact. Granularity assesses whether innocent bystanders are likely to be effected. Efficacy addresses the effectiveness of the measure and informs a risk discussion around the implementation. Finally, security assesses the impact on the security implications.

Understanding these technical features is important when it needs to be decided (often by a judge) if the medicine is worse than the disease. If the implementation has more than local scope and impacts more than just the targeted form of communication and is not going to be effective then the societal costs may be too high.

As an example of this type of analysis: In 2011 my colleagues wrote about a workshop on DNS Blocking. Let’s annotate the findings from that workshop:

  • DNS blocking/filtering does not solve the problem, as blocking access to a website does not mean that the content simply disappears from the online space; on the contrary, it is only not accessible at a certain location, but it can be easily moved to a different one. The measure can, therefore, be avoided at all times. [This is an Efficacy argument]
  • It has implications for privacy and security; [A Security argument]
  • It is incompatible with DNSSEC and undistinguishable from DNS attacks; [A Security argument]
  • It encourages Internet fragmentation/balkanization, affecting the universal resolvability of the Internet. Instead of having one global Internet, we move towards having a fragmented, country-by-country Internet; [A Scope and a Collaborative Security argument]
  • It may prevent people from accessing legal content, thus affecting people’s right to information. When a website is blocked because it hosts illegal content, access to the legal content hosted on the respective website is also blocked; [A Granularity argument]
  • It makes it even more difficult to attack the source of the problem, as it may function as an early warning system for criminals. [A Security argument]

The RFC takes a broader approach than looking at specific technology but looks at the properties of rendezvous systems (of which the DNS is an example), the Network (routing system, network flows, etc.), and the end-points.

It concludes that there are no perfect or even best ways to perform blocking and filtering, and there only seem less bad ways that are probably hybrid approaches implemented at the end-point and rely on information from the network. In addition, it makes one interesting other observation:

“where filtering is occurring to address content that is generally agreed to be inappropriate or illegal, strong cooperation among service providers and governments may provide additional means to identify both the victims and the perpetrators through non-filtering mechanisms, such as partnerships with the finance industry to identify and limit illegal transactions.”

In other words, technology may not always be the appropriate tool to fulfil a policy requirement. So not only: Think Globally, act locally, but also think creatively and act collaboratively.

Disclaimer: I am co-author of RFC 7754. This blog post is a personal reflection and does not necessarily reflect the Internet Society’s opinion, the opinion of my RFC7754 co-authors, or that of the IAB.

Note: An earlier version of this article appeared on the Internet Society blog.

Written by Olaf Kolkman, Chief Internet Technology Officer (CITO), Internet Society

Follow CircleID on Twitter

More under: Censorship, DNS, Policy & Regulation, Security

Read more here:: feeds.circleid.com/cid_sections/blogs?format=xml

Change of paradigm with IPv6 : no global addresses on router interfaces

By Eric Vyncke

Guest Post: Eric Vyncke discusses his IETF document RFC 7404 – Using Only Link-Local Addressing inside an IPv6 Network which describes the use of LLAs for links between routers in an IPv6 network.

The post Change of paradigm with IPv6 : no global addresses on router interfaces appeared first on APNIC Blog.

Read more here:: blog.apnic.net/feed/