Search This Blog

Tuesday, December 11, 2007

Microsoft Vista's IPv6 Raises New Security Concerns:

Members of the Internet engineering community have raised several new security concerns about Teredo, a mechanism for sending IPv6 traffic over IPv4 networks that comes turned on by default in Microsoft's Vista software.

Symantec and Ericsson security experts who called attention to the issue say they are concerned that Teredo bypasses network security through such devices as firewalls. Microsoft officials could not be reached for comment.

IPv6 is a long-anticipated upgrade to IPv4, the Internet's primary communications protocol.
IPv6 fixes the lack of IP addresses found in IPv4. IPv6 has a virtually unlimited number of IP addresses, while IPv4 has 4.3 billion IP addresses, the majority of which have been handed out.

Teredo is a tunneling technique used to send IPv6 traffic through IPv4 network address translators (NAT). Because of the lack of IPv4 addresses, NATs are commonly used in enterprise networks to mask many private IPv4 addresses behind a single public IPv4 address.

With Teredo, IPv6 packets are sent as IPv4-based User Datagram Protocol messages to go through IPv4 NATs. Teredo provides IPv6 traffic with address assignment and host-to-host automatic tunneling. A network using Teredo requires Teredo clients, Teredo host-specific relays, Teredo servers and Teredo relays.

Teredo is enabled by default in Windows Vista, but it won't be enabled by default in Windows Server Code Name 2008, according to Microsoft.
In a 20-page document titled "Teredo Security Concerns," James Hoagland of Symantec and Suresh Krishnan of Ericsson, outline several new security concerns about running Teredo in managed, corporate network environments. The document is the result of an independent analysis of Teredo's security implications that was conducted by Symantec.

"Teredo is not recommended as a solution for managed networks," the document states. "Administrators of such networks may wish to filter all Teredo traffic at the boundaries of their networks. . . . The easiest mechanism for this would be to filter out incoming traffic with Source Port 3544 and outgoing traffic with Destination Port 3544."

The Hoagland/Krishnan document was discussed at a meeting of the IETF's IPv6 Operations Working Group held here this week. It is in draft form and has not been approved yet by the group.
Because of the new security concerns about Teredo, the authors recommend that network managers turn off Teredo. "Security administrators should disable Teredo functionality unless their network-based security controls adequately recognize the tunneled traffic," the document says. The IETF previously cited security concerns about Teredo in the original Teredo RFC 4380, which was published by the IETF in February 2006.

The Symantec and Ericsson engineers now write: "IPv6 traffic tunneled with Teredo will not receive the intended level of inspection or policy application by network-based security devices, unless the devices are specifically Teredo-aware and capable.This reduces defense in depth and may cause some security gaps. This applies to all network-located devices and to end-host based firewalls whose hooking mechanisms would not show them the IP packet stream after the Teredo client does decapsulation."

The authors say that vendors of firewalls, intrusion-detection systems, intrusion-prevention systems and routers must add support for the Teredo protocol to ensure they can inspect Teredo packets. A network device that's unaware of Teredo will inspect only the IPv4 layer of a Teredo packet but won't recognize there is an IPv6 packet hidden inside to inspect or to apply a security policy.

Another concern of the authors is that the Teredo tunnel is open-ended and supports bidirectional traffic. To make sure networks are secure when sending IPv6 traffic via Teredo, network managers need to bolster the security of client hosts sending Teredo traffic. "One implication of the security control bypass is that defense-in-depth has been reduced, perhaps down to zero unless a local firewall is in use," the authors say. "However, even if there are host-based security controls that recognize Teredo, security administrators may not have configured them with full security-control parity even if all the controls that were maintained by the network are available on the host. Thus there may be some gaps in desired coverage."

Yet another problem is that network managers may not be aware that some of their hosts are using IPv6 through Vista and are now globally addressable. "Unlike what would be the case for native IPv6, some network administrators will not even be aware that their hosts are globally addressable," the authors say. They add that "it may not be efficient to find all Teredo traffic for network devices to examine."

The document lists the following additional security problems with Teredo and offers these recommendations:
-- Teredo bypasses inbound-destination-address and outbound-source-address filtering unless "extraordinary" measures are taken. In this situation, either routers or clients need to be upgraded to handle this filtering for Teredo-tunneled IPv6 addresses.
-- Teredo clients may forward IPv6 packets to another destination, thereby bypassing network-based source-routing controls. One solution is to have Teredo clients by default discard IPv6 packets that specify additional routing.
-- No mechanism exists to filter all Teredo packets efficiently or immediately. One suggestion is for network administrators to block all Teredo use.
-- There's no efficient mechanism for deep packet-inspection of Teredo traffic as there is for native IPv6 traffic. This is one reason the authors do not recommend Teredo as a transition mechanism for network administrators who want to monitor IPv6 traffic.
-- The opening created in a NAT device by Teredo can be used by network attackers. The recommendation here is to minimize Teredo use.
-- It may be easier for network attackers to guess Teredo addresses because these addresses reveal some information about the corresponding clients. The document suggests randomizing the server settings or Teredo client ports in use to alleviate this concern.

Even more alarming to the document's authors is that Teredo's original RFC 4380 specification argues that Teredo improves security for IPv6. "This misleading or inaccurate claim can be taken out of context and used to downplay Teredo security implications," the new document states.
The Hoagland/Krishnan document does not address the use of Teredo in unmanaged networks.

No comments: