Same problem with algo-pluto-08 and fips-06-ikev1-3des-sha1
| From: D. Hugh Redelmeier <h...@mimosa.com>
| Subject: [Swan-dev] please fix ikev1-algo-05-3des-sha2
|
| Pluto log on east says:
|
| "westnet-eastnet-ipv4-psk-ikev1" #1: STATE_MAIN_R3: sent MR3, ISAKMP SA
established {auth=PRESHARED_KEY cipher=aes_256 integ=sha2_256 group=MODP2048}
| "westnet-eastnet-ipv4-psk-ikev1" #1: the peer proposed: 192.0.2.0/24:0/0 ->
192.0.1.0/24:0/0
| "westnet-eastnet-ipv4-psk-ikev1" #2: IPsec encryption transform rejected:
3DES_CBC key_len 0 is incorrect
| "westnet-eastnet-ipv4-psk-ikev1" #2: sending encrypted notification
BAD_PROPOSAL_SYNTAX to 192.1.2.45:500
|
| I think that the test is broken. But it might be that Pluto is
| broken. I guess that this is something that Andrew is best equipped
| to fix.
|
| Bonus points (not just for Andrew):
|
| (1) I assume that this notification was encrypted. But nothing about a
| notification shows up on west.console.diff.
|
| Should we not report authenticated notifications to whack? It is
| reported in Pluto's log on west:
|
| "westnet-eastnet-ipv4-psk-ikev1" #1: ignoring informational payload
BAD_PROPOSAL_SYNTAX, msgid=00000000, length=12
| | ISAKMP Notification Payload
| | 00 00 00 0c 00 00 00 01 01 00 00 0f
|
| (3) the message should make clear whether the informational payload
| was authenticated.
|
| (3) It would be nice of Pluto to report a decoded version of this
| payload to the user. That would help the user understand the problem.
|
| (4) It would probably be smart not to keep resending the same message
| when it is so very likely that the outcome will be identical.
| This isn't a bug so it isn't very important.
_______________________________________________
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
