[Swan-dev] pluto replying with both v2N_INVALID_KE_PAYLOAD then v2N_NO_PROPOSAL_CHOSEN?

Andrew Cagney andrew.cagney at gmail.com
Fri Jul 7 14:13:10 UTC 2017


In one of my test runs I noticed
interop-ikev2-strongswan-11-nat-initiator failed with road's
strongSwan reporting:

+parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
+received NO_PROPOSAL_CHOSEN notify error
+establishing connection 'road-eastnet-ikev2' failed

digging a little and it seems that east's pluto is consistently
responding with, in sequence:

- v2N_INVALID_KE_PAYLOAD (ok)
- v2N_NO_PROPOSAL_CHOSEN (huh)

For instance:

| accepted IKE proposal ikev2_proposal:
3:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_512;DH=MODP2048
| converting proposal to internal trans attrs
| encryption ike_alg_lookup_by_id id: AES_GCM_C=20, found aes_gcm_16
| PRF ike_alg_lookup_by_id id: HMAC_SHA2_512=7, found sha2_512
packet from 192.1.2.254:500: initiator guessed wrong keying material
group (CURVE25519); responding with INVALID_KE_PAYLOAD requesting
MODP2048
| sending INVALID_KE back with MODP2048(14)
packet from 192.1.2.254:500: sending unencrypted notification
v2N_INVALID_KE_PAYLOAD to 192.1.2.254:500
| **emit ISAKMP Message:
|    initiator cookie:
|   13 87 4a 1b  56 bd 74 ad
|    responder cookie:
|   00 00 00 00  00 00 00 00
|    next payload type: ISAKMP_NEXT_v2N (0x29)
|    ISAKMP version: IKEv2 version 2.0 (rfc4306/rfc5996) (0x20)
|    exchange type: ISAKMP_v2_SA_INIT (0x22)
|    flags: ISAKMP_FLAG_v2_MSG_RESPONSE (0x20)
|    message ID:  00 00 00 00
| Adding a v2N Payload
| ***emit IKEv2 Notify Payload:
|    next payload type: ISAKMP_NEXT_v2NONE (0x0)
|    flags: none (0x0)
|    Protocol ID: PROTO_v2_RESERVED (0x0)
|    SPI size: 0 (0x0)
|    Notify Message Type: v2N_INVALID_KE_PAYLOAD (0x11)
| emitting 2 raw bytes of Notify data into IKEv2 Notify Payload
| Notify data  00 0e
| emitting length of IKEv2 Notify Payload: 10
| padding IKEv1 message with 2 bytes
| emitting 2 zero bytes of message padding into ISAKMP Message
| emitting length of ISAKMP Message: 40
| sending 40 bytes for v2 notify through eth1:500 to 192.1.2.254:500 (using #0)
|   13 87 4a 1b  56 bd 74 ad  00 00 00 00  00 00 00 00
|   29 20 22 20  00 00 00 00  00 00 00 28  00 00 00 0a
|   00 00 00 11  00 0e 00 00
| #0 complete v2 state transition from STATE_UNDEFINED with
v2N_NO_PROPOSAL_CHOSEN
| sending a notification reply
packet from 192.1.2.254:500: sending unencrypted notification
v2N_NO_PROPOSAL_CHOSEN to 192.1.2.254:500
| **emit ISAKMP Message:
|    initiator cookie:
|   13 87 4a 1b  56 bd 74 ad
|    responder cookie:
|   00 00 00 00  00 00 00 00
|    next payload type: ISAKMP_NEXT_v2N (0x29)
|    ISAKMP version: IKEv2 version 2.0 (rfc4306/rfc5996) (0x20)
|    exchange type: ISAKMP_v2_SA_INIT (0x22)
|    flags: ISAKMP_FLAG_v2_MSG_RESPONSE (0x20)
|    message ID:  00 00 00 00
| Adding a v2N Payload
| ***emit IKEv2 Notify Payload:
|    next payload type: ISAKMP_NEXT_v2NONE (0x0)
|    flags: none (0x0)
|    Protocol ID: PROTO_v2_RESERVED (0x0)
|    SPI size: 0 (0x0)
|    Notify Message Type: v2N_NO_PROPOSAL_CHOSEN (0xe)
| emitting length of IKEv2 Notify Payload: 8
| no IKEv1 message padding required
| emitting length of ISAKMP Message: 36
| sending 36 bytes for v2 notify through eth1:500 to 192.1.2.254:500 (using #0)
|   13 87 4a 1b  56 bd 74 ad  00 00 00 00  00 00 00 00
|   29 20 22 20  00 00 00 00  00 00 00 24  00 00 00 08
|   00 00 00 0e
| state transition function for STATE_UNDEFINED failed: v2N_NO_PROPOSAL_CHOSEN

it seems to be related to c4c2c62a

Andrew

PS: the log http://testing.libreswan.org/results/v3.20-709-g8de1339-master/interop-ikev2-strongswan-11-nat-initiator/OUTPUT/east.pluto.log.bz2
shows the behaviour; look for INVALID_KE


More information about the Swan-dev mailing list