Tag Archive for Internet Engineering Task Force

IPv4 IPocalypse Strikes Europe

IPv4 IPocalypse Strikes EuropeThe IPocalypse has stuck in Europe. RIPE NCC, the Regional Internet Registry (RIR) for Europe, the Middle East, and parts of Central Asia announced on 09-14-12 that it is down to its last “/8” worth of IPv4 addresses. ArsTechnica reports it is no longer possible to get new IPv4 addresses in Europe, the former USSR, or the Middle East, with one small exception: every network operator that is a “RIPE member” or “local Internet registry” (LIR) can get one last block of 1024 IPv4 addresses. To fulfill these requests, the RIPE NCC is keeping that last /8, which has 16.8 million addresses, in reserve.

None of this comes as a surprise, according to the author, given that global IPv4 IPocalypse struck when the global pool of free IPv4 addresses dried up in February 2011. APNIC, which distributes IP addresses in the Asia-Pacific region, ran out of IPv4 addresses in May 2011. The remaining three Regional Internet Registries are AfriNIC (Africa), LACNIC (Latin America and the Caribbean), and ARIN (North America), which all have enough IPv4 addresses to last at least two more years.

Since the depletion of IPv4 address space in the APNIC region, little information has surfaced about how network operators in the region have managed the situation. The article states, the lack of IPv4 addresses only impacts organizations and consumers who need more addresses, or who need addresses for the first time. Existing IPv4 users remain unaffected by the global IPocalypse, and so the immediate impact is limited. Also, large network operators get large address blocks from the RIRs and they typically have a pool of unused addresses of their own, so few will be experiencing immediate problems.

Every year for the past five years, some 200 million new IPv4 addresses have been put into use. Ars cautions, without a steady supply of fresh addresses, many Internet-related activities are going to become problematic in the years to come. Fortunately, 20 years ago the Internet Engineering Task Force (IETF) foresaw the IPv4 IPocalypse, where the 3.7 billion 32-bit IPv4 addresses would run out, would become a problem, and started working on a replacement: IPv6. However, the IPv4 depletion didn’t happen as fast as the IETF originally predicted, and IPv6 adoption has languished.

rb-

So IPv6 adoption got a big kick in the implementation from World IPv6 Launch. Eventually, IPv6 will replace IPv4, but the transition won’t be pretty. I have covered some of the IPv6 issues here, here, and here. Give it some time, Europe and the rest of us will survive the IPv4 IPocalypse.

Related articles

Ralph Bach has been in IT long enough to know better and has blogged from his Bach Seat about IT, careers, and anything else that catches his attention since 2005. You can follow him on LinkedInFacebook, and Twitter. Email the Bach Seat here.

Security Considerations for IPv6

Security Considerations for IPv6For those who missed the Internet Society (ISOC) announcement that World IPv6 Launch day arrived on June 6. (I blogged about World IPv6 day, back in March) Carl Herberger, VP of Security at Radware (RDWR) recently wrote at Help Net Security that he sees World IPv6 Launch day as much more hype than an operational change.

Internet Society logoMany high-profile organizations have hooked their plans on change over to the ISOC launch date. Supporters include Google (GOOG), Facebook (FB), Microsoft (MSFT) Bing, Yahoo (YHOO), and Akamai (AKAM).  Mr. Herberger points out that many companies have already leveraged IPv6 WAN connectivity. Most mobile providers who have adopted LTE 4G infrastructures have built them for mobile devices, Mobile devices will connect to the Internet with IPv6 addresses by default. He argues that since a 4G phone must also be 3G and IPv4 compatible, the 5G providers have not done much. The service providers have woven IPv6 into the existing IPv4 Internet much to the chagrin of the initial IPv6 designers.

IPv6 Pandora’s Box

Bottom line: Because IPv4 is not going away any time soon, we will essentially live in perpetuity with both designs. A new dawn? Or the beginning of the end? The Radware VP thinks it’s neither, he calls the interoperability issues between IPv4 and IPv6, a Pandora’s Box of opportunity for those of the nefarious persuasion.

So, what are the three main takeaways from World IPv6 Launch day?

Take away #1

Dog and catIPv6 will first be implemented on the WAN, IPv4 will continue to stay in the LAN for years to come – Google, Facebook, DNS, CDN providers, and many, if not most ISP’s are all moving to default IPv6 WAN connectivity. However, nearly no one has made the transition to IPv6 on the LAN. Mr. Herberger adds that rapid IPv6 deployment on the Internet WAN operations side and the very slow rollout of IPv6 on the LAN side will wreak havoc on perimeter security. He believes that there are huge problems associated with IPv4 and IPv6 cohabitating.

Take away #2

IPv6 & IPv4 don’t cohabitate well – IPv6 and IPv4 make insecure bedfellows. There are no predefined standards in the way to handle the cohabitation of IPv4 with IPv6.  The transition mechanisms to ease the transitioning of the Internet from its first IPv4 infrastructure to IPv6 have not been standardized yet. The Internet Engineering Task Force (IETF) has working groups and discussions through the IETF Internet-Drafts and Requests for Comments processes to develop these methods. Some basic IPv6 transition mechanisms have been defined; however, nothing has yet emerged as a proposed uniform standard. As such, the article states, the world is awash with a plethora of IPv4 to IPv6 (and vice versa) Transition Mechanisms such as:

  • Encapsulating IPv4 in IPv6 (or 4in6)
  • Encapsulating IPv6 in IPv4 (or 6in4)IPv6 tunnel
  • IPv6 over IPv4 (6over4)
  • DS-Lite
  • 6rd
  • 6to4
  • ISATAP
  • NAT64 / DNS64
  • Teredo
  • SIIT.

If you are familiar with network perimeter security devices, one of the things they do well is deep packet inspection and Stateful aware analysis. However, one of the dirty little secrets is that nearly none of today’s technologies have the capability to inspect encrypted traffic such as SSL  or the ability to inspect tunneling protocols such as L2TP, PPTP, etc. What IPv4 and IPv6 transition does is effectively exacerbate these “Achilles heels” in security detection capabilities by introducing a whole new class of nearly undetectable transmissions. The author warns Don’t be fooled by a vendor’s claim that they inspect a v4 packet in v6 or vice versa, because even if true for one or two methodologies, the ways to carry out this task are almost immeasurable today. This is really a true community-wide problem and one that must be addressed.

Take away #3

ConfusedMeet your old vulnerability – Same as the new vulnerability! Much of our defense is single-threaded, and should an adversary be able to pass through your perimeter defenses, many of the ‘older’ vulnerabilities would find a receptive home having passed through the ‘corporate scrubbers.’Moreover, just think of the new opportunities available to more nefarious organizations that don’t have your interests in mind. This ‘transition mechanism’ essentially becomes an effective ‘unscrubbed’ gateway or tunnel for all newly developed organized crime-designed, state-sponsored, and Hacktivist-motivated attacks.

Moreover, most of us will be largely blind to these realities unless we are acting now to make certain that our gateways are designed with all encapsulated traffic being detected and mitigated. Anomaly detection takes center stage here and signature tools will leave you wanting.

The Radware VP concludes that this problem requires action on behalf of security professionals to solve; you HAVE to do something different because the inertia path will leave you vulnerable.

Related articles

Ralph Bach has been in IT long enough to know better and has blogged from his Bach Seat about IT, careers, and anything else that catches his attention since 2005. You can follow him on LinkedInFacebook, and Twitter. Email the Bach Seat here.