Imagine living in the San Francisco Bay Area (some of you may already live there :-)).  You have just arrived at work for the day and started in on your first cup of coffee and the morning’s “urgent” emails.  When all of the sudden a flashing message from the San Francisco Fire Department flashes on your screen instructing you to leave your work area immediately and find safe cover from an impending earthquake.  This message will also give you time to full magnitude and an estimated countdown of strike.

Real-World Feature #2:  IPv6 Multicast Messaging

The good news is that a system just like this exists in Japan carried by Japan’s telecom NTT.  Not surprisingly, the Japan Meteorological Agency (JMA) is utilizing the built-in and streamlined support of IPv6 multicasting.  Currently, the system has over 1,000 sensors deployed that react upon changes in seismic activity along Japan’s earthquake hot-spots.  Included within this system is a server that collects all of the raw data and distributes location, time and warning messages to each of its paying customers.

What makes IPv6 multicast needed in this case?  Because the complicated networking instructions and decisions no longer need to be the responsibility of the software developer.  With IPv6, you get multicast already configured, enabled and operating by default.  All that remains is a few infrastructure configurations to enable globally routable IPv6 multicasting.  Another good news story, because any IPv6 deployment will probably have this built-out on the onset.

For a complete description on Japan’s earthquake monitoring system take a look at the diagram below:

For more on this and other IPv6 uses at NTT go here: http://www.digitalgovernment.com/media/Knowledge-Centers/asset_upload_file338_1748.pdf

What’s next??  Part 3 will discuss “Video content distribution via IPv6 multicast.”

Until later..

Jeremy

  Over the next few months, we plan to articulate the real-world applications of IPv6 right now.  This is not going to be one of those discussions that highlight beautiful IPv6 features stuck in the theoretical and things that don’t actually exist in nature (mandated IPSec, QoS, etc).  We are going to show you what is actually happening in the industry currently and what applications are leveraging IPv6.  Obviously, this is going to help everyone’s business case to drive adoption further along.  Without further ado, the juiciest use of IPv6 today: Microsoft’s Direct Access  Enjoy!

Real-World Feature #1:  IPv6, IPSec and Microsoft’s Direct Access

Direct Access from Microsoft solves the following problems with remote access VPNs, IPv6 and IPSec:

1. VPNs are hard to manage from a client and server side.  Servers need to be maintained by qualified personnel, and clients need to be individually configured with clunky third-party software (ie Cisco VPN client).
2. IPSec in either IPv4 and IPv6 is not at all automated.  Sure there are ways to automate key exchange, but each of those parameters need to be configured (type, encryption key, integrity, lifetime, re-key, etc.)  See the IKEv2 RFC for details on this. The only thing close to this is PKI for the DoD. However, even that has not been integrated with IPSec and IPv6 yet.
3. IPv6 deployment is difficult for some to manage.  In the meantime, there are ways to transition into it.

So given these problems, how does Direct Access solve it?  Direct Access automates the VPN process.  How on earth can it do this anyway?  Well, if you have the soon-to-be released Windows 7 client and a Microsoft Server 2008, Release 2 then it’s all ready to work out of the box.  I am sure open source implementations are soon to follow.  In fact, if anyone in the Blogospere, Twitterverse or Facebookland have any ideas about this, please let me know!

Currently, host to server VPNs don’t really use layer-3 IPSec.  In fact, IPSec is usually sandwiched between the data and a TCP or UDP header.  Not the most efficient use of IPSec.

How does Direct Access work anyway?  Taken from the great folks at Microsoft is a diagram that shows the full session:

