All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gervasio Bernal <gervasiobernal@speedy.com.ar>
To: netfilter-devel@lists.netfilter.org
Subject: Re: New extension: CRYPT target
Date: Mon, 22 May 2006 20:49:18 -0300	[thread overview]
Message-ID: <44724DFE.5030806@speedy.com.ar> (raw)
In-Reply-To: <4470E716.1090001@gmx.net>

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

  reply	other threads:[~2006-05-22 23:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-21 15:59 New extension: CRYPT target Gervasio Bernal
2006-05-21 17:01 ` Carl-Daniel Hailfinger
2006-05-21 21:15   ` Gervasio Bernal
2006-05-21 22:17     ` Carl-Daniel Hailfinger
2006-05-22 23:49       ` Gervasio Bernal [this message]
2006-05-23 16:27         ` Gervasio Bernal
2006-05-23 16:46           ` Carl-Daniel Hailfinger
2006-05-23 17:07             ` Patrick McHardy
2006-05-23 17:14               ` Carl-Daniel Hailfinger
2006-05-23 23:13                 ` Gervasio Bernal
2006-05-24  5:03                   ` Patrick Schaaf
2006-05-23 18:26           ` Michael Richardson
2006-05-21 22:57     ` Michael Richardson
2006-05-22 23:36       ` Gervasio Bernal
2006-05-23 13:08         ` Michael Richardson
2006-05-23 17:19           ` Gervasio Bernal
2006-05-21 17:51 ` Martijn Lievaart
2006-05-21 20:34   ` Cedric Blancher
2006-05-21 21:01   ` Gervasio Bernal
2006-05-21 22:54   ` Michael Richardson
2006-05-21 20:27 ` Gervasio Bernal
2006-05-25 16:11 ` Lennart Poettering
2006-05-26 18:12   ` Gervasio Bernal
2006-05-26 18:25     ` Patrick McHardy
  -- strict thread matches above, loose matches on Subject: below --
2006-05-23 23:33 Gervasio Bernal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44724DFE.5030806@speedy.com.ar \
    --to=gervasiobernal@speedy.com.ar \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.