SolidBLOG

In 2008, the European Network and Information Security Agency (ENISA) released a survey entitled: “Stock Taking Report on the Technologies Enhancing Resilience of Public Communication Networks in the EU Member States.” The survey assessed the effectiveness of three technologies with the potential to improve the stability and integrity of public eCommunication networks: MPLS, DNSSEC, and IPv6.

Instead of focusing on consumers, ENISA interviewed representatives large EU service providers (such as Vodafone, WIND, Orange Group-France Telecom, Telenor, Portugal Telecom, OTE), innovative and advanced service providers (NFSi Telecom, Elisa, .SE, Netnod), and research and academic network providers (Ja.net).

The results are interesting as far as DNSSEC and IPv6 are concerned. There is a lot of interest in both technologies, but there are also major stumbling blocks to adoption. Some of the results of the ENISA survey are in the tables below.

ENISA results: DNSSEC
Deployed DNSSEC:	22%
Planning to deploy in three years:	56%
No plan to deploy in three years:	22%

Among the reasons cited by the interviewees for deploying DNSSEC are the following:

• Improvement in the resilience of DNS against attacks
• Ability to detect where someone is tampering with DNS information
• Advance the state-of the-art of the technology offered to consumers
• Provide secure services that their clients can depend on
• Contribute to establishment of the technology

ENISA results: IPv6
Deployed IPv6:	27%
Planning to deploy within three years:	55%
No interest in deploying within three years:	18%

The reasons cited by the interviewees for deploying IPv6 include:

• The increasing demand on IP address space;
• Customer demand for IPv6
• Improvement on network resilience
• Introduction of technical innovations

The ENISA study can be found at: http://www.enisa.europa.eu/doc/pdf/publications/enisa_quarterly_04_09.pdf

Here’s an interesting article on NetWidget Books stating a number of objections against DNSSEC, and answering them. Entitled “The case against DNSSEC”. and written by Ronald Aitchison, President of Zytax, Inc., the article lists four “objections” to DNSSEC:

1. SSL provides known and trusted security, DNSSEC is superfluous
2. DNSSEC is complex and potentially prone to errors
3. DNSSEC makes DoS attacks worse
4. DNSSEC does not solve the last mile problem

The author then answers these point by point. Let me summarize his arguments with a few choice quotes from the article:

1. We have to get to the right place, the right IP address, for SSL to be effective.
2. Some things that are good for us, like medecines, are not always pleasant experiences.
3. DNSSEC Authoritative name servers (serving signed zones), at whatever level, would do a trivial amount more work by sending more zone records per request and thus, at worst, would be marginally more vulnerable to DoS attacks.
4. The DNSSEC standards define end-to-end security. However to achieve end-to-end security the current stub-resolvers installed on most of the worlds computers would need to be replaced with security aware versions

Don’t think that I’ve spoiled it all for you, though. The details are important. Check out Aitchison’s article. It’s a good, quick read.

After that, perhaps it would be a good idea to see how you can implement DNSSEC for your DNS servers.

IBM’s X-Force has released its annual Trend and Risk report. It seems that many of the security threats we will have to face may be coming from the vendors we presume we can trust. Here’s the opening of the story in “X-Force Report: Corporations Becoming No. 1 Security Threat to Their Own Customers“:

With the alarming increase in cyberattacks, criminals are literally turning businesses against their own customers in order to steal consumer’s personal data, warns the latest annual X-Force Trend and Risk report from IBM. “The security industry puts a lot of effort into the technical evaluation of security threats, examining, sometimes at great length, the potential threat that each issue might present to corporations and consumers. Criminal attackers out for profit, however, have considerations that the security industry does not always take into account, such as monetization cost and overall profitability.”

Here’s another highlight of the report:

Of all the vulnerabilities disclosed in 2008, only 47 percent can be corrected through vendor patches. Vendors do not always go back to patch previous year’s vulnerabilities. 46 percent of vulnerabilities from 2006 and 44 percent from 2007 were still left with no available patch at the end of 2008.

That doesn’t sound good. I would think, however, that this news should count as an incentive for purchasing applications that are designed to be secure from the ground up. If that sounds like a pitch for secure computing appliances, well, it is.