1. You boot up the Windows 7 client
2. It begins to configure IPv6.  If it can’t configure a native IPv6 address it wil attempt other mechanisms: 6to4, Teredo, and a new encapsulation technique called IPv6-in-HTTPS.  So native IPv6 is not required.  Word of caution here is the enterprise network should decide on the mechanism to use and not expose the network to others.  The reasoning for this is because there are huge security holes in having these tunneling mechanisms open and not being used and monitored.
3. Once the IPv6 connection is made, the Windows 7 client automatically negotiates the IPv6 IPSec session (either in tunnel or transport mode).  The great thing about this mechanism is that the DoD’s PKI and CAC-enabled system can be integrated very easily!
4. Now the client is a permanent fixture of the local network.  So virus updates to Active Directory policies can be pushed to these remote users just like they were on the local segment.

Take a look at the picture below to get a visual understanding (Courtesy of MS Technet).

“Transforming Your Edge Network with DirectAccess“

References

Here’s a list of further reading on Direct Access and how IPv6 is integrated into it!

• http://technet.microsoft.com/en-us/magazine/2009.05.cableguy.aspx?pr=blog
• http://technet.microsoft.com/en-us/magazine/2008.03.cableguy.aspx
• http://communities.intel.com/community/openportit/server/blog/2009/05/16/ipsec-offload-meet-microsoft-directaccess
• http://www.microsoft.com/windows/enterprise/products/directaccess.aspx

What’s next??  Part 2 will discuss “Global enterprise
instant messaging AKA IPv6 Multicast messaging.”

Until later..

Jeremy

This week Command Information received the IPv6 Forum’s IPv6 Enabled/Ready WWW Logo!  Check out our IPv6 homepage to see it on our site, or take a look at the Validated List here: http://www.ipv6forum.com/ipv6_enabled/approval_list.php

From the IPv6 Forum, the purpose of the program is to “accelerate deployment of IPv6…” and to “increase user confidence by demonstrating that IPv6 is available now and is ready to be used.”

 Vint Cerf even stated that “This program is a good step in the right direction. IPv6 needs to be integrated in all web sites.”

For some time, Command information has stated that the first step in transition for any network is to migrate the publicly facing services first!  By participating in this program, you are doing just that.  Good work IPv6 Forum!

 US Office of Management and Budget (OMB) released the Federal CIO council’s “Planning Guide / Roadmap Toward IPv6 Adoption in the U.S. Government” to  defines the US Federal Government’s policy to move from OMB 5-22 “IPv6-ready” state to an “IPv6-enabled” state. This document defines how to fit IPv6 transition into agencies IT investment plans and defines a minimum set of goals and critical timelines for IPv6 enablement.

US Whitehouse new CyberSecurity Review PDF Document and near-term action plan to secure national infrastructure -  especially power grid controls, emergency response, and other critical systems. Nothing IPv6 specific is mentioned here – more “Cyberspace” security on Internet systems.

Internet Numbering Resource Organization (NRO) governing body, formed by the Regional Internet Registries to formalize their co-operative efforts  to protect the unallocated IPv4 Number Resource pool, responds to European Union Telecommunications Standards Bureau with their  ‘Questionnaire on IPv6 Address Allocation and Encouraging the Deployment of IPv6’ [PDF] with  information on IPv4 address depletion, the slow rate of IPv6 adoption, the barriers to IPv6 adoption, and suggestions on policy to help mitigate the risks of slow adoption.

http://www.ipv6actnow.org   European Regional Internet Registry RIPE (www.ripe.net) has launched “IPv6 Act Now,” a website explaining the new Internet protocol in terms everyone can understand, and urging all organizations to adopt IPv6, which is integral to the future growth and operations of the Internet. IPv6 has only grown  2.4 to 4 percent in 2008, and the continued slow growth will result in a lack of Internet growth space as IPv4 address space will run before IPv6 is fully adopted.

American Registry for Internet Numbers (ARIN) releases a set of comic books to attempt to educate the public about the IPv4 address exhaustion problems and help get IPv6 adoption in gear. ARIN uses the comics to illustrate the FUD (Fear Uncertainty and Doubt) that may be limiting IPv6 adoption.

