netfilter and ipsec

netfilter and ipsec

[寬旻]

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


  Hi ,
  I am a new entrant in linux network security, and have tried to understand Netfilter and FreesWan.
  There is a question now confusing me so long. Why not integrating IPSec in the Netfilter architecture?
  Is there any reason that IPSec must exist as an device driver or some drawbacks to integrate??


  Regards
  Kuan-Ming Lin
    

[-- Attachment #2: Type: text/html, Size: 999 bytes --]

Re: netfilter and ipsec

[Stefan Schlott]

Re-Hi,

>   I am a new entrant in linux network security, and have tried to
> understand Netfilter and FreesWan.
>   There is a question now confusing me so long. Why not integrating
> IPSec in the Netfilter architecture?
>   Is there any reason that IPSec must exist as an device driver or
> some drawbacks to integrate??

I personally never touched the FreeSWAN-code, but I did the kernel part of
an IPsec-implementation for the IPv6 module about 2 years ago. So, this
statement is from an IPv6-point-of-view :-)
The main problem is the increasing size of a packet: It is possible to
modify packets in netfilter - as long as you don't increase the size.
Fragmentation is done somewhere else (in an earlier stage), so you have
to make sure that your IPsec-enriched packets do not exceed the (P)MTU.
If they do, this is your problem. If you don't care, the kernel will drop
the outgoing packet.
Of course, you could implement that, but this would void the performance
optimization done in the TCP code.
Inbound packets are not better: When netfilter gets hold of them, they are
still fragmented - afaik IPsec processing is done on the reassembled packets
(this makes sense: If a fragment is lost, some expensive cryptographic
operations would have been done in vain).
That's why I ended up patching the ipv6 module.

Well, as already mentioned - that was two years ago. If something has
changed, I'd be curious to know.

Stefan.

-- 
*--- please cut here... -------------------------------------- thanks! ---*
|-> E-Mail: stefan.schlott@informatik.uni-ulm.de    PGP-Key: 0x2F36F4FE <-|
| The only secure Microsoft software is what's still shrink-wrapped in    |
| their warehouse...                                                      |
|   -- Richard Forno                                                      |
*-------------------------------------------------------------------------*

Netfilter and IPSec

[Fábio Souto]

Hello,

First place, let me congratulate all of this community, whose 
contribution is of utmost importance.
Hopefully, I will integrate it with pride.

So, what brings me here...

I'm trying to find out some alternatives for a task I have been assigned.
Basically, I want to sign IPSec packets on another machine. The idea is 
when I receive an IPSec packet, I delegate the cryptographic signature 
generation to another machine, and I receive the signed packet.
I'm currently studying several alternatives for doing this, and even 
tried a socket-based approach, by changing some kernel modules, which 
has failed. It would require a huge remake of kernel code; this task is 
made even harder due to lack of documentation.

So I was wondering if anyone knew if with netfilter is possible to 
achieve this. Any other suggestions/hints would be extremely valued.

Thanks in advance!

-- 
------------------------------------------------------------------------------------------
Fábio Souto
LaSIGE , Navigators Group
Departamento de Informática, FC/UL
Block C6, room 6.3.32, Campo Grande
1749-016 Lisboa, Portugal

Re: Netfilter and IPSec

[Jan Engelhardt]

On Tuesday 2008-04-15 05:41, Fábio Souto wrote:
>
> I'm trying to find out some alternatives for a task I have been
> assigned. Basically, I want to sign IPSec packets on another
> machine. The idea is when I receive an IPSec packet, I delegate the
> cryptographic signature generation to another machine, and I
> receive the signed packet.
>
> I'm currently studying several alternatives for doing this, and
> even tried a socket-based approach, by changing some kernel
> modules, which has failed. It would require a huge remake of kernel
> code; this task is made even harder due to lack of documentation.
>
> So I was wondering if anyone knew if with netfilter is possible to
> achieve this. Any other suggestions/hints would be extremely
> valued.

The situation is deliberate, yes. IPsec is done in what you could
call the xfrm subsystem, not netfilter. To that end, the only
suggestion I could give is that you create a new xfrm policy/state
from esp where esp is split into your encryption and signing
"targets".

It kinda brings me the question why the ipsec transformation is
not done with an xtables target instead; that would also give
handy access to connection tracking if needed.

Re: Netfilter and IPSec

[Jan Engelhardt]

On Tuesday 2008-04-15 05:41, Fábio Souto wrote:
>
> I'm trying to find out some alternatives for a task I have been
> assigned. Basically, I want to sign IPSec packets on another
> machine. The idea is when I receive an IPSec packet, I delegate the
> cryptographic signature generation to another machine, and I
> receive the signed packet.
>
> I'm currently studying several alternatives for doing this, and
> even tried a socket-based approach, by changing some kernel
> modules, which has failed. It would require a huge remake of kernel
> code; this task is made even harder due to lack of documentation.
>
> So I was wondering if anyone knew if with netfilter is possible to
> achieve this. Any other suggestions/hints would be extremely
> valued.

The situation is deliberate, yes. IPsec is done in what you could
call the xfrm subsystem, not netfilter. To that end, the only
suggestion I could give is that you create a new xfrm policy/state
from esp where esp is split into your encryption and signing
"targets".

It kinda brings me the question why the ipsec transformation is
not done with an xtables target instead; that would also give
handy access to connection tracking if needed.

Re: Netfilter and IPSec

[Ingo Oeser]

Jan Engelhardt schrieb:
> It kinda brings me the question why the ipsec transformation is
> not done with an xtables target instead; that would also give
> handy access to connection tracking if needed.

And simplify firewalling A LOT :-)

BTW: Anybody has a working ipsec match these days or is this known broken?


Best regards

Ingo Oeser

Re: Netfilter and IPSec

[Patrick McHardy]

Ingo Oeser wrote:
> BTW: Anybody has a working ipsec match these days or is this known broken?


It should work as always. Are there any problems I'm not aware of?

Re: Netfilter and IPSec

[Jan Engelhardt]

On Tuesday 2008-04-15 18:54, Ingo Oeser wrote:
>Jan Engelhardt schrieb:
>> It kinda brings me the question why the ipsec transformation is
>> not done with an xtables target instead; that would also give
>> handy access to connection tracking if needed.
>
>And simplify firewalling A LOT :-)
>
>BTW: Anybody has a working ipsec match these days or is this known broken?

-p esp, -m policy, take your pick :-)

Re: Netfilter and IPSec

[Fábio Souto]

Jan Engelhardt wrote:
>
>
> The situation is deliberate, yes. IPsec is done in what you could
> call the xfrm subsystem, not netfilter. To that end, the only
> suggestion I could give is that you create a new xfrm policy/state
> from esp where esp is split into your encryption and signing
> "targets".
>
>   
Thank you for all answers. The major problem I'm facing is the lacking 
of documentation on that subsystem.
For example, how to create a policy. And after that?
My task is a bit easier, because I only need to use AH and not ESP.
Although a flexible solution would be of value :)

The kernel is still a bit unknown to me, so I'm having a bit of trouble 
into all the jargon you are using around.
But the few things I understood are being extremely helpful.
> It kinda brings me the question why the ipsec transformation is
> not done with an xtables target instead; that would also give
> handy access to connection tracking if needed.
>   
With that I must agree!

-- 
------------------------------------------------------------------------------------------
Fábio Souto
LaSIGE , Navigators Group
Departamento de Informática, FC/UL
Block C6, room 6.3.32, Campo Grande
1749-016 Lisboa, Portugal