linux-ipsec: Re: IPSec: Fragmentation in Linux 2.0.xx IP stack

On Tue, 28 Apr 1998, Alan Cox wrote:

> > The version I am puting together is based on some old code (Enskip,

I am not sure about this. The Canadian team working on what they call KLIPS uses the JI code as their only source they base their work on. They are active development and want to make something to be integrated to 2.2.x. I am not impressed with the speed of delivering results so far, but they are making
some progress.

My code (better: the mixture of code which I made to work together) did not try to be able to be put under any specific copyright. The ciphers and hashes are not original and the packet processing had to be heavily modified for the linux skbuff paradigm as opposed to BSD mbufs. The IPsec "routing" uses the JI e-routes, which is nothing more than a port of the BSD radix trees.

The userland utilities I am using are all from OpenBSD now, but that is probably easy to change.

I would welcome any recommendations regarding copyright and other issues. But, please note, my aim is not to produce something which would survive ages, but to have a working IPSec for IPv4 under Linux which would interwork with other recent IPSec implementations.

>
> > I was wondering if you would have any idea where to put a hook to process

Hmmm... There were some major problems with the device paradigm in KLIPS, but they may have been caused by buggy implementation rather than wrong architecture.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

A third option would be to make own IPSec specific hooks into the whole IP stack.

> The other approach would be

That sounds interesting, as it might eliminate the need for a completely separate routing table (e-routes) for IPSec. I am not sure how stable the 2.1.xx release train is, as I have not used that yet. All our systems are 2.0.33 at the moment (we support about 50 servers both inhouse and at various customers).

> Even then the ip_build_xmit case remains. Right now ip_build_xmit > is

I understand the performance benefits and I do not want to get rid of it. I was considering spliting the IPSec decision making and the actual transormations and to make the decisions at the very beginning and provided the packet needs processing you need to do a lot of work on it anyway (the hashes and ciphers are not really cheap on processor and copying), so one might be able to assemble the whole datagram, transform it and return it for further processing (ie. fragmentation).

> Maybe change ip based sockets to call > > sk->ip_build_xmit() > > and

That sounds like a lot of work to me.

> Alan
>

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

Thanks for all your input,

Petr Novak Received on Tue Apr 28 09:22:24 1998