It is also an argument for going open source since vulnerabilities can be spotted and fixed if enough eyeballs are looking at and testing the code. Of course you do have to get the eyeballs going at it.

Either way you go, it pays to have some built-in structure that keep security at the forefront.

Read the story and check out the link to the full report (PDF): IBM Internet Security Systems X-Force 2008 Trend & Risk Report

First the good news. I found it on a blog post by Jeremy Hitchcock entitled First gTLD Signed: Dot Gov. Hitchcock writes:

Today is a historic day as the first generic Top-Level Domain (gTLD) has been signed. Only a few other top level domains, all of which are country code Top-Level Domains (ccTLDs), have been signed to date. This step is part of the first phase of adoption. Authoritative DNS servers need to sign and publish their zones. The second part is for the resolvers on the Internet to validate the keys. Both systems working together will provide security in the DNS.

When will the other gTLDs follow suit? So far the ccTLDs have been in the lead.

Now some bad news. Here’s a related item, U.S. Government Misses DNSSEC Deployment Deadline:

The U.S. federal government has missed its initial deadline for rolling out DNS Security Extensions (DNSSEC) on its .gov top-level domain. Federal officials now say they will cryptographically sign .gov by the end of February, one month behind their original schedule.

Still more work to be done! But at least it’s moving.

Yes, blowing our own horn. That’s what we will end up doing by announcing that InfoWeapons SolidDNS™ has just bagged a prestigious JITC certification.

The story, “DISA certifies DNSsec IPv6 appliance“, which appeared in Government Computer News, puts it this way:

The Defense Information Systems Agency (DISA) Joint Interoperability Test Command (JITC) has concluded that InfoWeapons SolidDNS meets the requirements to qualify as a certified IPv6-ready device, providing organizations with the ability to run an IPv4/IPv6 dual-stack Domain Name Service (DNS) from a single appliance.

SolidDNS also supports DNS Security (DNSsec), making it the only DNS appliance on the market that supports both IPv6 and DNSsec.

The JITC certification is required for a product to be placed on the Defense Department’s Approved Product List, which is used by defense, intelligence and other agencies.

SolidDNS™ is a secure, DNS/DHCP appliance with DNSSEC. It is fully capable of dual-stack operations, meaning it can run in IPv4-only, IPv6-only, and in mixed networks. SolidDNS™ has multiple management interfaces that enable administrators to easily manage DNS functions without any need for UNIX or BIND expertise. It is also the first such appliance with a graphical interface to manage DNSSEC features.

SolidDNS™ E-Series appliance

Some of the market’s largest DNS systems providers reported several vulnerabilities in their products, a search of the United States Computer Emergency Readiness Team’s (US-CERT) National Vulnerabilities Database reveals.

Microsoft DNS reported 21 vulnerabilities from January 1, 2007 to December 1, 2008, with five vulnerabilities still outstanding. ISC BIND reported six and three vulnerabilities for versions 8.0 and 9.0, respectively. Two vulnerabilities for version 8.0 remain outstanding, while no outstanding issues remain with version 9.0. Infoblox revealed two vulnerabilities with their DNSone system, but they have all been resolved. Bluecat Networks’ Adonis DNS system had three vulnerabilities, with none outstanding. (See table below)

Infoweapons’ SolidDNS™ appliance reported 0 vulnerabilities for the same time period.

The United States Computer Emergency Readiness Team (US-CERT) works with the United States Department of Homeland Security and the public and private sectors to protect the country’s Internet infrastructure. The agency tries to analyze and reduce cyber threats and vulnerabilities and to disseminate reasoned and actionable cyber security information to the public. It maintains the National Vulnerabilities Database, which stores software product information and security flaws, security checklists, misconfigurations and impact metrics. It can be accessed at http://nvd.nist.gov.

Do you need a reason to deploy DNSSEC? You might want to read this comment:

