Date: Mon, 14 Jan 2002 15:09:06 +0100 From: Alex Le Heux <alexlh@funk.org> To: Kshitij Gunjikar <kshitijgunjikar@yahoo.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Filtering packets received through an ipsec tunnel Message-ID: <20020114140906.GN75815@funk.org> In-Reply-To: <DJEEIBCKNENADJJIMPLFOEGPCDAA.kshitijgunjikar@yahoo.com> References: <20020114131305.GK75815@funk.org> <DJEEIBCKNENADJJIMPLFOEGPCDAA.kshitijgunjikar@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I'm not worried about people modifying the IPSec packets en route, that's what we have strong crypto for. I am worried about giving the network at the other end of the tunnel full access to mine. In only a few of the many possible IPSec implementations do both ends of the tunnel follow the same security policies. And even then I might want to use filtering. I tend to see an IPSec tunnel more like a leased line that happens to use an IP network as iunderlying transport. Just as with a leased line I want to be able to filter packets going in and out, even though I may not use that filtering capability in all circumstances. Although using filters in this way on a machine that has multiple tunnels that go up and down could cause some headaches... Cheers, Alex On Mon, Jan 14, 2002 at 07:10:39PM +0530, Kshitij Gunjikar wrote: > Hi, > If you have a IPSec packet you can't see the data(even if u can it's > useless as it's encrypted). unless you exchange keys and know what the > encryption algorithm we can't decrypt and know the information being passed. > Hence, the fact that we are using IPsec gives greater security than any > firewall can. You can't possibly break a 128-bit encryption. till now I > don't think it has been broken. > > if you want restrict somebody in your internal network from using IPSec. > Then yes we must be able to do it with a firewall. > If somebody in your trusted internal network hacks then you are in trouble . > If I'm not wrong few firewalls take care of it . > > Also, if some body corrupts the encrypted packet then we can discard it at > time of decryption. > > Regards > Kshitij > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Alex Le Heux > Sent: Monday, January 14, 2002 6:43 PM > To: Kshitij Gunjikar > Cc: freebsd-net@freebsd.org > Subject: Re: Filtering packets received through an ipsec tunnel > > > Hi, > > I don't think this is quite correct. > > The fact that I have a tunnel means I have some relation with the other > network, and that I do not trust the network(s) between us. > > It does NOT mean that I trust their security setup and want to receive any > packet that they send me. > > So I would certainly hope that I have the option of filtering. > > Cheers, > > Alex Le Heux > > On Mon, Jan 14, 2002 at 05:32:11PM +0530, Kshitij Gunjikar wrote: > > > > > > Hi Rene, > > I'm wondering why do you want to filter Secure traffic? > > > > The very fact that you have a tunnel to a place means you trust that > > network. Hence, why filter? > > > > What are the complex situations you have in mind? > > > > Regards > > Kshitij > > > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org > > [mailto:owner-freebsd-net@freebsd.org]On Behalf Of Rene de Vries > > Sent: Sunday, January 13, 2002 10:32 PM > > To: net@freebsd.org > > Subject: Filtering packets received through an ipsec tunnel > > > > > > Hello, > > > > > This message was already posted to hackers@freebsd.org, but with > > > limited success. I'm hoping that someone on net@freebsd.org can give me > > > some more information. > > > > By experimenting with ipsec and looking at the source of "ip_input.c" a > > co-worker and I found the following out. > > > > When a ipsec tunnel packet is received this (protocol 50/51) packet is > > passed through ip-filter (& co). After filtering and when it has been > > determent that the current host is the destination (tunnel end-point), > > this packet is decrypted/verified. The decrypted packet is then pushed > > back into the queue that leads to ip_input(...). So far so good.... > > > > But once in ip_input(...) the filtering code is skipped and we were > > wondering why. > > > > I know that ipsec has some handles to be able to filter on address, > > protocol and/or port. But for more complex situations this is not > > enough. In these situations it would be nice to be able to use > > ip-filter (& co) on traffic from the tunnel (and also for traffic going > > into the tunnel). > > > > I was wondering why this is implemented the way it is. Maybe someone on > > this list could shed a light on this? > > > > Rene > > -- > > Rene de Vries <rene@tcja.nl> > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > -- > "My theory is that the (Internet) industry was started in > large part by technologists rather than media people..." > - Robin Webster, President, Interactive Advertising Bureau > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- "Although the force from the engine is a lot for a motorcycle, the Earth is not impressed. The Motorcycle and I loose the 'F' and 'm' battle and have to consume all the 'a' in the form of sheer unadulterated acceleration." - Ian Orr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020114140906.GN75815>