Was the test run with?
ikev2: only return STF_{OK,FAIL,FATAL} from CREATE_CHILD_SA processor
Not STF_FAIL+v2N. Fixes a sec_label core dump when the initiator gets
rejected.
Internally use v2_notification_t, mapping that onto the above (the
code will eventually need to send the notification to the responder as
part of a separate informational exchange. See 2.21. Error Handling).
the symptoms below look similar.
On Sun, 4 Jul 2021 at 22:13, Paul Wouters <p...@nohats.ca> wrote:
>
> I added two new testcases:
>
> ikev2-rw-multiple-subnets-4-mismatch (mismatch in CREATE_CHILD_SA_
> ikev2-rw-multiple-subnets-5-mismatch-frst (mismatch in IKE_AUTH)
>
> I ran the 4-mismatch test with mismatched subnets. That is the initiator
> has
> more subnets then responder. The first subnet matches, so IKE_AUTH
> completes. Then CREATE_CHILD_SA's are used for the further pending
> subnets.
>
With "pluto: When Child state fails, don't tear down IKE SA" reverted I see:
+003 "road/0x2" #3: dropping unexpected CREATE_CHILD_SA message containing
TS_UNACCEPTABLE notification; message payloads: SK; encrypted payloads: N;
missing payloads: SA,Ni,TSi,TSr
+036 "road/0x2" #3: encountered fatal error in state STATE_V2_NEW_CHILD_I1
which is a missing state transition. Likely fallout from the above.
> I observe:
>
> "road/0x4" #1: initiating IKEv2 connection
> "road/0x3": queuing pending IPsec SA negotiating with 192.1.2.23 IKE SA #1
> "road/0x4"
> "road/0x2": queuing pending IPsec SA negotiating with 192.1.2.23 IKE SA #1
> "road/0x4"
> "road/0x1": queuing pending IPsec SA negotiating with 192.1.2.23 IKE SA #1
> "road/0x4"
> "road/0x4" #1: sent IKE_SA_INIT request
> "road/0x4" #1: switching CHILD #2 to pending connection "road/0x1"
> "road/0x4" #1: sent IKE_AUTH request {auth=IKEv2 cipher=AES_GCM_16_256
> integ=n/a prf=HMAC_SHA2_512 group=MODP2048}
> "road/0x4" #1: authenticated using RSA with SHA2_512 and peer certificate
> 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, CN=
> east.testing.libreswan.org, E=user-e...@testing.libreswan.org' issued by
> CA 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department,
> CN=Libreswan test CA for mainca, E=test...@libreswan.org'
> "road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 0.5
> seconds for response
> "road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 1
> seconds for response
> "road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 2
> seconds for response
> "road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 4
> seconds for response
> "road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 8
> seconds for response
> "road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 16
> seconds for response
> "road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 32
> seconds for response
> "road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: 60 second timeout exceeded
> after 7 retransmits. No response (or no acceptable response) to our IKEv2
> message
> "road/0x4" #1: liveness action - putting connection into hold
> "road/0x4" #1: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 64.10909s
> and sending notification
> "road/0x4" #1: deleting IKE SA but connection is supposed to remain up;
> schedule EVENT_REVIVE_CONNS
>
>
And for this I see:
+003 "road/0x1" #2: IKE_AUTH response contained the error notification
TS_UNACCEPTABLE
+002 "road/0x4" #1: deleting other state #2 connection
(STATE_V2_IKE_AUTH_CHILD_I0) "road/0x1" and NOT sending notification
which is from this code:
v2_notification_t n = process_v2_IKE_AUTH_response_child_sa_payloads(ike,
md);
if (v2_notification_fatal(n)) {
/* already logged */
/*
* XXX: should be sending the fatal notification using
* a new exchange.
*/
return STF_FATAL;
} else if (n != v2N_NOTHING_WRONG) {
/* already logged */
/*
* XXX: should be sending the child failure
* notification using an additional exchange and then
* leaving the IKE SA up.
*
* Instead just wipe out the IKE family :-(
*/
return STF_V2_DELETE_EXCHANGE_INITIATOR_IKE_SA;
}
Like the comments point out, this is a hack. The fix means queueing up a
new exchange to send a delete notify with the SPI received from the
responder?
_______________________________________________
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
