A few months ago, I wrote an article about Windows Vista's ability to form ad hoc networks using the IPv6 protocol. Since that time, I have received a considerable amount of email from readers who are concerned about the implications of these capabilities. In this article, I want to put some of those fears to rest by discussing the security mechanisms that safeguard these connections.
The first thing you need to understand about ad hoc networks is that they are nothing new. I bought my first set of wireless networking hardware back in 2000. Even then, the wireless NIC driver gave users the option of either connecting to a wireless access point or forming an ad hoc network.
Ad hoc risks
Of course ad hoc networks are not without risks. Probably the biggest risk associated with ad hoc networking has always been electronic eavesdropping. Traditionally, ad hoc connections have lacked the various encryption mechanisms that are typically used with wireless access points, such as WEP and WPA.
Another risk of ad hoc networks is that someone could connect to the network without your knowledge or consent and access files off your computer or another network to which your computer is connected.
Wireless security the Windows way
Microsoft has attempted to mitigate these various risks in Windows Vista by standardizing the way that ad hoc networks are formed. Standardizing ad hoc networks accomplishes two things. First, it makes it much easier for users to form ad hoc networks, because there is now an application specifically dedicated to that purpose. Second, security is increased because the ad hoc network is functioning within the confines of an individual application.
In Windows Vista, this application is known as Windows Collaboration. Windows Collaboration has many different built-in security mechanisms. The first layer of defense is the IPv6 protocol. In case you aren't familiar with the IPv6 protocol, it is the successor to the IPv4 protocol that is used for most TCP/IP communications today.
The IPv6 protocol is an absolute requirement for the Windows Collaboration application, owing primarily to the fact that IPv6 overcomes some of the logistical issues involved in forming an ad hoc network. Normally, when a computer accesses another network host (whether on the local network or on the Internet), the computer must resolve the remote host's name to an IP address. To do so, the computer performs a DNS query. The problem with an ad hoc network is that there is no DNS server configured with the names and IP addresses of the network participants.
Another issue with ad hoc networking is that of IP addresses. In an IPv4 network, hosts on an ad hoc network must all have IP addresses that fall within a common subnet. Unless the ad hoc network contains a DHCP server, the chances of all of the hosts using the same IP address range are slim.
IPv6 solves these problems by allowing the person who initially established the ad hoc network to transmit a multicast message to everyone on the ad hoc network notifying them of the service's availability. If nobody else has yet connected to the ad hoc network, then nobody will receive this multicast message. That being the case, it is possible for hosts running Windows Vista to run a probe that scans a scope for a set of services. This allows hosts to discover ad hoc networks without the presence of DHCP or DNS servers.
Those are the logistical reasons why Microsoft chose to use the IPv6 protocol for ad hoc networks -- but what about security? The Microsoft implementation of IPv6 is designed to support IPsec encryption and IKE by default.
Microsoft has implemented other security mechanisms with Windows Collaboration as well. For example, the file sharing and Windows firewall exception rules required for using Windows Collaboration are disabled by default. Unless a user specifically chooses to enable file sharing and firewall exception rules, there is no danger of someone establishing a Windows Collaboration session with that PC.
Other safeguards
When a user establishes an ad hoc connection, other safeguards are in place as well. The first safeguard is a session password, as shown in Figure A. Nobody can connect to the ad hoc session without the password.
Figure A
Ad hoc sessions are password protected.
Another safeguard is that you have the option of hiding a session. Normally, when users open Windows Collaboration, they will see a screen similar to the one shown in Figure B. As you can see in the figure, this screen displays all the detected ad hoc sessions. To join an ad hoc network, a user must simply click on the network and enter the session password.
Figure B
By default, Windows Collaboration displays all of the ad hoc sessions that are currently running.
The problem with this is that ad hoc sessions are typically formed using a Wi-Fi connection in a public area. You may not want other people who are using the Wi-Fi network to know about your ad hoc network. In that type of situation, it is possible to hide the ad hoc session from view, as shown in Figure C.
Figure C
It is possible to hide an ad hoc session from public view.
You might be wondering how the people in your group can connect to a session if it is hidden from view. Windows Collaboration is designed to detect anybody who has Windows Collaboration open, even if they are not in a session (this is performed using an IPv6 probe such as the one I discussed earlier). This probe compiles a list of the people who are using Windows Collaboration. You can then send invitations to the people you want to include in the session, as shown in Figure D.
Figure D
You can send an invitation to specific people, allowing them to join an ad hoc session.
Conclusion
Unfortunately, ad hoc networking in Windows Vista is not completely secure. For example, there is nothing stopping someone from configuring Windows Collaboration to use a name other than his own in an effort to trick someone into sending him an invitation that was intended for someone else. Even so, I think that Windows Vista offers a huge improvement over what was previously available, both in terms of security and usability.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at www.brienposey.com.
