public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rick Kennell <kennell@ecn.purdue.edu>
To: Andrew McGregor <andrew@indranet.co.nz>
Cc: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>,
	LKML <linux-kernel@vger.kernel.org>,
	netdev@oss.sgi.com
Subject: Re: [OT] Connection tracking for IPSec
Date: Wed, 20 Aug 2003 23:37:01 -0500	[thread overview]
Message-ID: <1061440621.16712.289.camel@k7.localnet> (raw)
In-Reply-To: <1710000.1061417560@ijir>

On Wed, 2003-08-20 at 17:12, Andrew McGregor wrote:
> --On Wednesday, August 20, 2003 04:16:28 PM +0200 Felipe Alfaro Solana 
> <felipe_alfaro@linuxmail.org> wrote:
> > The problem here is that opening up protocols 50 and 51, makes *any*
> > IPSec-protected traffic to pass the firewall, but I still want that any
> > traffic (IPSec-protected or not) be applied the connection-track
> > filters. For normal (no IPSec) traffic, an incoming packet is only
> > accepted if it belongs to a connection that was initiated locally. For
> > IPSec traffic, I just want the same. I don't want any kind of
> > IPSec-protected traffic to be able to pass through the firewall, only
> > traffic that belongs to a connection that was initiated locally on the
> > machine receiving it.
> 
> It doesn't make sense for this configuration to fail in this way, I agree.
> 
> Essentially, the ESP and AH transforms should be a magic netfilter rule, so 
> you can insert them in a netfilter chain and do this sort of thing.  If 
> they aren't, we should at least have the input and output chains traversed 
> by packets both before and after the transforms.

I brought up the same thing in the netfilter and netfilter-dev lists
last month.  http://www.spinics.net/lists/netfilter/msg18030.html

I think there's no need for a special netfilter rule if the assumption
is made that an ESP packet reaching the "mangle" chain of the "INPUT"
table is definitely destined for a local process.  At that point, it
should be automatically unencapsulated so that its true protocol and
port numbers can be interrogated.  e.g. if we know an ESP packet is for
this machine, do the unencapsulation as early as possible.  Since
there's not yet a consensus on the behavior of things like NAT-based
forwarding of IPsec packets I think this is a safe assumption.  (But my
opinion generally doesn't count for much.)

If it's important to remember that the packet had been an ESP packet,
netfilter can be set up to mark it as such in the PREROUTING mangle
chain so that it can later be filtered appropriately.  This seems
similar to what I've read is done in FreeBSD:

http://www.bsdforums.org/forums/showthread.php?threadid=11725

> The issue exists, I'm convinced.  Dang, I'm going to run into it too one 
> day soon.  Another thing that needs looking at, in case noone else fixes it 
> first.

That's sort of what I thought too.  And, yeah, I'd be real happy if
someone else did it before I tried to.  8^)

-- 
Rick Kennell <kennell@ecn.purdue.edu>
Purdue University School of Electrical and Computer Engineering


  reply	other threads:[~2003-08-21  4:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-20 11:22 [OT] Connection tracking for IPSec Felipe Alfaro Solana
2003-08-20 12:11 ` Christophe Saout
2003-08-20 14:22   ` Felipe Alfaro Solana
2003-08-20 14:53     ` Christophe Saout
2003-08-20 15:18       ` Felipe Alfaro Solana
2003-08-20 17:36       ` Jose Luis Domingo Lopez
2003-08-20 12:49 ` Andrew McGregor
2003-08-20 14:16   ` Felipe Alfaro Solana
2003-08-20 22:12     ` Andrew McGregor
2003-08-21  4:37       ` Rick Kennell [this message]
2003-08-20 14:43 ` Wiktor Wodecki

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=1061440621.16712.289.camel@k7.localnet \
    --to=kennell@ecn.purdue.edu \
    --cc=andrew@indranet.co.nz \
    --cc=felipe_alfaro@linuxmail.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox