|
|||||||||||
|
Re: linux-ipsec: Linux IPsec architecture
From: Henry Spencer <henry(at)spsystems.net>
Date: Sat Aug 01 1998 - 23:41:43 EDT
This is a problem, to be sure, but it's not clear that it's our problem. If Linux wants IPSEC, there has to be a way to fit it into the kernel. Believe me, we don't *like* patching the kernel, and we are not happy about how much patching our current code has to do. We did it because we saw no good alternative, at least not within the 2.0.xx kernels. Actually, it makes very little difference whether the filter is a kernel module or a user-space process. Just doing the tapping, to route the IP traffic through *some* *kind* of filter, is the hard part in the 2.0.xx kernels. We'd have done it that way if we could, but the network code is not very modular, and the folks who looked at it for us could not find a good way to insert a filter. We hope that 2.1.xx will make it easier. We'd very much prefer to avoid, or at least minimize, alterations to the rest of the kernel. Our current arrangement is a temporary expedient, which we have not worried about much because it's all going to have to change for 2.1.xx anyway. In fact, there are strong reasons for wanting the filter to be a kernel component: many people who want to do IPSEC want to do a lot of it, and crossing the kernel/user boundary is costly. There is really no good reason to put the crypto code in a user-level process. What matters is whether the standard kernel has to be modified to provide the interfaces for the crypto code, not where the crypto code itself is located.
Henry Spencer
henry@spsystems.net
(henry@zoo.toronto.edu)
Received on Sun Aug 2 00:21:51 1998This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 12:59:25 EDT |
||||||||||
|
|||||||||||