Given the insecurity of WEP and the authentication system built upon it, a more robust privacy and authentication mechanism is needed. There are at least two good systems, both of which I have used. Note that I do not have facilities to snoop on the actual data packets as they fly across the air, so this is a description of steps which I expect to provide the desired authentication (both of the access point and the client) and privacy.
A good overview describing encrypting network traffic is available. It's somewhat dated, presently showing a date of October 2000.
CIPE uses a shared key which is used to exchange working keys. As each end needs the key, this also provides authentication, in that only users with the key can make an effective connection. The encrypted channel across the wireless link uses UDP protocol. There is no official port allocated, so I chose 501, one above the standard IPSEC UDP port. Both ends need to agree upon this!
There is a simple configuration file at each end, and I found it really easy to get this up and running.
IPSEC uses public/private keys for key exchange; the exchanged keys are for encrypting traffic on the link, and are changed at regular intervals, thus requiring that snoopers break the encryption regularly. And since each end needs the public key of the other, there is also authentication of the other end.
The wireless network is essentially a DMZ all on its own. This allows a firewall to be established on the eth0 interface. The firewall rules are quite simple - allow IPSEC (or CIPE) traffic in! CIPE uses a UDP port which you can select; IPSEC uses two protocols (ah, esp) and UDP port 500. I also allow DHCP requests, and currently DNS. The need for DNS is not obvious, but is probably benign. DHCP is currently out of use, as IPSEC and DHCP do not play well together - at least until I figure out how to route DHCP traffic to the wireless net around the IPSEC channel.
DHCP causes problems for both methods. The FreeS/WAN problem is a routing one on the server. Specifically, the client asks for an address, but the reply will attempt to go over the IPSEC channel. I believe this can be worked around, but have not done so yet. For now, the solution is static addresses on the client.
The ultimate decision was to use IPSEC for the link. Either method appears to be acceptable, but IPSEC does more of the route fixing steps when started up. And secondly, IPSEC on the client means I can establish an IPSEC channel to my network when travelling, as the code is already in the kernel.
Making DHCP and IPSEC operate together is a little tricky, and is described in detail on the DHCP and IPSEC page.
Getting Serious
Sundry Other Stuff