[strongSwan] FW: Mail to Strongswan
prasobh.s25 at wipro.com
prasobh.s25 at wipro.com
Thu Sep 24 12:54:06 CEST 2015
Hello,
I have a query regarding the usage of "lifebytes" and "marginbytes" .
1) Is the soft bytes expiry ( due to lifebytes, marginbytes) handled in the same manner as soft time expiry ( due to keylife,margintime).
2) I read in another thread that a code segment is there in child_sa.c to prevent multiple rekey initiation due to soft time expiry. Does the same apply for soft bytes expiry ??
3) Is there any difference in :- rekeying getting initiated due to soft bytes expiry for outbound SA and rekeying getting initiated due to soft bytes expiry for Inbound SA.
Iam using Strongswan 5.0.0
Iam facing an issue of continuous rekeying getting initiated due to continuous receiving of "XFRM_MSG_EXPIRE" from kernel during soft bytes expiry.
The issue , strangely, happens from 2nd rekeying onwards. During the first rekeying everything is fine.
"ip -s xfrm state" output before and after rekeying due to soft bytes expiry is given below :-
root# ip -s xfrm state
src 60.60.60.3 dst 70.70.70.2
proto esp spi 0xc61f69dc(3323947484) reqid 1(0x00000001) mode tunnel
replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
auth-trunc hmac(sha1) 0xf24529a8d5eeb0f1b606c822d5d5b59ac2f66308 (160 bits) 96
enc cbc(aes) 0xab62a2a829ab5ce1f0e7c06859898521 (128 bits)
lifetime config:
limit: soft 89855(bytes), hard 102400(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 80272(sec), hard 86400(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
73480(bytes), 867(packets) < ---- Before Expiry
add 2014-11-12 10:21:19 use 2014-11-12 10:21:19
stats:
replay-window 0 replay 0 failed 0
src 70.70.70.2 dst 60.60.60.3
proto esp spi 0xc6a6a0ac(3332808876) reqid 1(0x00000001) mode tunnel
replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
auth-trunc hmac(sha1) 0x27684d5edc76ff2aa8483463a285ebf1bb9c9e3f (160 bits) 96
enc cbc(aes) 0xaa69a832a5081b7a70e4f51ef28d4155 (128 bits)
lifetime config:
limit: soft 85238(bytes), hard 102400(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 79325(sec), hard 86400(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
85040(bytes), 877(packets) < ---- Before Expiry
add 2014-11-12 10:21:19 use 2014-11-12 10:21:19
stats:
replay-window 0 replay 0 failed 0
root#
root# ip -s xfrm state
src 60.60.60.3 dst 70.70.70.2
proto esp spi 0xc1964f0d(3247853325) reqid 1(0x00000001) mode tunnel< ---- After Expiry-1 ( SPID has changed, rekey has happened)
replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
auth-trunc hmac(sha1) 0xb04c092c437cd7ccc7a83ef185a3e819fe4474b8 (160 bits) 96
enc cbc(aes) 0xcadf33240aaaa60fac6843192a07b8c4 (128 bits)
lifetime config:
limit: soft 86349(bytes), hard 102400(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 82479(sec), hard 86400(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
2880(bytes), 5(packets) < ---- After Expiry-1
add 2014-11-12 10:28:24 use 2014-11-12 10:28:24
stats:
replay-window 0 replay 0 failed 0
src 70.70.70.2 dst 60.60.60.3
proto esp spi 0xcd6a7881(3446306945) reqid 1(0x00000001) mode tunnel< ---- After Expiry-1 ( SPID has changed, rekey has happened)
replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
auth-trunc hmac(sha1) 0x056ad13248c1f20989f5f0ef3bfed7503b69ae26 (160 bits) 96
enc cbc(aes) 0xdcffb61a4bbc7993e11ac3d8281d90ca (128 bits)
lifetime config:
limit: soft 87884(bytes), hard 102400(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 81655(sec), hard 86400(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
54428(bytes), 50(packets) < ---- After Expiry-1
add 2014-11-12 10:28:24 use 2014-11-12 10:28:24
stats:
replay-window 0 replay 0 failed 3
root#
root# ip -s xfrm state
src 60.60.60.3 dst 70.70.70.2
proto esp spi 0xcf8b0939(3481995577) reqid 1(0x00000001) mode tunnel < ---- After Expiry-2 ( SPID has changed, rekey has happened again in 1-2 seconds)
replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
auth-trunc hmac(sha1) 0xd3c489168a8c6d575a8bc595b5e52bd2356a2178 (160 bits) 96
enc cbc(aes) 0xc682d48bd79e0dad1c1d405065563a55 (128 bits)
lifetime config:
limit: soft 85919(bytes), hard 102400(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 82004(sec), hard 86400(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
0(bytes), 0(packets) < ---- After Expiry-2
add 2014-11-12 10:28:26 use -
stats:
replay-window 0 replay 0 failed 0
src 70.70.70.2 dst 60.60.60.3
proto esp spi 0xcda07a90(3449846416) reqid 1(0x00000001) mode tunnel< ---- After Expiry-2 ( SPID has changed, rekey has happened again in 1-2 seconds)
replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
auth-trunc hmac(sha1) 0x05478f2f33f603a2dd97bc2c96ec3471e6b1e3d2 (160 bits) 96
enc cbc(aes) 0x2fa1422441f1463ee8bf40e47eba8890 (128 bits)
lifetime config:
limit: soft 86839(bytes), hard 102400(bytes)
limit: soft (INF)(packets), hard (INF)(packets)
expire add: soft 81297(sec), hard 86400(sec)
expire use: soft 0(sec), hard 0(sec)
lifetime current:
39828(bytes), 42(packets) < ---- After Expiry-2
add 2014-11-12 10:28:26 use 2014-11-12 10:28:26
stats:
replay-window 0 replay 0 failed 5
"ip -s xfrm state" outputs for After Expiry-1 and After Expiry-2 were captured in 1-2 second interval. How does the lifetime current bytes count reach such high values of 54428 and 39828 all of a sudden
during rekeying. Rekeying is getting initiated due to such erroneous byte count after rekeying I think.
The issue is faced only during soft bytes expiry and not during soft time expiry.
Please help if anyone has a clue.
Thanks and Regards,
Prasobh
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150924/df2b8c24/attachment-0001.html>
More information about the Users
mailing list