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

[Harald Welte <laforge@netfilter.org>]

[-- 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 --]