[Top] [All Lists]

Re: port-based filtering of ESP packets with in-kernel IPsec?

To: Andreas Jellinghaus <aj@xxxxxxxxxxxxxxx>
Subject: Re: port-based filtering of ESP packets with in-kernel IPsec?
From: Harald Welte <laforge@xxxxxxxxxxxxx>
Date: Wed, 30 Jul 2003 17:16:53 +0200
Cc: netfilter-devel@xxxxxxxxxxxxxxxxxxx, netfilter@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <1059576701.4586.20.camel@simulacron>
Mail-followup-to: Harald Welte <laforge@xxxxxxxxxxxxx>, Andreas Jellinghaus <aj@xxxxxxxxxxxxxxx>, netfilter-devel@xxxxxxxxxxxxxxxxxxx, netfilter@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
References: <1059540296.16545.305.camel@xxxxxxxxxxx> <20030730142411.GD4553@xxxxxxxxxxxxxxxxxxxxxxx> <1059576701.4586.20.camel@simulacron>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.4i
On Wed, Jul 30, 2003 at 04:51:41PM +0200, Andreas Jellinghaus wrote:
> [netfilter]
> incoming encrypted packets are seen as ESP/AH in INPUT
> and then as decrypted packet in INPUT or FORWARD.

ok, great.

> outgoing packets are only seen as ESP in OUTPUT.

this could be a problem.  I think there is quite a number of users who
want to impose packet filtering on outgoing locally-originated
packets... and obviously you want to do that at some time _before_ you
hide everything behind crypto..

> you can already filter incoming packets. The problem is you
> don't know if they came in that way they look now, or if they
> came in via ESP packets and got decrypted.
> maybe decryption/unencapsulating could leave a mark on the
> packet, so we know packets without that mark came in without
> ipsec and are bad / attempts to access resources without ipsec?
> (maybe fwmark works on that. or an explicit ipip tunnel, so you
> have "ipip0" or something as incoming interface).

This sounds a bit like the existing problem with bridgewalling.  They
also have no idea of where the packet originally came from (at least
before the physdev stuff was introduced as solution to this).

- Harald Welte <laforge@xxxxxxxxxxxxx>   
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

Attachment: pgpvwTGoug954.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>