International Telecommunication Union (ITU) has just launched an IPv6 website to provide information about global activities related to IPv6 so as to raise awareness of IPv6 deployment, as well as provide information on training events being undertaken by organizations in the Internet community.  ITU Member States and Sector Members reached consensus and adopted Resolution 64 [PDF Link] ‘IP address allocation and encouraging the deployment of IPv6’ to promote awareness of the availability of IPv4 addresses and the deployment of IPv6.

All of Google’s services now available over IPv6. Google engineers say it was not expensive and required only a small team of developers to enable all of the company’s applications to support IPv6. 

Snort Intrusion detection system (IDS) v2.8.5 mainstreams the Snort beta support for preventing IPv6-borne attacks and enhanced NetBIOS traffic inspection.  Snort Beta 3.0, which was to include IPv6 support and other improvements, continues in development but the ability to detect IPv6-borne attacks has been added to the current version.

http://www.networkworld.com/community/node/37947 Direct Access in Microsoft Windows 7 is a system that is uses IPv6 over IPSec so system administrators can help maintain remote workforce and teleworker computers while they are on the go. Additionally, the privacy addressing feature which randomizes addresses to prevent tracking and ID of individual computers can be turned on and off by system administrators. Windows 7 is still lacking advanced IPv6 protocol support for Mobile IPv6 (MIPv6) Mobile Node (MN) functions and Microsoft’s own Secure Neighbor Discovery (SEND) .

    Last time, I discussed some of the issues related to DHCPv6 implementation differences.  However, is DHCPv6 even any more secure?

Issue# 2: Security issues for DHCPv6 and Stateless Address Configuration

Conventional wisdom will tell us it is.  When issuing addresses we have reasonable confidence that the node requesting the address is authorized.  This is a correct assumption only if you can properly authenticate them.  DHCPv6 has many of the same vulnerabilities as stateless configuration:

(1) Man-in-the-middle attacks where a rouge server stands up to reroute you elsewhere.

(2) Denial of Service where attackers stop all nodes on a network from communicating completely.

(3) Neighbor Solicitation/Advertisement spoofing.  This affects both because all nodes are still required to participate in Duplicate Address Detection (DAD) regardless of address procurement.

As I said, this happens in both situations.  However, there are some DHCPv6 standards out in the industry.  Most of these mechanisms use authentication built into IPv6 called IPSec and Cryptographically Generated Addresses (CGA).  This standard is currently in draft.

However, these are very similar to Secure Neighbor Discover with Cryptographically Generated Addresses (SeND with CGA).  RFC 3971,describes how this should work in current networks.  The disadvantage to this approach is that there is very little supported implementations due to a few ongoing patent negotiations.

Another security mechanism used in stateless address configuration is the use of privacy extensions.  RFC 3041, IPv6 Privacy Extensions are implemented in most host platforms: Windows Vista and all Linux and Unix platforms.  However, most Linux implementations do not have this module enabled by default.  Current address configuration is done using known fields in the MAC address.  Implementing privacy extensions means reconfiguring the global-unicast addresses periodically with randomizing bits.  This process keeps any attacker or malicious probe on a network guessing.

To recap:

DHCPv6 can be secure if IPSec authentication using CGA is implemented and hosts in the network are at least Windows Vista and Linux 2.6.18 and higher with the current dhcp6c module/utility.

Stateless Address Configuration can be secure if Secure Neighbor Discovery (SeND) and CGA is used.  It must also be combined with the use of IPv6 Privacy Extensions.

More to follow…

010100110110010101101101011100000110010101110010001000000100011001101001

Jeremy Duncan

Since my initiation into the world of IPv6 in 2004, it seemed that a religious war of address management was brewing.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) and Stateless Address Autoconfiguration (RFC 4862) became an issue of security, address management and scalable nodal allocations.  Really, what is the big issue?  In this blog (and later blog entries) I want to try to address each issue’s pro/con and hopefully discuss any myths behind each of the issues of automatic address issuance.

Issue #1: Why is DHCPv6 implemented differently in multiple operating systems?

