[Openswan dev]

Hi dev,

A new release of the ocf-linux package is up:

	http://ocf-linux.sourceforge.net/

Mostly Openswan updates/cleanups and fixes in this release.

* Well tested on 2.4.32 and 2.6.15 with OpenSwan.
* hold locks for less time which improves
  the cryptosoft (software driver) interaction
  with the system.
* fix cryptodev to handle CRIOGET requests when
  application is chrooted.
* Bug fixes and improvements by Ronen Shitrit
  md5/sha processing in cryptosoft
  other typo/ordering problems in cryptosoft
  more error reporting to make debugging easier.
* updated openswan patch for 2.4.5rc5
* openswan support no longer requires any other crypto
  code (other than OCF) to be configured in.
* openswan code Q's state machine when in interrupt context
  and calls immediately when not (previously compile time
  determined)
* openssh uses OCF appropriately now if it supports required   
  algs
* updated ssl patch to openssl-0.9.8a
* no patch required for openssh anymore
* openssl md5/sha support by Ronen Shitrit

[Openswan dev] Accelerating IPSec

Hi all,

I develop a software that expoits the MPC's 8248 Security Engine 
capabilities in order to use it in openswan. I want to ask you if the 
connection of this software and openswan should be done through 
CryptoAPI making a "new" encryption algorithm or by modifying the 
built-in crypto and hashing functions that exist in openswan ? It seems 
(is that true ?) that CryptoAPI can be used from openswan only for 
cipher algorithms and not for hashing. For example I didn't see anywhere 
in ipsec_alg_cryptoapi.c a function that assigns a hashing algorithm. 
Also I saw that in ipsec_esp.c or in ipsec_ah.c that only built-in 3DES 
or MD5 or SHA1 algorithms are used (e.g. in ipsec_xmit_esp_setup).

Thanks in advance,

Panayotis Tziaros
Software Engineer

Re: [Openswan dev] Accelerating IPSec

Jivin Panayotis Tziaros lays it down ...
> Hi all,
> 
> I develop a software that expoits the MPC's 8248 Security Engine 
> capabilities in order to use it in openswan. I want to ask you if the 
> connection of this software and openswan should be done through 
> CryptoAPI making a "new" encryption algorithm or by modifying the 
> built-in crypto and hashing functions that exist in openswan ? It seems 
> (is that true ?) that CryptoAPI can be used from openswan only for 
> cipher algorithms and not for hashing. For example I didn't see anywhere 

CryptoAPI is used for both ciphers and hashes (auth),  check in
ipsec_alg.c for the code.

> in ipsec_alg_cryptoapi.c a function that assigns a hashing algorithm. 
> Also I saw that in ipsec_esp.c or in ipsec_ah.c that only built-in 3DES 
> or MD5 or SHA1 algorithms are used (e.g. in ipsec_xmit_esp_setup).

No,  it can use either the builtin ones or the CryptoAPI (ALG) ones.
Look for the various ifdef CONFIG_KLIPS_ALG's to find the code.

If you are implementing a HW solution,  and it is capable of
asynchronous (ie., interrupt driven) operation perhaps you should look
at:

	http:/ocf-linux.sourceforge.net/

It gives you a framework for accelerating OpenSwan, OpenSSL and OpenSSH
and other things,

Re: [Openswan dev] Accelerating IPSec

David McCullough wrote:

>Jivin Panayotis Tziaros lays it down ...
>  
>
>CryptoAPI is used for both ciphers and hashes (auth),  check in
>ipsec_alg.c for the code.
>
>No,  it can use either the builtin ones or the CryptoAPI (ALG) ones.
>Look for the various ifdef CONFIG_KLIPS_ALG's to find the code.
>
>  
>
OK I'll check the code to find the link points  to cryptoAPI.

>If you are implementing a HW solution,  and it is capable of
>asynchronous (ie., interrupt driven) operation perhaps you should look
>at:
>
>	http:/ocf-linux.sourceforge.net/
>
>It gives you a framework for accelerating OpenSwan, OpenSSL and OpenSSH
>and other things,
>
>  
>
Yes, the device is capable of asynchronous operation so this solution is 
very interesting and I'll definitely look at it soon.

>Cheers,

[Openswan dev] pfkey_msg_build of Add SA esp.XX failed

---------- Forwarded message ----------
Date: Fri, 10 Mar 2006 10:14:30 +0000
From: Brian Candler <B.Candler <at> pobox.com>
To: users <at> openswan.org
Subject: [Openswan Users]

I have an interoperability problem between Openswan 2.4.5rc5 and Cisco PIX
7.0.2 with PFS enabled. Phase 1 comes up successfully, but phase 2 fails
with a pfkey error: "Trouble parsing newly built pfkey message, error=-22"

After this openswan *says* that the quick mode SA was actually brought up
successfully, and I can send outbound pings (they appear as UDP 4500
encapsulated), but I don't see any replies.

The setup is like this:

                                  dynamic     static
10.1.50.0/28          172.151     x.x.x.x     p.p.p.p     10.1.1.0/24
------------ Openswan ------- NAT =================== PIX -----------
             (Linux)          rtr

Openswan is running under Linux 2.4.30 (actually an OpenWRT box, where I've
recompiled the openswan package to bring it up to 2.4.5rc5)

Because the openswan 'client' box is on a dynamic IP address, I'm using
aggressive mode so that the PIX can choose the correct pre-shared key to
use.

Here's what I see at the openswan side:

[Openswan dev] more info on pfs failure previous message

---------- Forwarded message ----------
Date: Fri, 10 Mar 2006 15:35:18 +0000
From: Brian Candler <B.Candler <at> pobox.com>
To: users <at> openswan.org
Subject: [Openswan Users]

