IPv6 and Taxes

How many times have you heard skeptics ask about the ephemeral Business Case for IPv6? How many times did you ask yourself that question?  Even if you are one of its cheerleaders, there are those lonely, rainy nights when you doubt and wonder. The pressure did come off a bit lately. By now we all know there is no way around it so that might be a business case in itself. But then … does it matter?  Who cares?

Everyone will soon care.

Picture this nightmare: It is April 15. Yeah, that April 15, the IRS day. You procrastinated (much like many organizations who should have moved to IPv6 by now) and you are ready to do what it takes to file by the deadline. You are ready in your tax filing sweat pants and head band, the pile of supporting papers is to your right on the desk,  a gallon of coffee to your left, it is game time! Now all you need is the forms.

The Facebook lover, twitter savvy, Google master you sees no problem. You confidently type in your browser: www.irs.gov and … you wait, and wait … and wait some more. Odd but, it must be crowded you say. You get to the forms and start the download. The progress bar is barely moving while the clock on the wall seems to have learned about the theory of relativity and is racing to deadline. You keep your cool. You smash a few knickknacks from your desk. You sob like a baby but the download is still dragging. Pride be damned, you call a friend and … what do you know? He has no problem downloading the forms, many times over. You suspect he might be doing it even for fun at your expense.

What in the IRS World is going on?

You my friend are accessing the IRS website over IPv6 and the IRS webpage is only 61% effective over IPv6. Here is the proof, the blue line in the graph bellow shows the Global IPv6 Effectiveness of www.irs.gov on April 22 as measured by v6Sonar (the only superhero APM in the IPv6 space: www.v6sonar.com).


OK, so the nightmare scenario happened a few days before April 15 but … it did happen!

Morals of the story:

1)      IPv6 does matter and it might be your Ironman (just to stay actual) or your Freddy

2)      Dear IRS, don’t take the OMB mandate for granted. Not even you can just wave a magic wand and think IPv6 will just work well. You have to work for it like everyone else.

What is your IPv6 story?

For questions, bashing or tax filling audits, please e-mail: contact@nephos6.com

Nephos6 Helps Define the IPv6 Forum Security Certification Standards

Excerpt from the IPv6 Forum Press Release:

The IPv6 Forum Launches the IPv6 Education Security Certification Logo Program Accelerating adoption and integration of IPv6 in the Education Curriculum Worldwide


PENANG, MALAYSIA – SAN JOSE, USA – LUXEMBOURG,  May 25, 2012 – The IPv6 Forum Education Logo Program Committee releases a new program: The IPv6 Education Security Certification Logo Program. This program will certify Security Courses, Trainers and Engineers with the Gold Logo level.

In order to be certified, the candidates must cover all mandatory topics outlined in section 3.5 in the requirements specifications document (attached). Only the Gold level of certification is provided by the IPv6 Forum Certified Security program.

“The IPv6 security & privacy are going to be implemented again as an after-thought similar to IPv4 simply due to lack of in-depth knowledge in this area. The IPv6 Forum Security Certification Logo program formalizes a concrete curriculum for everyone to benefit from.” states Latif Ladid, President, IPv6 Forum, Senior Researcher at University of Luxembourg, Security and Trust (SnT) Center.

“Security is top of mind for any decision maker facing the two major inflexion points ahead IT organizations Worldwide: IPv6 transition and Cloud adoption. The IPv6 Forum leverages its global network of IPv6 SMEs to define the educational and expertise standards that will provide the industry with the proven talent needed to successfully tackle the security challenges and opportunities presented by the IPv6 transition.” states Ciprian Popoviciu, CEO, Nephos6. Certified IPv6 Forum Trainer (Gold)

To obtain the IPv6 Security Certification Logo, please visit the following web site andapply by filling out the application form http://www.ipv6forum.com/ipv6_enabled/ipv6_education.php


IPv6 and “Teardrop” Attacks

Way back in 1997, CERT issued an advisory about “Teardrop” attacks (http://www.cert.org/advisories/CA-1997-28.html).  These are attacks where overlapping IP fragments are sent by a malicious actor in an attempt to either A) gain access to a protected system by evading IDS, firewall, and/or platform-based defenses, or B) disrupt the capabilities of the target environment – ideally in several parts of the network but especially the target node (the destination IP interface) itself.

In the 1997 CERT advisory, I am sure the concern was IPv4 systems.  In brief, CERT’s advice was to contact vendors for a solution, and that solution was almost always to upgrade the platform OS version – it seemed the vendors were able to patch implementations.  Presumably, this was done by discarding fragments associated with a Teardrop attack (any set of fragments where any two overlap).  Juniper, for example, added a user configurable switch on platforms to explicitly drop overlapping fragments.

Any node sending overlapping fragments make no sense at all, from a protocol standpoint.  Yet my understanding is that some old IP stacks did sometimes send overlapping fragments, not as an attack but as a result of a sloppy or buggy IP implementation.  Thus, in an effort to promote interoperability with these stacks, other vendors would accept overlapping fragments.  This philosophy goes all the way back to Jon Postel who said “be conservative in what you do, be liberal in what you accept from others”.

On the downside, this flexibility provided an exploitable vulnerability to malicious actors. Mostly, the attack was more directed at OS platform bugs than the IP stack.  Modern platforms for the most part have implementations hardened against Teardrop-style attacks on IPv4 or IPv6.

And while it is true that the IETF IPv6 specification (RFC 2460) does not explicitly prohibit overlapping fragments, most vendors implemented protections against those IPv6 fragments as a matter of best practice.  Later (December 2009) RFC 5722 made it out-of-spec for source nodes to send overlapping fragments, and made it required for the reassembling node (the ultimate destination) to silently discard all fragments associated with a fragmented packet when any two fragments overlap.  Fragments are silently discarded, as opposed to having the reassembling node send ICMPv6 error messages, to guard against reflection attacks (where the attacker uses a victim IPv6 address as the source of the offending packets), and because the sending node is already acting “fishy”, so best not to burden any system (including the originator) with processing ICMPv6 error messages.

There is also the issue of fragmentation attacks against “atomic fragments”.  These are IPv6 packets that are not actually fragmented, but carry the IPv6 Fragmentation Extension Header (with “Fragment Offset” set to zero and the “M” bit not set).  The reason for these to be allowed in the IPv6 specification is to support certain IPv6-to-IPv4 translation solutions.  To protect the capability from exploitation, there is an IETF draft (“Processing of IPv6 “Atomic” Fragments”) discussing ways to defend against fragmentation-centric attacks on this kind of packet.

With the improvements made to stack implementations over time (in the case of IPv4), and the fact that most IPv6 implementations were always “tighter”, the Teardrop attack has become a spent force on the Internet – really only affecting older platforms.  Thanks to RFC 5722, there is now official IETF guidance on how IPv6 stacks should be implemented in terms of handling overlapping fragments, and giving platform vendors the green light to discard these corrupted fragments aggressively.

It is a classic example of the “arms race” nature of IP security – whether for IPv4 or IPv6.  The bad guys discover a new vulnerability and an exploit, and the good guys close it off and harden everything else related to the vulnerability they can think of.   A good reminder that IPv6 security is only “better” than IPv4 security in a few ways, and secure environments really depend on rigorous deployment of security best practices and constant vigilance by an informed and talented security team.