[strongSwan-dev] IKEv2 IKE_AUTH request not responded if assembling of previous fragmented request (retransmitted) is in progress
tiio vossi
tottiviljami at gmail.com
Wed Oct 28 08:31:08 CET 2020
Hi,
using a bit old Strongswan 5.6.0 as server and iOS clients with IKEv2 and
eap-radius. Following ipsec.conf:
conn ios_ikev2_with_auth
keyexchange=ikev2
left=%defaultroute
leftid="anonymized"
leftsubnet=0.0.0.0/0
leftcert=server.crt
leftsendcert=always
right=%any
rightsourceip=198.18.64.0/20
rightreassignafter=60
lifetime=80m
auto=add
rightauth=eap-radius
eap_identity=%identity
dpdaction=clear
forceencaps=yes
fragmentation=yes
ike="aes256gcm16-prfsha1-modp1536,aes256gcm16-prfsha1-modp2048"
esp="aes256gcm16,aes128gcm16"
and strongswan.conf:
charon {
threads = 16
interfaces_use = eth1
process_route = no
install_routes = no
load_modular = yes
plugins {
attr {
load = yes
dns = anonymized
}
eap-radius {
load = yes
accounting = yes
servers {
primary {
address = 127.0.0.1
secret = anonymized
auth_port = anonymized
acct_port = anonymized
sockets = 3
}
}
}
constraints {
load = yes
}
ctr {
load = yes
}
rc2 {
load = yes
}
md4 {
load = yes
}
unity {
load = yes
}
led {
load = yes
}
certexpire {
load = yes
csv {
}
}
gcrypt {
load = yes
}
random {
load = yes
}
revocation {
load = yes
}
cmac {
load = yes
}
x509 {
load = yes
}
test-vectors {
load = yes
}
aes {
load = yes
}
ccm {
load = yes
}
pubkey {
load = yes
}
error-notify {
load = yes
}
xcbc {
load = yes
}
af-alg {
load = yes
}
medcli {
load = yes
}
resolve {
load = yes
resolvconf {
}
}
farp {
load = yes
}
pkcs7 {
load = yes
}
hmac {
load = yes
}
updown {
load = yes
}
pkcs1 {
load = yes
}
pgp {
load = yes
}
dnskey {
load = yes
}
sshkey {
load = yes
}
xauth-generic {
load = yes
}
pem {
load = yes
}
pkcs12 {
load = yes
}
md5 {
load = yes
}
sha2 {
load = yes
}
nonce {
load = yes
}
kernel-netlink {
load = yes
}
gmp {
load = yes
}
dhcp {
load = yes
}
pkcs11 {
load = yes
modules {
}
}
tnc-tnccs {
load = yes
}
fips-prf {
load = yes
}
lookip {
load = yes
}
rdrand {
load = yes
}
openssl {
load = yes
}
xauth-noauth {
load = yes
}
gcm {
load = yes
}
addrblock {
load = yes
}
medsrv {
load = yes
}
curl {
load = yes
}
pkcs8 {
load = yes
}
sha1 {
load = yes
}
stroke {
load = yes
}
socket-default {
load = yes
}
eap-tls {
load = yes
}
eap-identity {
load = yes
}
}
}
Occasionally, if client is in a bad network, server side IKEv2 message
request/response state machine seems to go to state where it does not
respond to request it receives from client. Particularly it seems to occur
if the previous request is fragmented and has been already responded and
then receiving retransmission of already responded request only partially.
After that Strongswan server is not responding to next request coming from
client. Issue is quite hard to reproduce so providing all info mentioned in
https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests is a bit
difficult. Managed to get following logs from the situation:
1) Server receives request 7 in 3 fragments:
2020-10-26T09:57:57.816620+00:00 test-server charon: 14[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(540 bytes)
2020-10-26T09:57:57.817118+00:00 test-server charon: 14[ENC] parsed
IKE_AUTH request 7 [ EF(2/3) ]
2020-10-26T09:57:57.817531+00:00 test-server charon: 14[ENC] received
fragment #2 of 3, waiting for complete IKE message
2020-10-26T09:57:57.824152+00:00 test-server charon: 15[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(140 bytes)
2020-10-26T09:57:57.824779+00:00 test-server charon: 15[ENC] parsed
IKE_AUTH request 7 [ EF(3/3) ]
2020-10-26T09:57:57.825213+00:00 test-server charon: 15[ENC] received
fragment #3 of 3, waiting for complete IKE message
2020-10-26T09:57:58.816896+00:00 test-server charon: 16[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(540 bytes)
2020-10-26T09:57:58.817497+00:00 test-server charon: 16[ENC] parsed
IKE_AUTH request 7 [ EF(1/3) ]
2020-10-26T09:57:58.817953+00:00 test-server charon: 16[ENC] received
fragment #1 of 3, reassembling fragmented IKE message
2020-10-26T09:57:58.818381+00:00 test-server charon: 16[ENC] parsed
IKE_AUTH request 7 [ EAP/RES/TLS ]
2020-10-26T09:57:58.818788+00:00 test-server charon: 16[IKE] EAP_TLS
payload => 1024 bytes @ 0x7f47c4001770
2) Server sends response 7:
2020-10-26T09:57:58.847587+00:00 test-server charon: 16[ENC] generating
IKE_AUTH response 7 [ EAP/REQ/TLS ]
2020-10-26T09:57:58.848096+00:00 test-server charon: 16[NET] sending
packet: from <anonymized server ip>[4500] to <anonymized client ip>[4500]
(67 bytes)
3) Server receives request 7 again but fragment 1 is missing (server starts
waiting for fragment 1 or retransmission of request 7):
2020-10-26T09:57:58.848501+00:00 test-server charon: 08[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(540 bytes)
2020-10-26T09:57:58.848902+00:00 test-server charon: 08[ENC] parsed
IKE_AUTH request 7 [ EF(2/3) ]
2020-10-26T09:57:58.849298+00:00 test-server charon: 08[ENC] received
fragment #2 of 3, waiting for complete IKE message
2020-10-26T09:57:58.849698+00:00 test-server charon: 08[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(140 bytes)
2020-10-26T09:57:58.850093+00:00 test-server charon: 08[ENC] parsed
IKE_AUTH request 7 [ EF(3/3) ]
2020-10-26T09:57:58.850509+00:00 test-server charon: 08[ENC] received
fragment #3 of 3, waiting for complete IKE message
4) Server receives request 8 which means that client received response 7.
However, for some reason server is not responding to it.
2020-10-26T09:57:59.885632+00:00 test-server charon: 09[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(540 bytes)
2020-10-26T09:57:59.886200+00:00 test-server charon: 09[ENC] parsed
IKE_AUTH request 8 [ EF(1/2) ]
2020-10-26T09:57:59.886624+00:00 test-server charon: 10[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(308 bytes)
2020-10-26T09:57:59.887044+00:00 test-server charon: 10[ENC] parsed
IKE_AUTH request 8 [ EF(2/2) ]
2020-10-26T09:58:00.880421+00:00 test-server charon: 11[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(540 bytes)
2020-10-26T09:58:00.881109+00:00 test-server charon: 11[ENC] parsed
IKE_AUTH request 8 [ EF(1/2) ]
2020-10-26T09:58:00.888986+00:00 test-server charon: 12[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(308 bytes)
2020-10-26T09:58:00.889507+00:00 test-server charon: 12[ENC] parsed
IKE_AUTH request 8 [ EF(2/2) ]
5) Server keeps on receiving request 8 as client is resending it but server
is not responding at all, finally SA is deleted as negotiation does not
complete.
2020-10-26T09:58:02.890462+00:00 test-server charon: 14[ENC] parsed
IKE_AUTH request 8 [ EF(1/2) ]
2020-10-26T09:58:06.894558+00:00 test-server charon: 07[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(540 bytes)
2020-10-26T09:58:06.895142+00:00 test-server charon: 07[ENC] parsed
IKE_AUTH request 8 [ EF(1/2) ]
2020-10-26T09:58:06.895654+00:00 test-server charon: 09[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(308 bytes)
2020-10-26T09:58:06.896156+00:00 test-server charon: 09[ENC] parsed
IKE_AUTH request 8 [ EF(2/2) ]
2020-10-26T09:58:14.894535+00:00 test-server charon: 13[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(540 bytes)
2020-10-26T09:58:14.895174+00:00 test-server charon: 13[ENC] parsed
IKE_AUTH request 8 [ EF(1/2) ]
2020-10-26T09:58:14.903061+00:00 test-server charon: 14[NET] received
packet: from <anonymized client ip>[4500] to <anonymized server ip>[4500]
(308 bytes)
2020-10-26T09:58:14.903576+00:00 test-server charon: 14[ENC] parsed
IKE_AUTH request 8 [ EF(2/2) ]
2020-10-26T09:58:17.039947+00:00 test-server charon: 06[JOB] deleting half
open IKE_SA with <anonymized client ip> after timeout
According to IKEv2 spec (https://tools.ietf.org/html/rfc4306#section-2.1):
The responder MUST remember each
response until it receives a request whose sequence number is larger
than the sequence number in the response plus its window size
Not very familiar with the protocol details but based on the above spec
statement, strongswan should ignore incomplete second request 7 (at step 5)
as it already received the request with increased sequence number 8
(meaning that client must have received response 7).
Tried to also compare on code level Strongswan 5.9.0 and 5.6.0 differences
(especially in libcharon/sa/ikev2/task_manager_v2.c and
libcharon/encoding/message.c) and possible fixes for the issue but didn't
find anything which could help.
Does this look like Strongswan server issue or is iOS client doing
something wrong here?
Thanks,
Totti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20201028/94bf6f18/attachment-0001.html>
More information about the Dev
mailing list