Slashdot Mirror
Crypto and IPSec Merged into 2.5
Corbet writes "Linus has just merged the new crypto API and IPSec implementation into his 2.5 BitKeeper tree. This is the first time that serious cryptographic code has made an appearance in the mainline kernel, and it will hopefully lead to more secure communications for all Linux users in the future."
somewhat, but from what I read bout a week and a half ago... the ipsec impmentation that they are putting in does not yet support ipv4 transport.... ie is useless unless you have hosts fully using ipv6 on both sides of the tunnel. Keep in mind, its not frees/wan, its from the linux ipv6 project.
With the atitude that the frees/wan project maintains, we will never see freeswan merged with mainstream kernel... hell... they still refuse to take patches from us citiziens and residents (that includes linus)
Also in 740.13, to, in part, take into account the "open source" approach to software development, unrestricted encryption source code not subject to an express agreement for the payment of a licensing fee or royalty for commercial production or sale of any product developed using the source code can, without review, be released from "EI" controls and exported and reexported under License Exception TSU.
Jon.
I'll stick with FreeBSD thanks. And then there's OpenBSD and NetBSD for fully implemented IPSec and IPv6.
FreeSWAN barely talks to anything but itself, yet I can get FreeBSD's IPSec to talk to Cisco routers and do other things. Other things that are well-documented too, and there are no physical tussles over the code and where it goes.
For FreeBSD, I add IPSEC, IPSEC_DEBUG, and IPSEC_ESP to the kernel, recompile and install the kernel, and I'm ready to go. Adding IPv6 support is equally simple.
Plus, most of the applications that I use (mail, irc, ssh, etc...) already use both tcp4 and tcp6 sockets.
You linux guys are still lagging (IMO) with IPSec.
Whatever.
I only found this out recently, but the freeswan.org site lags behind the actual development of freeswan quite a lot. A nice friendly guy runs freeswan.ca, and keeps it chockablock with all the latest patches and stuff.
I've mirrored the downloads as they're so useful.
Get your own free personal location tracker
No, the whole kernel is about 32MB source. Binary is far smaller.
Don't compare a 43 MB binary download to a 32MB source download. That's apples to oranges.
FreeSWAN may be good for crypto, but bad for actually getting your work done. Regardless, the new IPSec code gets the hard part integrated, an ipv4 implementation should be trivial.
Sources themselves are huge compared to the bins they create especially considering source trees for projects like the kernel and X, which have support for many architectures. Much of the source code doesn't even get into the binary in the end.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
The bzip2 is 32MB. Get a real compression mechanism.
Unzipped only counts in terms of disc space. 160MB is small change for most machines. If its not, compile the kernel somewhere else and ship it over.
Still, it further proves my point, because that means we're goign from 160MB source to 10MB compiled code.
My whole point is people bitch about bloat when the kernel is anything but bloated. For all the stuff it contains (which is a lot), submitted by all those different people (which is a lot), its incredibly lean.
No, the ipsec in the kernel is actually IPv4 specific at the moment. It is NOT the USAGI IPv6 IPSEC code.
Yes. IIRC IPSec originated as a part of the IPv6 specification. Since then it has been backported to IPv4. This is a little unfortunate because that might actually slow down the transition from IPv4 to IPv6. Had IPv6 been a requirement to use IPSec, we might have seen IPv6 getting adopted a little faster.
Do you care about the security of your wireless mouse?
FreeS/WAN + NAT-Traversal patch manages this fine, by encapsulating the packets in UDP.
Aggressive Mode gets around this by collapsing two steps of the negotiation and transmitting a username in the clear. This is considered "insecure" by the FreeSwan team.
What's more "insecure"? Using AM or using a broken implementation of PPTP?
If you want to see bloat, take a look at the commercial UNIXes.
/stand/vmunix
For example, on a random HP 11.0 box here:
-rwxr-xr-x 1 root sys 18946872 May 9 08:43
That is a 19 megabyte binary kernel. It would be interesting to see how big the source is...
But the 32MB is for the compressed source, not for the binary. By the time you've compiled and compressed the binary image, it's typically down to about 5-700 KB, and I'd assume that if you have an embedded system with clearly defined minimal hardware you can probably get it a bit smaller than that. It's certainly not tiny, but the size of the end product (which is what really matters for the vast majority of people) is very reasonable.
There's no point in questioning authority if you aren't going to listen to the answers.
NAT-Traversal patch for FreeS/WAN is available at http://open-source.arkoon.net/
You'll be glad to know that the Cerberus/PlutoPlus implementations done by NIST are going to be more widely available in the near future. Specifically, I've been working on extending them to support large-scale configuration management of it. I ported the cerberus (read: ipsec) support to the 2.4 kernel, and am wrapping up the final details at the moment. The good news about it is that it's not done in the hacky way that freeswan did stuff. I'll be creating a sourceforge project for it within the week (I have a deadline to do it by next week), so look for it shortly.
I actually tried to approach the FreeSWAN folk to considering instrumenting their code with our policy-role-based configuration management support infrastructure, but they said "no US no way" and I didn't really have a choice if I wanted my patches rolled back into the project. The Cerberus and PlutoPlus developers, on the other hand, have been much more polite and helpful.
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
The patches are not supplied by the ipv6 (USAGI) people.
The new IPSEC code is writen by Dave Miller and Alexey Kuznetsov.
Al Qaeda has ninjas!
It's most likely because adding IPSEC adds your build time. Also, few people use it.
A problem with KAME IPSEC (and, I think, pretty much every non-free/swan IPSEC implementation) is that they don't do opportunistic encryption. You need pre-arranged certs or shared keys. If it did have something like that, I bet more people would use IPSEC by default.
(Annoying problem if people do start doing that: tcpdump becomes pretty much useless as a diagnostics tool.)
The cryptoAPI is the real kicker here folks.
/dev/random will no longer us its own crypto librtaries (SHA-1). IPSec will not use its own crypto (well, freeswan will because they feel there's value there).
.so's can have their digital signature verified before execution), and other majic stuff.
Once cryptoAPI is in the kernel,
CryptoAPI will also permit people to have encrypted filesystems, swap partitions, even BOOT partitions.
Present applications include: eliminate duplicated code, harmonize/facilitate crypto in the kernel, encrypted file systems, swap paritions, cdroms, etc., "turnkey" ipsec
Later applications include: load-time code-signing (that is all binaries and
JLC