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

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

[Rick Kennell]

I asked about this last week in the general netfilter list, but it
appears that most folks are still using FreeS/WAN for IPsec.

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.

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

Since ESP packets that reach the mangle INPUT chain are destined for a
local process, why not unencapsulate them just before that point?  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.

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

Am I missing something obvious?

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

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

[Chris Wilson]

Hi Rick,

> Since ESP packets that reach the mangle INPUT chain are destined for a
> local process, why not unencapsulate them just before that point?  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.

The ESP itself will presumably be for a security association (SA) which
terminates on the machine, but it could easily be for some tunnel, in
which case the unencrypted packet should be sent through FORWARD instead 
of INPUT.

Logically, it makes sense to me that the packet should pass through the 
whole of Netfilter _again_ after it's been decapsulated, similarly to what 
now happens with FreeS/WAN (but presumably without an ipsec0 interface 
being involved). Or, maybe it should be decapsulated before routing (and 
hence visible unencrypted in FORWARD, INPUT and OUTPUT).

Cheers, Chris.
-- 
   ___ __     _
 / __// / ,__(_)_  | Chris Wilson -- UNIX Firewall Lead Developer |
/ (_ / ,\/ _/ /_ \ | NetServers.co.uk http://www.netservers.co.uk |
\ _//_/_/_//_/___/ | 21 Signet Court, Cambridge, UK. 01223 576516 |

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

[Rick Kennell]

On Wed, 2003-07-30 at 05:34, Chris Wilson wrote:
> Hi Rick,
> 
> > Since ESP packets that reach the mangle INPUT chain are destined for a
> > local process, why not unencapsulate them just before that point?  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.
> 
> The ESP itself will presumably be for a security association (SA) which
> terminates on the machine, but it could easily be for some tunnel, in
> which case the unencrypted packet should be sent through FORWARD instead 
> of INPUT.

Mmm, sure.  But if it is directed to INPUT, it should still be
decapsulated.

> Logically, it makes sense to me that the packet should pass through the 
> whole of Netfilter _again_ after it's been decapsulated, similarly to what 
> now happens with FreeS/WAN (but presumably without an ipsec0 interface 
> being involved).

I thought about this for a while trying to figure out how to do so
without an extra interface.  Maybe a netfilter rule to decapsulate and
requeue to PREROUTING?

> Or, maybe it should be decapsulated before routing (and 
> hence visible unencrypted in FORWARD, INPUT and OUTPUT).

If the packet were being routed by the local host (i.e. from one subnet
to another) we'd want to preserve the encapsulation.  Actually, we
probably wouldn't be able to decapsulate it.

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

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

[Rick Kennell]

On Wed, 2003-07-30 at 05:34, Chris Wilson wrote:
> Hi Rick,
> 
> > Since ESP packets that reach the mangle INPUT chain are destined for a
> > local process, why not unencapsulate them just before that point?  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.
> 
> The ESP itself will presumably be for a security association (SA) which
> terminates on the machine, but it could easily be for some tunnel, in
> which case the unencrypted packet should be sent through FORWARD instead 
> of INPUT.

Mmm, sure.  But if it is directed to INPUT, it should still be
decapsulated.

> Logically, it makes sense to me that the packet should pass through the 
> whole of Netfilter _again_ after it's been decapsulated, similarly to what 
> now happens with FreeS/WAN (but presumably without an ipsec0 interface 
> being involved).

I thought about this for a while trying to figure out how to do so
without an extra interface.  Maybe a netfilter rule to decapsulate and
requeue to PREROUTING?

> Or, maybe it should be decapsulated before routing (and 
> hence visible unencrypted in FORWARD, INPUT and OUTPUT).

If the packet were being routed by the local host (i.e. from one subnet
to another) we'd want to preserve the encapsulation.  Actually, we
probably wouldn't be able to decapsulate it.

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

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

[Henrik Nordstrom]

On Wed, 30 Jul 2003, Chris Wilson wrote:

> Logically, it makes sense to me that the packet should pass through the 
> whole of Netfilter _again_ after it's been decapsulated, similarly to what 
> now happens with FreeS/WAN (but presumably without an ipsec0 interface 
> being involved). Or, maybe it should be decapsulated before routing (and 
> hence visible unencrypted in FORWARD, INPUT and OUTPUT).

It needs to pass routing first unless something has changed drastically 
in the 2.6 IP networking code, or else the kernel won't know if the 
ipsec packet is to be decapsulated or routed.

Regards
Henrik

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

[Henrik Nordstrom]

On Wed, 30 Jul 2003, Chris Wilson wrote:

> Logically, it makes sense to me that the packet should pass through the 
> whole of Netfilter _again_ after it's been decapsulated, similarly to what 
> now happens with FreeS/WAN (but presumably without an ipsec0 interface 
> being involved). Or, maybe it should be decapsulated before routing (and 
> hence visible unencrypted in FORWARD, INPUT and OUTPUT).

It needs to pass routing first unless something has changed drastically 
in the 2.6 IP networking code, or else the kernel won't know if the 
ipsec packet is to be decapsulated or routed.

Regards
Henrik

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?

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

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

[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

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?

[Jeremy Davis]

I guess I need to get a develop kernel and do some testing.  Purdue aye, I
just moved from Indianapolis, had many friends that attended Purdue.  Been
there a time or two myself.

Jeremy Davis
Security Analyst
Slice Networks

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Rick Kennell
Sent: Wednesday, July 30, 2003 12:45 AM
To: netfilter-devel@lists.netfilter.org; netfilter@lists.netfilter.org
Subject: port-based filtering of ESP packets with in-kernel IPsec?


I asked about this last week in the general netfilter list, but it
appears that most folks are still using FreeS/WAN for IPsec.

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.

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

Since ESP packets that reach the mangle INPUT chain are destined for a
local process, why not unencapsulate them just before that point?  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.

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

Am I missing something obvious?

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