This issue is quite a fascinating one in the industry.  DHCP in IPv4 worked simply as a server on a network segment issuing IPv4 addresses to hosts that solicit to the broadcast (255.255.255.255).  However, in IPv6 it is implemented quite a bit differently.  The crux of the debate goes into how multiple IETF RFCs are translated.

M&O Camp:  the newer Stateless Address Autoconfiguration standard (RFC 4862) discussed the use of the Managed and Other Configuration flags in Router Advertisements for “DHCPv6 configurations” to instruct a client on the network that there are DHCPv6 servers on the network.  Therefore, a client will know to solicit for DHCPv6 servers.  Otherwise, they will only accept address prefixes issued by routers on the network.  They will then configure their own host identifiers.

Pro: secure address management, current support in Microsoft Vista clients

Con: must implement both solutions, unknown which clients support this approach, inflexible

Server-only camp: In the older address configuration (RFC 2462), the language used for DHCPv6 was a little more vague by using the term “stateful address configuration.”  Many operating system distributions in the Linux and Unix world implement DHCPv6 clients very similar to the way they did in IPv4.  The client will send out a request on the network using multicast (unlike in broadcast for DHCPv4) for any servers on the network.  It will also listen for Router Advertisements and continue to do stateless configuration.  However, the DHCPv6 address will be promoted to the primary address.

Pro: Flexible, easily integrated and understood by network operators, support in Linux/Unix systems

Con: No support in Microsoft Vista exists, not as secure to manage nodes on the network

More on the automatic address configuration debate to follow…

I’m often asked what’s the latest news on in the US Government’s IPv6 programs since they are the driving force behind preparing US telecommunications infrastructure for the coming IPv4-to-IPv6 changeover. Since we know that the IPv4-based Internet will be having tremendous scaling problems by 2012, it’s an Internet continuity of operations and cybersecurity issue to keep IPv6 transition moving forward in a timely manner. Here are some of the key US Federal Government events from the last few months that are continuing to move the transition forward: 

• Federal Acquisitions Rule (FAR) Mod 2005-41 is in final form and will (hopefully) be signed VERY SOON and should be in effect in FY 2010 requiring ALL US Federal IT acquisitions to be IPv6-capable
• September 2008, NIST published A Profile for IPv6 in the U.S. Government Version 1.0 (Now they are launching a testing program)
• NIST IPv6 lab accreditation and testing program will hold a meeting in May and will HOPEFULLY go into operation immediately after see Special Publication 500-273, “IPv6 Test Methods: General Description and Validation.

• The Federal CIO Council is producing a suite of guidance documents via the Federal Enterprise Architecture PMO to guide to guide Federal IPv6 transitions. One of the key documents that many of us worked on under the leadership of Pete Tseronis is currently in final draft and should be signed and released IMMINENTLY. The “Business_Case_&_Roadmap_for_Completing_IPv6_Adoption in the US Government” document contains information on:

  • -Critical timelines and steps for upgrading Internet architecture and applications to IPv6 to avoid IPv4 scaling issues
  • -Coordinating IPv6 initiatives with the IT infrastructure Line of Business (ITILOB
  • -Utilizing the IT Infrastructure and Information Sharing Segment Architectures to define a “to-be” IPv6 environmen
  • -Reinforcing how EA and Enterprise Transition Plans drive IPv6 Exhibit 300 development
• Multiple DoD IPv6 pilot exercises are taking place in 2009 (Joint Services JUICE exercise, Air Force pilot at Eglin AFB, Army C4ISR OTM, etc)
• The DoD is issuing more detailed and actionable IPv6 procurement guidance to help program managers and network operators understand how to procure and fully implement IPv6 networks, applications, and communications systems
• The DoD and Intelligence community are coordinating security guidance to implement IPv6 networks between operational enclaves
• DoD’s successful IPv6 product testing program at JITC has been shut down, and the IPv6 testing is being transferred to be covered under DoD’s Unified Capabilities Requirements testing. See http://jitc.fhu.disa.mil/apl/dsn.html for information concerning UCR requirements and application procedures.