Opportunistic Encryption of IP traffic: FreeS/WAN 2.0

Russ Nelson writes "Since 1996, John Gilmore has dreamed of an Internet where all traffic between cooperating sites is encrypted. He has supported the FreeS/WAN project which uses IPSEC to encrypt IP traffic on an opportunistic encrypting basis. The team has released Linux FreeS/WAN 2.00, their first release optimized for Opportunistic Encryption (OE). After installation, ZERO host configuration is required for OE! A Linux box running 2.00 will encrypt all IP packets to other OE capable boxes whenever possible, provided you publish a key and IPsec gateway information in DNS." Nice.

Comments

Re:Wireless applications?

[kmcmartin]

This is a very useful application of IPsec. The wavesec project is an example of using IPsec to secure the link between a client and the wireless access point.

This was in-practice last year at OLS where the FreeS/WAN folks set up a wavesec encrypted link, while the folks that were not using wavesec had their traffic snooped and displayed on a monitor.

The problem with using IPsec as a replacement for WEP, however, is that IPsec is higher up on the OSI layer diagram, so more information is left unencrypted than when using WEP (yes, I'm aware that WEP is weak and in this case, won't make a difference, I'm just illustrating a point.)

Re:Weakest link

[Klaruz]

Determine the best form of opportunism your system can support.

* For full opportunism, you'll need a static IP and and either control over your reverse DNS or an ISP that can add the required TXT + KEY Records for you.
* If you have a dynamic IP, and/or write access to forward DNS only, you can do initiate-only opportunism
* To protect traffic bound for real IPs behind your gateway, use this form of full opportunism.

So you'd only be able to use initiate-only opportunism. Oh well, still sucks.

KEY record debate...

[pabl0]

One potential problem with this is that KEY records were originally intended for DNSsec usage and some controversy has arisen with regard to using KEY records for other purposes, such as OE. This pretty much sums it up, however, and it seems as though they've gone on using KEY for this purpose.

(I realize the articles listed are 8-9 months old, but clearly the issue is still relevant.)

I'm unfortunately not running OE, as my DNS provider (UltraDNS) did not provide the capability to add KEY records to a zone at the time I went through the installation process. Not sure if they do so now; perhaps time to check! I'd be interested in discovering which DNS providers do or do not provide the ability to insert KEY records into zones.

Re:Weakest link

[velkro]

Yes, DNS is currently the weakest link.

DNSSec will fix most of this, however that requires all of the TLD and gTLD's support it. Currently, only .nl will sign records all the way to the root zone. We need more TLD/gTLD buy-in for DNSSec to become commonplace.

--
ken@freeswan.ca

Re:not really

[arvindn]

this uses public-key encryption, which may be an "easy" algorithm but is certainly not secure because given enough clock cycles, the public key can be used to derive the private key.

Aaargh! Please go read up some crypto. There's no sense in anything you said. You are essentially saying that all crypto is pointless.

First, public-key encryption is not an "easy algorithm" in any sense. It is much more computationally expensive than symmetric key encryption. Second, adding just a few bits of key size doubles the computational complexity of brute force key search (for public key encryption; for symmetric encryption, adding just a single bit of key length doubles the complexity.) Currently, we are just able to crack 512 bit keys, but most public key encryption today uses 1024 bit keys, so the time taken to bruteforce it would be of the order of countless bajillions of years. The only widely used encryption algo that the NSA can crack is 56bit DES, and it has already been phased out. Third, all real-world crypto needs to use a mixture of public and symmetric key encryption. The former because it is the only one that allows authentication, and the latter because it is much faster.

I hope that cleared some things up.

OE cannot be used by the majority...

[sweet 'n sour]

Unless you've got a class C or larger ip block to yourself, you probably won't be able to use OE. Dynamic ip addressers need not apply either.

If you've got a static ip block that is smaller than 255 addresses, most ISPs will only let you assign names/keys/other to your ip addresses through classless reverse delegation (RFC 2317 http://www.ietf.cnri.reston.va.us/rfc/rfc2317.txt) .

The problem I ran into was that KEY requests never reached my servers (CNAME, TXT, others worked fine). This made it impossible for other OE enabled systems to communicate with me since my box seemed to be configured to talk OE, yet they could never get my key to begin negotiation.

Another terrible side effect from this was that any OE server I DID try to communicate with would KEEP TRYING to negotiate with me forever until I could get them to shutdown their OE...