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:
- Quick Guide: Prepare Your Systems for the Root KSK Rollover
- KSK Rollover at a Glance
- KSK Rollover: Q+A
Have a Question?
Send an email to email@example.com with “KSK Rollover” in the subject line to submit your questions.
Read more here:: teamarin.net/feed/
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.
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
Read more here:: feeds.circleid.com/cid_sections/news?format=xml
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
Read more here:: feeds.circleid.com/cid_sections/blogs?format=xml
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/
By heise online
Mit dem von Jon Postel und Robert Hinden herausgegebenen RFC 1897 begann man nach langen Jahren der Vorarbeit mit den ersten Umsetzungen des neuen IPv6-Protokolls im Netz der Netze, das vieles anders macht als IPv4 und manches weit besser.
Read more here:: www.heise.de/netze/rss/netze-atom.xml
By Burt Kaliski
Earlier this year, I wrote about a recent enhancement to privacy in the Domain Name System (DNS) called qname-minimization. Following the principle of minimum disclosure, this enhancement reduces the information content of a DNS query to the minimum necessary to get either an authoritative response from a name server, or a referral to another name server.
In typical DNS deployments, queries sent to an authoritative name server originate at a recursive name server that acts on behalf of a community of users, for instance, employees at a company or subscribers at an Internet Service Provider (ISP). A recursive name server maintains a cache of previous responses, and only sends queries to an authoritative name server when it doesn’t have a recent response in its cache. As a result, DNS query traffic from a recursive name server to an authoritative name server corresponds to samples of a community’s browsing patterns. Therefore, qname-minimization may be an adequate starting point to address privacy concerns for these exchanges, both in terms of information available to outside parties and to the authoritative name server.
DNS query traffic from a client to a recursive name server, in contrast, corresponds to individual users’ browsing patterns. To the extent that that these exchanges present a privacy concern, a complementary privacy enhancement, DNS-over-TLS (Transport Layer Security), may be an appropriate mitigation. Just as Web traffic is typically protected by establishing a TLS connection between client and server, DNS traffic can be encrypted by running the DNS protocol over TLS. The encryption takes away any direct information about the query from outside parties, while still maintaining full information at the recursive name server so that it can respond to the client’s request.
(There are also some more sophisticated methods, such as described by Haya Shulman in her recent paper, whereby other parties can get indirect “side” information from the timing or size of encrypted queries. However, the primary risk of direct access to query information is effectively mitigated by the encryption.)
Privacy has received a significant increase in attention within the Internet Engineering Task Force (IETF) over the past two years as a result of concerns about security and pervasive monitoring. The DNS PRIVate Exchange (DPRIVE) working group was formed during this time and, among other documents, has produced an Informational RFC (Request for Comments) on DNS privacy considerations, and is also developing specifications for the enhancements just described.
The session “Protecting Privacy at the Infrastructure Level: The Evolution of Domain Name System Security” at the Privacy.Security.Risk 2015 conference gives an overview of these enhancements and how privacy professionals can integrate them into their portfolio of privacy risk mitigations. Broadly speaking, privacy risks in a DNS-based system can be organized into four categories, depending on where unauthorized disclosure of DNS traffic may occur:
- Between client and recursive
- At recursive name server
- Between recursive and authoritative
- At authoritative name server
In addition, unauthorized modification of DNS traffic can present a privacy risk if a client is misdirected to a resource controlled by an adversary.
Mitigations to the disclosure risks include qname-minimization and DNS-over-TLS, as already mentioned, as well as data handling policies, technologies and audits at the various components involved. The modification risk can also be addressed by DNS-over-TLS (because TLS authenticates as well as encrypts traffic), proper data handling, and domain name security extensions (DNSSEC) and DNS-based Authentication of Named Entities (DANE).
Similar to the way privacy risks elsewhere in an information system are assessed and mitigated, privacy professionals should consider these steps when considering DNS-based systems:
- Ask if these risks apply
- Ask if existing mitigations are sufficient
- Consider how these mitigations can help
- Ask your DNS provider about its privacy practices
DNS privacy will be getting more attention over the coming years, as attacks as well as defenses move from the application to the network layer. It’s good to see efforts like DPRIVE looking ahead and Verisign will continue to support them with practical contributions.
What privacy concerns do you see in your DNS-based systems, and how do you see privacy enhancements such as qname-minimization and DNS-over-TLS playing out?
Written by Burt Kaliski, Chief Technology Officer at Verisign
Follow CircleID on Twitter
Read more here:: feeds.circleid.com/cid_sections/blogs?format=xml
There are many IPv6 books around nowadays with many different approaches to the subject. IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6 by Rick Graziani is an excellent book that will help you fully understand the fundamentals of IPv6. It has a great balance of theory and practical information and is a good starting point for learning about IPv6. Other IPv6 books can be found on our books and e-books pages. We have included a number of Amazon reader reviews below:
[amazon template=add to cart&asin=1587143135]
Graziani provides straightforward understanding.
By M.B. Reynolds on June 5, 2013
The title of the book is an accurate depiction of the contents of this work. The material is presented in a straightforward, methodical manner. The material is presented with understanding and teaching in mind utilizing repetition, sample code, examples, and review. The book is primarily a walk through the various Internet Engineering Task Force (IETF) Requests for Comments (RFC) that comprises the aspects, features, and options of IPv6. Most of these RFC walkthroughs are accompanied with Cisco IOS example code for setting up a router to implement the RFC.
After some of these examples, output from a packet sniffer demonstrates the changes to the packet headers. The book finishes with mechanisms for implementing mixed IPv4 and IPv6 environments and approaches to transitioning from IPv4 to IPv6. Additional references and notes point the reader to more details or topics not covered by the book. Overall I certainly recommend this book as a starting point into IPv6 if the reader has some IPv4 and routing experience. I believe for the novice an additional more general book on networking should be digested first.
The book covers the Internet history and the motivation of IPv6. The IPv6 headers and Extension headers are presented in (again) a straightforward explanation with plenty of diagrams and tables. This explanation includes the specific differences between IPv4 and IPv6 headers. A nice overview of IPSec headers includes authentication, transport, and tunneling modes. Chapter four outlines the multitude of unicast, multicast, and anycast address types. The Neighborhood Discovery Protocol is a new feature of Internet Control Message Protocol version 6 (ICMPv6). Graziani shows ICMPv6 with its enhancements is an important change in how IP hosts identify themselves and others hosts and routers on the network.
The middle of the book discusses IPv6 configuration and routing. Initially, a router is configured from scratch with the various address types. The same example configuration and network is nicely used through the middle of the book. This method is useful for continuity and context. Building on this initial configuration static routes and routing tables are built. The old and new RIPng, EIGRP, and OSPF are compared and contrasted in Chapter 8. The middle ends with Dynamic Host Configuration Protocol version 6 (DHCPv6). The new features such as stateless & stateful DHCP and relay agents are covered. Some interesting differences in Domain Name Service (DNS), TCP, and UDP are explained.
The book ends with mixed IPv4 and IPv6 environments. Graziani shows dual stack allows for parallel IPv4 and IPv6 networks. He covers tunneling methods such as 6to4 and ISATAP that allow for IPv6 packets to be encapsulated in IPv4 packets and routed through an IPv4 network. He shows this allows for a smooth transition from IPv4. Finally Network Address Translation IPv6 to IPv4 (NAT64) is walked through. He shows this allows and IPv4 address to be mapped to a IPv6 address and vice versa to allow coexisting IPv4 and IPv6 networks to communicate.
One of the most substantial changes from IPv4 to IPv6 is the addresses and their types. After introducing hexadecimal and the address format short hands, Graziani explains well the structure of the new 128-bit address: prefix, subnet, and interface id.
After trying others – THIS is THE BOOK!
By John Scott on March 22, 2013
The review written by Cosmic Traveler says it well. I purchased 2 other books before this one and they both ended up on the bottom shelf of my bookshelf. I ordered this one and I couldn’t put it down. If the mere thought of a 128-bit address represented in hexadecimal format makes your hair stand up, you need to order this book and then go have a glass of wine – or a cold beer.
By Matthew Petersen on February 14, 2014
To support future business continuity, growth, and innovation, organizations must transition to IPv6, the next generation protocol for defining how computers communicate over networks. IPv6 Fundamentals provides a thorough yet easy-to-understand introduction to the new knowledge and skills network professionals and students need to deploy and manage IPv6 networks.
Excellent book, highly recommended!
By MSG causes migraines on October 15, 2013
Even though I have been a CCIE since the 1990s and have dealt with IPv6 successfully on the re-certification exams, this book added a lot of needed clarity on the context and usage of IPv6 so the concepts are more readily absorbed and made intuitive. For those network engineers not yet exposed to IPv6 due to their individual customer/employer situations, it is a near-term reality everyone is going to have to deal with as the IPv4 private addressing RFC 1918 (and the updated IPv4 content in RFC 6761) cannot eliminate the reality that IPv4 is nearing address depletion.
[amazon template=add to cart&asin=1587143135]
By COSMIC TRAVELER on November 17, 2012
Are you a network engineer; network designer; network technician; part of the technical staff; and, networking student, including those of the Cisco Networking Academy; who are seeking a solid understanding of the fundamentals of IPv6? If you are, then this book is for you! Author Rick Graziani, has done an outstanding job of writing a book that focuses on the basics of IPv6.
Author Graziani, begins by discussing how the Internet of today requires a new network layer protocol, Ipv6, to meet the demands of its users. Then, the author examines the Ipv6 protocol and its fields. Next, he introduces IPv6 addressing and address types. The author continues by examining the different types of IPv6 addresses in detail. Then, he examines ICMPv6. The author then illustrates the configuration of IPv6, addressing the use of a common topology. Next, he examines the IPv6 routing table and changes in the configurations pertaining to IPv6. The author continues by discussing three routing protocols: RIPng, EIGRP for IPv6 and OSPFv3. Then, he examines DHCP for IPv6 or DHCPv6. The author then covers two of three strategies for IPv4 and IPv6 integration and coexistence: dual-stack and tunneling. Finally, he discusses the third technique for transition from IPv4 and IPv6: Network Address Translation or NAT.
This most excellent book provides a thorough yet easy-to-understand introduction to IPv6. More importantly, this great book is also intended to provide a foundation in IPv6 that will allow you to build on it.
Great book to begin IPv6 study
By Cord Scott on March 22, 2013
Really like this book. Information is accurate and concise and concentrates on the protocol and not just how to configure Cisco gear for IPv6, which is what too many people look for. Not a whole lot on migration but Cisco Press has another book that deals with that.
Everyone should start IPv6 with this book
By Andras Dosztal on May 13, 2013
Detailed but still easy to understand, having a good balance of theory and practical knowledge. Up to date, covers all topics needed for someone who’s getting familiar with IPv6. Having prior IPv4 and routing knowledge is recommended.
[amazon template=add to cart&asin=1587143135]
Network Working Group J. Reynolds, Editor Request for Comments: 3232 RFC Editor Obsoletes: 1700 January 2002 Category: Informational
Assigned Numbers: RFC 1700 is Replaced by an On-line Database
Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo obsoletes RFC 1700 (STD 2) "Assigned Numbers", which contained an October 1994 snapshot of assigned Internet protocol parameters. Description From November 1977 through October 1994, the Internet Assigned Numbers Authority (IANA) periodically published tables of the Internet protocol parameter assignments in RFCs entitled, "Assigned Numbers". The most current of these Assigned Numbers RFCs had Standard status and carried the designation: STD 2. At this time, the latest STD 2 is RFC 1700. Since 1994, this sequence of RFCs have been replaced by an online database accessible through a web page (currently, www.iana.org). The purpose of the present RFC is to note this fact and to officially obsolete RFC 1700, whose status changes to Historic. RFC 1700 is obsolete, and its values are incomplete and in some cases may be wrong. We expect this series to be revived in the future by the new IANA organization. Security Considerations This memo does not affect the technical security of the Internet. Reynolds Informational [Page 1]
Today is 6/6/2012, World IPv6 Launch Day. The day the Internet community permanently enables the IPv6 Internet protocol on their infrastructure. Some refer to this protocol as ‘The New Internet Protocol’. But is it new? No. Not at all.
To deal with the anticipated IPv4 address exhaustion, the Internet Engineering Task Force (IETF) developed IPv6 and described it in Internet standard document RFC 2460. This was published in December 1998. Due to the incompatibilty with the current IPv4 protocol, it was never widely adopted. Now that address exhaustion is imminent, the world is in a hurry to set things straight.
I am the proud owner of what is arguably the coolest IPv6 Internet domain name in the world: ipv6.net. I have owned it for a long time. Not too long ago I realized that 6 days after 6/6/2012, it has been exactly 15 years since the domain name was registered. Apparently, back in 1997, I envisioned that IPv6 was going to be big. I just didn’t know it would take such a long time. But are we there yet? No. Not even close.
Back then the community thought we would run out of IP addresses in just a couple of years. With some tricks we managed to stretch things out until now. We even back-ported some cool stuff from the new protocol into the old. It wasn’t until mid 2011 that we saw some serious global industry initiatives to promote adoption of IPv6: World IPv6 Day on June 8th. On that day some of the smaller as well as larger members of the global Internet community temporarily enabled IPv6 on their infrastructure. For some, just to see what would happen. For others a good test of their transition plan or chosen technology. Some ‘forgot’ to switch it off again. For most it was a big success; a final rehearsal for the big step: a global transition from IPv4 towards IPv6.
Today is the start of that transition. Content providers around the globe will provide access to their services over IPv6. Access providers will provide IPv6 access to their end-users. Hard- and software manufacturers will bring out IPv6 support for their products. This broad involvement will certainly help to solve the chicken and egg, content versus access, problem.
So what will happen after today? If all goes well, and I certainly expect so, we will have marked the beginning of the end of IPv4. It will take many years before IPv6 has become the dominant protocol and IPv4 is marked ‘legacy’. But I expect that after today more and more companies will make a start with their transition. For many it will be hard to make a good business case for it as there is not always a clear added business value. Just don’t wait too long as the landscape is rapidly changing.
Some advice for those about to take the plunge: take ample time to gather knowledge, create awareness among those involved, decide on a sound transition scenario, test and start planning.
And for me? Well, as an IT professional I will be helping out customers doing just that. Personally, I will continue to blog and tweet about IPv6 for a long time to come…