SolidBLOG

An interesting, business-oriented article on IPv6, “Is Your Business Ready for IPv6? (Part 1 of 3)“, by Patrick Barnard, Senior Web Editor at TMCnet, was published last month. It presents a non-techie argument for businesses to move their networks to IPv6, part of which I quote below:

IPv6 holds many advantages over IPv4, not the least of which are faster, higher capacity, more efficient and more secure networks. And because all businesses, especially global enterprises, are becoming more “Internet centric,” there’s no question that there will be a growing need for higher-performing networks. IPv6 not only facilitates true end-to-end connectivity, it drastically reduces network congestion and frees up precious bandwidth. Ratified by the Internet Engineering Task Force in 1998, IPv6 uses a 128-bit address code, and thus supports 2128 – or about 34×1038, about 340 undecillion addresses – presumably enough to hold us for quite a while.

The bottom line: IPv6 solves the problem of IPv4 address depletion and is simply more efficient. I would add that IPv6 is more secure than IPv4, provided you implement it properly.

There are, of course, technical challenges facing those who choose to make the transition. It would seem that these are daunting enough to keep many from taking the leap, especially when they don’t see any pressing business case to do so. That may change as IPv4 addresses run out, but by then it will be too late and the ensuing panic rush may well be bloody.

It is up to those in the know to continue informing organizations about the benefits of switching to IPv6 as soon as possible.

Welcome to the club. Most people who have even heard of IPv6 have questions. Before you post those questions on a friendly online IPv6-related forum, however, check out a new paper by the Number Resource Organization (NRO).

The NRO is a group made up of four Regional Internet Registries (RIRs), namely APNIC, ARIN, LACNIC and RIPE NCC. The organization recently released the paper, “IPv6 – What is it, why is it important, and who is in charge?,” which answers some of the more common questions about IPv6. The paper is targeted at non-technical readers such as policy makers and executives.

Here’s a sample from the paper:

3. How are allocations made, and to whom?

IP addresses are managed under a system which has been in operation for some 15 years, and which has supported the successful growth of the Internet by a factor of over 100 in that time. This system was established initially by the Internet Engineering Task Force (IETF), a recognized international standards development organization which is the home of the Internet’s core technical standards.

Today, organisations known as Regional Internet address Registries (RIRs) receive IP addresses from a central global source, the IANA (or Internet Assigned Numbers Authority, which is operated by ICANN, the Internet Corporation for Assigned Names and Numbers). The RIRs then make allocations directly to Internet Service Providers (ISPs) within their respective regions. This system achieves a balance between the uniform resource management (which is critical to the maintenance of a single globally cohesive Internet), and the direct service of the needs of ISPs (namely, those who need and use Internet address space).

Each of the RIRs is a non-profit organization, and acts in accordance with policies and practices which are established by the Internet community in its region. These policies and practices govern the management, allocation, usage and recovery of IP address space (both IPv4 and IPv6) according to the best current practices of the Internet, its industry and stakeholders. At the global level, policies and practices are coordinated through the Address Supporting Organisation (ASO) of ICANN.

In some cases (currently 8 in total), National Internet address Registries (NIRs) provide services within a specific country or economy, in effect as an agent of the RIR. Such registries operate under the policies and authority of their RIR, and do not receive their own allocations of IP address space. The existence and operation of NIRs is specific to local needs and circumstances: for instance, some may be Governmental bodies while others may be independent.

Now that’s informative without being too technical. And you can read the entire paper in under ten minutes! Make that 15 minutes if you’re enjoying a glass of iced coffee.

We’ve got some good news from the DNSSEC front. H Security News reports in the article “First root server provides a DNSSEC-signed zone as of December 1st“:

Joe Abley of ICANN and VeriSign manager Matt Larson announced, at the 59th meeting of the “Réseaux IP Européens” (RIPE) in Lisbon, that, starting on the 1st of December, the central root zone of the Domain Name System (DNS) will be signed, deploying the DNS Security Extensions (DNSSEC) protocol, which has been discussed for years. However, the signed root zone will be distributed only gradually to a total of 13 root servers, while the public key is slated for distribution starting on the first of July, 2010. Responses cannot actually be validated until then. DNSSEC is designed to ensure that responses to DNS requests only come from authorised servers.

The deployment is to be gradual so as to monitor how DNS will handle the expected load.

The Internet is slowly — but surely — putting better DNS security in place. Let’s hope things hold until enough of it is working. In the meantime DNS admins may have to rely on DNSSEC Look-Aside Validation (DLV).

What’s DLV? Here’s how the Internet Systems Consortium (ISC) explains it:

DLV (DNSSEC Look-aside Validation) is an extension to the DNSSECbis protocol. It is designed to assist in early DNSSEC adoption by simplifying the configuration of recursive servers.

DLV provides an additional entry point (besides the root zone) from which to obtain DNSSEC validation information. Without DLV, in the absence of a fully signed path from root to a zone, users wishing to enable DNSSEC-aware resolvers would have to configure and maintain multiple trusted keys into their configuration.

Maintaining multiple trusted keys by hand is an unmanageable task. ISC DLV removes this need by serving as a trusted repository of entry points through which those keys can be securely retrieved by the resolver when it needs them.

Here’s hoping another root server gets onboard soon!

Root server map dated August 2007

(Root server map by Monaneko distributed under the GNU Free Documentation License, Version 1.2. Original is at http://commons.wikimedia.org/wiki/File:Root_Nameserver.svg)

For those of you out there who can’t get enough of IPv4 Exhaustion counters, here are a few more.

The first is from Hurricane Electric:

Here’s the code for the widget:

<script type="text/javascript" src="http://ipv6.he.net/v4ex/sidebar.js"></script>

The Hurricane Electric site also has the counter in the form of an iPhone/iPod touch App, and as iGoogle, Google Desktop, Windows Vista/7 Gadgets. The page for these is at: http://ipv6.he.net/statistics/

There’s one more! A simple HTML counter page can also be found at: http://penrose.uk6x.com/

Cool toys!

(Today we have a report from InfoWeapons Malaysia Country Sales Manager Julian Vincent on the recently concluded INET Asia Regional Conference. Read on!)

The Asia Regional Conference held on the 20th of July 2009. in Kuala Lumpur, Malaysia, has recently concluded. The event was organized by the Internet Society (ISOC) in collaboration with the Asia Pacific IPv6 Task Force and the National Advanced IPv6 Centre of Excellence Malaysia

The key messages that came out of this event were:

1. IPv6 is no longer “next generation” technology but rather the current technology;
2. There is no killer application for IPv6. The internet is the killer application;
3. The Business Case for IPv6: if you want to stay in business start enabling dual-stack networks.

Interestingly, the DNS and DHCP services for the conference network were provided by SolidDNS™, an InfoWeapons product.

More information about the conference is at: http://www.isoc.org/isoc/conferences/inet/09/kualalumpur.shtml

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