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

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

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]

On Tue, Jul 29, 2003 at 11:44:57PM -0500, Rick Kennell wrote:
> I asked about this last week in the general netfilter list, but it
> appears that most folks are still using FreeS/WAN for IPsec.

yes, most people will use a stable kernel rather than a development one
;)

> I'm using the in-kernel IPsec and want to be able to filter ESP packets
> based on protocol or port number.  These values are encapsulated in the
> ESP payload and are unavailable to netfilter.  If I were using
> FreeS/WAN, I could use standard netfilter techniques on the ipsec0
> device.  With the in-kernel IPsec, there's no extra pseudo-device with
> which to examine unencapsulated ESP packets.

true.

> It looks too me like netfilter sees the packet as ESP in all chains in
> all tables.  (I'd be delighted to be corrected.)

I haven't investigated the new in-kernel ESP implementation that far,
but your observation sounds reasonable (although I don't say this is the
desired behaviour).

> Since ESP packets that reach the mangle INPUT chain are destined for a
> local process, why not unencapsulate them just before that point?  

Because NF_IP_LOCAL_IN (like all other hooks) are in the layer 3 stack,
and decapsulating ESP is inside a layer 4 protocol - thus it happens
after the ip stack has handed it over to the esp4 protocol engine.

> It might still be nice to have an indication that this was once an ESP
> packet for filtering, but that could be done by setting a mark in the
> mangle PREROUTING chain.

no. My preferred solution was something like adding a netfilter hook to
the xfrm4 engine, exactly after decapsulation / decryption of one layer,
i.e.  after xfrm_type.input was called. 

iptables could then register the INPUT chain (or probably even a
seperate POSTXFRM chain) in order to filter on the respective packets.

> I realize that this would probably require some heavy lifting in the
> network layer to accomplish this nesting of functionality.

yes, this is why this should be discussed on the netdev list (Cc'ed).

I think this needs to be sorted out before 2.6.0-final will be released.

Any comments are appreciated.

> Am I missing something obvious?

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "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 #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Andreas Jellinghaus]

Hi,

if you are using ipsec from kernel 2.6.* there is no "ipsec0"
interface, and thus using netfilter isn't as easy as it was with
freeswan.

three ways to solve the problem, only tried the first one so far:
1.) configure ipsec in tunnel mode, add your tunnel ip to 
    the outgoing interface, change the default route to
    set the source ip to the tunnel ip.
note: there is no routing step after encapsulating a packet
with ipsec, there was one with freeswan, so this is different.

2.) set a fwmark on an esp packet, it should be there after
    unpacking/decryption. didn't try this one.

3.) do not use the build in tunneling. use an explicit ipip tunnel.
	that way you have the interface, can use it in netfilter,
	can route into it, and the interface will set the right
	source address.

[netfilter]
incoming encrypted packets are seen as ESP/AH in INPUT
and then as decrypted packet in INPUT or FORWARD.

outgoing packets are only seen as ESP in OUTPUT.

> > Since ESP packets that reach the mangle INPUT chain are destined for a
> > local process, why not unencapsulate them just before that point?  

INPUT only means the ESP will be decrypted/unecapsulated.
after that the decrypted packet will show up in INPUT or FORWARD.

> no. My preferred solution was something like adding a netfilter hook to
> the xfrm4 engine, exactly after decapsulation / decryption of one layer,
> i.e.  after xfrm_type.input was called. 
>
> iptables could then register the INPUT chain (or probably even a
> seperate POSTXFRM chain) in order to filter on the respective packets.

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).

> Any comments are appreciated.

Regards, Andreas

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

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

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@netfilter.org>             http://www.netfilter.org/
============================================================================
  "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 #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Dax Kelson]

On Wed, 2003-07-30 at 08:51, Andreas Jellinghaus wrote:
> [netfilter]
> incoming encrypted packets are seen as ESP/AH in INPUT
> and then as decrypted packet in INPUT or FORWARD.

Just to clarify, the packets will travel INPUT *twice* (once as ESP and
then in the clear)?

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

[Dax Kelson]

On Wed, 2003-07-30 at 14:37, Dax Kelson wrote:
> On Wed, 2003-07-30 at 08:51, Andreas Jellinghaus wrote:
> > [netfilter]
> > incoming encrypted packets are seen as ESP/AH in INPUT
> > and then as decrypted packet in INPUT or FORWARD.
> 
> Just to clarify, the packets will travel INPUT *twice* (once as ESP and
> then in the clear)?

If this is the case, then I see a problem.

If you have an explicit drop/reject all the bottom (or have a DROP
policy) of INPUT then no IPSEC traffic would be allowed.

I supposed you could add a rule that allowed all ESP traffic before the
the explicit drop.

Dax