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.
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, [email protected]' issued by CA 'C=CA,
ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, CN=Libreswan test CA for mainca,
[email protected]'
"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
It shows in debug that road/0x4 repeatedly receives TS_UNACCEPTABLE.
It then _retransmits_ something, maybe the last packet, maybe not. It
should not retransmit when it got an answer. It just probably should
re-add the entry to the pending queue with exponential backoff.
Once it does that, it won't hit the code for "max retransmits" that
tears down everything under the asumption no one is answering any
IKE packets - they did answer, our code just didn't note that down.
I think perhaps the retransmit logic for IKEv1 and IKEv2 deserve to
be split up entirely.
Paul
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
