From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gervasio Bernal Subject: Re: New extension: CRYPT target Date: Mon, 22 May 2006 20:49:18 -0300 Message-ID: <44724DFE.5030806@speedy.com.ar> References: <44708E68.9080508@speedy.com.ar> <44709CFC.7050007@gmx.net> <4470D859.7000706@speedy.com.ar> <4470E716.1090001@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT Return-path: In-reply-to: <4470E716.1090001@gmx.net> To: netfilter-devel@lists.netfilter.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Carl-Daniel Hailfinger wrote: > Gervasio Bernal wrote: > >>Carl-Daniel Hailfinger wrote: >> >>>Gervasio Bernal wrote: >>> >>> >>>>(on host A, 1.2.3.4, FTP client) >>>># iptables -t mangle -A POSTROUTING -d 1.2.3.5 -p tcp --dport 20:21 -j >>>>CRYPT --cipher blowfish --key topsecret --mode ecb --direction encrypt >>> >>>Ouch. If anybody runs ps while this iptables command is running, he has >>>your top secret key. > > > How are you going to prevent that? Well, give us some time to study it. > > > >>>Does this provide any benefit over IPSEC? > > >>IPSEC/OpenSwan is complicated to use and quite heavy. > > > I admit IPSEC is complicated to use, but it has lightweight modes. > > >>CRYPT is truely peer-to-peer. > > > IPSEC also has peer-to-peer modes. > > >>It is compatible with routing daemons. > > > Same for IPSEC to a certain extent (depends on how you use IPSEC) > > >>It allows you to encrypt all the traffic between two endpoints or >>only certain type of traffic (ej: only TCP connections). > > > Same for IPSEC. > > >>It is extremely easy to use for an administrator familiarized >>with Linux firewalling since it uses Iptables and it > > > Unfortunately, IPSEC is not so easy to use. > > >>does not make any modification to the normal routing behavior. > > > IPSEC can do that in some modes. > > >>CRYPT is considerably light and does all the >>encryption/decryption process at kernel space (contrary to OpenVPN). > > > OK, but does it have any advantages over an encryption library loaded > with LD_PRELOAD which replaces all networking functions for a given > application with its own encrypted variant? I consider "all in kernel" > to be a disadvantage. > > > What happens if a router on the way decides to fragment the packets? In TCP connections there is no problem, we use destination MTU to calculate the corresponding Maximun Segment Size. In others protocols we are studying the way to avoid fragmentation. > > > I think your approach to encrypted communication is interesting, but > wouldn't an iptables interface to IPSEC in transport mode achieve > similar results? Yes, but if you tell to someone that he can encrypt and authenticate a communication using Iptables only, I think that the extension could interest to him. > > > Regards, > Carl-Daniel