DNSSEC is a colossal flop, but not a mistake. It’s an embarrassment, but we’d do it all again if we had to. It’s late — it was started years before the IPv6 effort but is (believe it if you can) even less finished and less deployed than IPv6. It’s ugly and complicated and if we knew then what we know now we’d've scrapped DNS itself and started from scratch just to avoid the compromises we’ve made. But we didn’t know then, etc., and what we have to do now is avert our gaze and fully deploy this ugly embarrassing thing.

Interesting opinion. Just as interesting is the person who wrote it: Paul Vixie. You know him. He’s the guy who is the President of Internet Systems Consortium, the group that maintains BIND, which is the software that most DNS servers are based on.

The article by Vixie from which I took the above quote — as well as a few more more by other authors — can be found on Why Deploy DNSSEC, a collection of short pieces hosted at DNSSEC.Net. The collection is in flux, and the maintainers are accepting contributions. So if you have an interesting take on why we should deploy DNSSEC, check out the site and look up the contact they’ve put there for contributors.

The list of contributors so far is as follows:

– Olaf Kolkman, Director, NLnet Labs

– Paul Vixie, President, Internet Systems Consortium (ISC)

– Anne-Marie Eklund-Löwinder, Quality & Security Manager, .SE

– Mark Beckett, VP of Marketing, Secure64 Software Corporation

– Ron Aitchison, Author of Pro DNS & BIND

– European Network and Information Security Agency (ENISA)

If you’re looking for reasons to justify deploying DNSSEC, try this resource.

Members of Réseaux IP Européens (RIPE), which has been pushing for wider implementation of DNSSEC (DNS Security Extensions), agreed to recommend the signing of root zones in their meeting in Dubai. This was reported by Heise Online in IP address management group recommends fast introduction of DNS Security:

The RIPE members have long demanded the introduction of DNSSEC to increase the security within the DNS. DNSSEC allows the PKI-based authentication of DNS server responses, which can help prevent problems like cache poisoning attacks. To use DNSSEC in a sensible way, however, all DNS level must be made secure – not just individual Top Level Domains (TLDs), but also the root zone itself. So far, the concept’s implementation was impeded by the fact that by signing the root zone (which is managed by the NTIA), US authorities would also take control of key management.

Political issues remain, to be sure. Under the current structure, root signing would mean that the root keys would be held by US authorities, which (apparently) is not to everyone’s liking. Still, this recommendation is a step in the right direction as far as security is concerned. It remains to be seen whether the trust considerations can move forward as quickly.

InfoWeapons has released a White Paper on DNSSEC. You can download it from:

http://204.2.248.13/download/whyNeedDNSSECForm.php

Happy reading!

A policy for allocating the what’s left of the IPv4 address blocks has been decided upon. This was reported by Heise Online in the report, Last IPv4 blocks are given out. The report states:

The last remaining IPv4 address blocks have been allocated. IP address administrators (the Regional Internet Registries or RIR) of all five regions (AfriNIC, APNic , ARIN, LacNIC and RIPE) have agreed on how the Internet Assigned Numbers Authority (IANA) should allocate them. The last five blocks available are to be allocated one each to the five RIRs. This was the conclusion reached by the specialists meeting in Dubai at the 57th session of Réseaux IP Européens (RIPE), which is responsible for Europe and parts of Asia. The existing stock of IPv4 addresses held by the IANA will probably only last until January 2011. The individual registries can continue issuing their remaining addresses to internet service providers until December 2011.

There are different methods for estimating how much time is left before IPv4 addresses actually run out. InfoWeapons has published a White Paper on the topic, which can be downloaded at: http://www.infoweapons.com/download/IPv4RunOutForm.php

This White Paper proposes a different model for predicting when the remaining addresses will run out. Using this model, it is estimated that IPv4 addresses will be exhausted by September 2010.

That’s just 23 months away.

This week, we’re adding a new feature to the InfoWeapons website. It’s called the InfoWeapons Weekly Radio Update.

This feature is basically an audio podcast that you can download or stream from our News section. Hosted by Christy Henry, the podcasts will focus on relevant news and trends about the Next Generation Internet Protocol (that’s IPv6 for you!).

Have a listen to our first podcast. It’s in our site’s News and Events section at: http://infoweapons.com/news.