Encrypting the Local Network
When the user starts a web browser, and requests a hostname through the DNS server, the hotspot redirects this request to itself. The client is then presented with an SSL-protected login page for the AP. After passing the credentials, the hotspot stops redirecting packets for this user. We then also want to start encrypting all traffic from this user's laptop to the AP, where we then decrypt it and send it further on. When the user runs out of time (or money), we enable the redirect again, and start from scratch.
It is important that any DNS server used is rate limited, to prevent clever hackers from not paying and setting up a TCP-OVER-DNS network with software such as NSTX.
Now we need to combine all these design goals and choices into a functional design.
WaveSEC
Now that we know the goals we want to accomplish, we can look at the design and see how to implement our goals.
240
Chapter 10
This diagram shows the result of an established WaveSEC connection. The client machine has an IPsec connection with the WaveSEC server. This WaveSEC server is located behind the wireless segment, on a trusted wired segment. The client encrypts its traffic and sends it over the wireless to the WaveSEC server where the traffic is decrypted, and sent it on further.
Note that the WaveSEC server here is in the direct path of all the packets. It has become a critical part of the infrastructure. This mode is the easiest to set up, and is called inline mode. This is usually the setup employed when the wireless network is on private IP space that needs to be NATed.
The WaveSEC setup in this figure shows appendix mode. It works the same as inline mode, except that the WaveSEC server is now a purely optional network component. Appendix mode has the advantage that WaveSEC does not become a part of the critical infrastructure. If the WaveSEC server dies in appendix mode, people can still use the network, though of course without the added security provided by WaveSEC. We have successfully run WaveSEC in appendix mode at various IETF conferences.
Appendix mode however, is slightly harder to set up and get working properly, especially when the wireless is on routable public IP addresses and no NAT is present in the network. In such a case, packets from the client to the Internet will be properly tunneled, but packets on the way back
241
Encrypting the Local Network
from the Internet to the client will not realize they are supposed to be encrypted. The routing will not properly route the packets through the WaveSEC server. Only traffic that is destined outside the LAN will be encrypted. If you want to make things easy, you can put all the functionality of the WaveSEC server on a single machine that also acts as the default gateway of the network, using inline mode.
WaveSEC needs support on both the client and server side. Since not all clients can easily support WaveSEC, we have created a somewhat different approach for those operating systems that cannot support WaveSEC natively. When clients have full support, we call it Full WaveSEC. Clients that do not support WaveSEC can run something we dubbed WaveSEC for Windows.
Full WaveSEC
First, when a new client appears in the network, it performs a normal DHCP discovery on the network. The DHCP server sends back a DHCP offer that, apart from the IP address it is offering, contains a special X-WaveSEC-Server= option to inform the DHCP client that this network supports WaveSEC, and on which IP address the WaveSEC server can be found. The DHCP server then waits for the DHCP client to confirm the offer with a request for the offered IP address. The DHCP client then sends this request for the offered IP address, and it if supports WaveSEC, it will include its own public key as part of that request. The DHCP server then confirms the offer.
In a standard DHCP exchange, this is the end of the DHCP protocol, but when WaveSEC is supported by the DHCP server, it performs one extra task. It sends a dynamic DNS update for a TXT record of the reverse zone of the IP address it just assigned to the client to the DNS server. The TXT record contains the public key that the DHCP client has sent to the DHCP server. The DNS server acknowledges the update to the DHCP server.
242