>                                   dynamic     static
> 10.1.50.0/28          172.151     x.x.x.x     p.p.p.p     10.1.1.0/24
> ------------ Openswan ------- NAT =================== PIX -----------
>              (Linux)          rtr

Supplementary information:

(1) Logs from the PIX side

Once the Openswan box thinks that phase 2 is up, it sends packets to UDP
port 4500, but the PIX is discarding them (without explaining exactly *why*
it's discarding them). The logs show incoming UDP packets from openswan with
two different source ports, x.x.x.x/62859 and x.x.x.x/3593, to port 4500.

Mar 10 14:27:00 pixfw2 %PIX-7-713906: IP = x.x.x.x, processing SA payloadMar 10 14:27:00 pixfw2
%PIX-7-713906: IP = x.x.x.x, processing ke payloadMar 10 14:27:00 pixfw2 %PIX-7-713906: IP = x.x.x.x,
processing ISA_KE
Mar 10 14:27:00 pixfw2 %PIX-7-715001: IP = x.x.x.x, processing nonce payload
Mar 10 14:27:00 pixfw2 %PIX-7-715001: IP = x.x.x.x, Processing ID
Mar 10 14:27:00 pixfw2 %PIX-7-715047: IP = x.x.x.x, processing VID payload
Mar 10 14:27:00 pixfw2 %PIX-7-715049: IP = x.x.x.x, Received DPD VID
Mar 10 14:27:00 pixfw2 %PIX-7-715047: IP = x.x.x.x, processing VID payload
Mar 10 14:27:00 pixfw2 %PIX-7-715047: IP = x.x.x.x, processing VID payload

[Openswan dev] patch for pfs (really nat aggressive mode) issue

I'll write up a test case and then look at this patch, and the one in
teh bugracker at #231, and resolve this before we release 2.4.5.

Paul

---------- Forwarded message ----------
Date: Fri, 10 Mar 2006 16:51:37 +0000
From: Brian Candler <B.Candler <at> pobox.com>
To: users <at> openswan.org
Subject: Re: [Openswan Users]

(Sorry to reply to myself again 

On Fri, Mar 10, 2006 at 03:35:18PM +0000, Brian Candler wrote:
> If I run tcpdump on the openswan box's own interface, I see some packets
> with {src 500, dst 4500} and others with {src 4500, dst 4500}. As far as I
> can tell, the 500/4500 ones are IKE, and 4500/4500 are payload (i.e. test
> pings)
>
> Is this correct, or is openswan messing up here?? Since there are two
> different source ports, of course these get mapped to two different ones via
> the intervening NAT.

Turning on natt debugging in openswan, I also see:

Jan  2 01:34:46 (none) kern.debug pluto[9211]: | processing connection pix
Jan  2 01:34:46 (none) kern.debug pluto[9211]: | NAT-T: updating local port to 500
Jan  2 01:34:46 (none) kern.debug pluto[9211]: | NAT-T connection has wrong interface definition
172.151.113.52:500 vs 172.151.113.52:4500

Re: [Openswan dev] pfkey_msg_build of Add SA esp.XX failed

    Brian> 10:14:30 +0000 From: Brian Candler <B.Candler <at> pobox.com> To:
    Brian> users <at> openswan.org Subject: [Openswan Users]

    Brian> I have an interoperability problem between Openswan 2.4.5rc5
    Brian> and Cisco PIX 7.0.2 with PFS enabled. Phase 1 comes up
    Brian> successfully, but phase 2 fails with a pfkey error: "Trouble
    Brian> parsing newly built pfkey message, error=-22"

  PFS on or off shouldn't matter.
  I assume that this message is coming from pluto.

Jan  1 18:17:53 (none) kern.debug pluto[6463]: | pfkey_lib_debug:pfkey_msg_parse: parsing message
ver=2, type=2(update), errno=0, satype=0(UNKNOWN), len=11, res=0, seq=13, pid=6463.

  The satype=0 is what screws things up. I am uncertain why this is happening. 
Can you operate with anything else?  Can you try the same code on an x86
box?

    Paul> Anybody got any ideas what's going on here, or is there some
    Paul> more debugging I can turn on to help pin this down? As far as
    Paul> I can tell from the source, it seems that openswan is
    Paul> generating a message, running it through its own parser before
    Paul> sending it, and failing to parse it. This implies the problem
    Paul> is either with the format of the message it generates or with
    Paul> its own parser, and not with the PIX.

  Yes-ish.
  It may also be that it accepted a parameter of some kind from the PIX,
which turns out to confuse it when it builds the message. Reparsing the

Re: [Openswan dev] more info on pfs failure previous message

> If I run tcpdump on the openswan box's own interface, I see some
> packets with {src 500, dst 4500} and others with {src 4500, dst
> 4500}. As far as I can tell, the 500/4500 ones are IKE, and 4500/4500
> are payload (i.e. test pings)

Yes, the basically correct.
However, it is supposed to send 500/500 and 4500/4500.

Aggressive mode + NAT isn't well tested. That shouldn't matter re: the
pfkey issue, except that perhaps it confuses things.

--

-- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr <at> xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

[Openswan dev] Badness in remove_proc_entry

Hi

I get the following message when removing the ipsec module from the
kernel:
"Badness in remove_proc_entry at fs/proc/generic.c"
I read somewhere that it should be fixed in release 2.4.5 but from a
code review it seems that, it still has the same problem.

Any way to solve it see attached patch to linux/net/ipsec/ipsec_proc.c

Regards
Ronen Shitrit

Marvell Semiconductor Israel Ltd (www.marvell.com)
rshitrit <at> marvell.com

_______________________________________________
Dev mailing list
Dev <at> openswan.org
http://lists.openswan.org/mailman/listinfo/dev