[Openswan dev] Pluto esp transform selection behaviour

[Frank Schmirler]

Hi,

sorry for my late reply. I was very busy last week :(

On Sat, 28 Apr 2007 17:14:36 -0400, Michael Richardson wrote
> Test case algo-pluto-05 (why I have tests named pluto-algo and
> algo-pluto, I don't know) has just been created.
> 
> I can not confirm your report. Perhaps I missed the details, that's why
> I asked for a test case.

In algo-pluto-05 you only check the ike= parameter. My problem is with the
esp= parameter. All tests from algo-pluto-05 use esp=aes256-sha1. I updated
the configs. You will get problems with the following test:

Run eastrun2.sh (east restricted to 3des) and the following tests will fail:
west:~# ipsec auto --up westnet-eastnet-both
west:~# ipsec auto --up westnet-eastnet-default

Run eastrun3.sh (east restricted to aes) and you will get problems with:
west:~# ipsec auto --up westnet-eastnet-two

Sample pluto log from east:
"westnet-eastnet-3des" #8: IPsec Transform [ESP_AES (256),
AUTH_ALGORITHM_HMAC_SHA1] refused due to strict flag
"westnet-eastnet-3des" #8: no acceptable Proposal in IPsec SA

> Note that I did find an anomaly.

Let's see:
> west:~# : east set up for only 3des, so expect 3des
> west:~# ipsec auto --replace  westnet-eastnet-both
> west:~# ipsec auto --up  westnet-eastnet-both
> 104 "westnet-eastnet-both" #7: STATE_MAIN_I1: initiate
> 003 "westnet-eastnet-both" #7: received Vendor ID payload [Openswan
> 003 "westnet-eastnet-both" #7: received Vendor ID payload [Dead Peer Detection] 
> 106 "westnet-eastnet-both" #7: STATE_MAIN_I2: sent MI2, expecting MR2
> 108 "westnet-eastnet-both" #7: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "westnet-eastnet-both" #7: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_RSA_SIG cipher=aes_256 prf=oakley_sha group=modp2048}

Unable to reproduce this here (openswan 2.4.7). I get 3des as expected.

And what about this one:

> west:~# : east set up for both, expect 3des, since it has priority
> west:~# ipsec auto --replace  westnet-eastnet-both
> west:~# ipsec auto --up       westnet-eastnet-both
> 104 "westnet-eastnet-both" #11: STATE_MAIN_I1: initiate 
> 003 "westnet-eastnet-both" #11: received Vendor ID payload [Openswan 
> 003 "westnet-eastnet-both" #11: received Vendor ID payload [Dead Peer Detection]
> 106 "westnet-eastnet-both" #11: STATE_MAIN_I2: sent MI2, expecting MR2
> 108 "westnet-eastnet-both" #11: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "westnet-eastnet-both" #11: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_RSA_SIG cipher=aes_256 prf=oakley_sha group=modp2048}

West prefers aes, East prefers 3des. Plutos transform selection code is
straightforward. It selects the first matching algorithm which is aes. I think
this is ok. Do the RFCs require a different behaviour?

> Please see the 2.5.00 git tree for the details of the test, this is the
> log output:

Guess something's broken on my side?

cg-clone http://git.openswan.org/public/scm/openswan.git/ openswan-2
defaulting to local storage area
http://git.openswan.org/public/scm/openswan.git/refs/heads/master:
14:13:39 ERROR 404: Not Found.
http://git.openswan.org/public/scm/openswan.git/heads/master:
14:13:39 ERROR 404: Not Found.
14:13:39 URL:http://git.openswan.org/public/scm/openswan.git/HEAD [41/41] ->
"refs/heads/origin" [1]
error: File af6d54c00d95a81cf9a253ea5d3630006f3e95b8
(http://git.openswan.org/public/scm/openswan.git/objects/af/6d54c00d95a81cf9a253ea5d3630006f3e95b8)
corrupt

Cannot obtain needed commit af6d54c00d95a81cf9a253ea5d3630006f3e95b8
while processing commit 0000000000000000000000000000000000000000.
error: cannot map sha1 file af6d54c00d95a81cf9a253ea5d3630006f3e95b8
cg-pull: objects pull failed
cg-init: pull failed


Cheers,
Frank
-------------- next part --------------
A non-text attachment was scrubbed...
Name: east.conf
Type: application/octet-stream
Size: 808 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20070508/2e28da96/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 970 bytes
Desc: not available
Url : http://lists.openswan.org/pipermail/dev/attachments/20070508/2e28da96/attachment-0001.obj