<div dir="ltr"><div dir="ltr"><div>Was the test run with?</div><br><div> ikev2: only return STF_{OK,FAIL,FATAL} from CREATE_CHILD_SA processor<br> <br> Not STF_FAIL+v2N. Fixes a sec_label core dump when the initiator gets<br> rejected.<br> <br> Internally use v2_notification_t, mapping that onto the above (the<br> code will eventually need to send the notification to the responder as<br> part of a separate informational exchange. See 2.21. Error Handling).</div><div><br></div><div>the symptoms below look similar.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 4 Jul 2021 at 22:13, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I added two new testcases:<br>
<br>
ikev2-rw-multiple-subnets-4-mismatch (mismatch in CREATE_CHILD_SA_<br>
ikev2-rw-multiple-subnets-5-mismatch-frst (mismatch in IKE_AUTH)<br>
<br>
I ran the 4-mismatch test with mismatched subnets. That is the initiator has<br>
more subnets then responder. The first subnet matches, so IKE_AUTH<br>
completes. Then CREATE_CHILD_SA's are used for the further pending<br>
subnets.<br></blockquote><div><br></div><div>With "pluto: When Child state fails, don't tear down IKE SA" reverted I see:</div><div><br>+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<br>+036 "road/0x2" #3: encountered fatal error in state STATE_V2_NEW_CHILD_I1</div><div><br></div><div>which is a missing state transition. Likely fallout from the above.<br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I observe:<br>
<br>
"road/0x4" #1: initiating IKEv2 connection<br>
"road/0x3": queuing pending IPsec SA negotiating with 192.1.2.23 IKE SA #1 "road/0x4"<br>
"road/0x2": queuing pending IPsec SA negotiating with 192.1.2.23 IKE SA #1 "road/0x4"<br>
"road/0x1": queuing pending IPsec SA negotiating with 192.1.2.23 IKE SA #1 "road/0x4"<br>
"road/0x4" #1: sent IKE_SA_INIT request<br>
"road/0x4" #1: switching CHILD #2 to pending connection "road/0x1"<br>
"road/0x4" #1: sent IKE_AUTH request {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048}<br>
"road/0x4" #1: authenticated using RSA with SHA2_512 and peer certificate 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, CN=<a href="http://east.testing.libreswan.org" rel="noreferrer" target="_blank">east.testing.libreswan.org</a>, E=<a href="mailto:user-east@testing.libreswan.org" target="_blank">user-east@testing.libreswan.org</a>' issued by CA 'C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, CN=Libreswan test CA for mainca, E=<a href="mailto:testing@libreswan.org" target="_blank">testing@libreswan.org</a>'<br>
"road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 0.5 seconds for response<br>
"road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 1 seconds for response<br>
"road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 2 seconds for response<br>
"road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 4 seconds for response<br>
"road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 8 seconds for response<br>
"road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 16 seconds for response<br>
"road/0x4" #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 32 seconds for response<br>
"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<br>
"road/0x4" #1: liveness action - putting connection into hold<br>
"road/0x4" #1: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 64.10909s and sending notification<br>
"road/0x4" #1: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS<br>
<br></blockquote><div><br></div><div>And for this I see:</div><div><br>+003 "road/0x1" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLE<br>+002 "road/0x4" #1: deleting other state #2 connection (STATE_V2_IKE_AUTH_CHILD_I0) "road/0x1" and NOT sending notification<br></div><div><br></div><div>which is from this code:</div><div><br></div><div style="margin-left:40px"> v2_notification_t n = process_v2_IKE_AUTH_response_child_sa_payloads(ike, md);<br> if (v2_notification_fatal(n)) {<br></div><div style="margin-left:40px"><div style="margin-left:40px"> /* already logged */<br> /*<br> * XXX: should be sending the fatal notification using<br> * a new exchange.<br> */<br> return STF_FATAL;<br></div></div><div style="margin-left:40px"> } else if (n != v2N_NOTHING_WRONG) {<br></div><div style="margin-left:40px"><div style="margin-left:40px"> /* already logged */<br> /*<br> * XXX: should be sending the child failure<br> * notification using an additional exchange and then<br> * leaving the IKE SA up.<br> *<br> * Instead just wipe out the IKE family :-(<br> */<br> return STF_V2_DELETE_EXCHANGE_INITIATOR_IKE_SA;<br></div></div><div style="margin-left:40px"> }</div></div><div class="gmail_quote"><br></div><div>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?<br></div><div><br></div></div>