[Swan] Decoding IPSEC_RESPONDER_LIFETIME

[h***@horiba.com]

Hello list,

I have to communicate to a cisco peer that seems to disagree on lifetimes
- it sends informational payload IPSEC_RESPONDER_LIFETIME and sometimes
just deletes SAs and then ignores any further attempts to reestablish,
resulting in a stale ISAKMP. That means I have to --down and --up the
connection to force a new Phase 1.

I'm suspecting that thie IPSEC_RESPONDER_LIFETIME might contain
information that brings me closer to getting this connection stable -
unfortunately I cannot do anything with the payload:

May 20 12:06:40 millhouse pluto[1584]: | ISAKMP Notification Payload
May 20 12:06:40 millhouse pluto[1584]: | 00 00 00 1c 00 00 00 01 03 04
60 00

How do I interpret those values? Or do I have to enable debug logging to
see what Lifetime the Cisco sends?

And in a related question: My peer seems to have enabled some sort of
inactivity (or idle) timeout. Does LibreSWAN have a similar feature? Or
will auto=ondemand suffice once the SAs have timed out?

Best Regards
Heiko Helmle

[Paul Wouters]

I have to communicate to a cisco peer that seems to disagree on lifetimes - it sends informational payload IPSEC_RESPONDER_LIFETIME and
sometimes just deletes SAs and then ignores any further attempts to reestablish, resulting in a stale ISAKMP. That means I have to --down
and --up the connection to force a new Phase 1.
I'm suspecting that thie IPSEC_RESPONDER_LIFETIME might contain information that brings me closer to getting this connection stable -
May 20 12:06:40 millhouse pluto[1584]: | ISAKMP Notification Payload
May 20 12:06:40 millhouse pluto[1584]: |   00 00 00 1c  00 00 00 01  03 04 60 00
How do I interpret those values? Or do I have to enable debug logging to see what Lifetime the Cisco sends?

I guess we should really parse those payloads. See

https://tools.ietf.org/html/rfc2407#section-4.5.2

https://tools.ietf.org/html/rfc2408#section-3.3

and the attribute registry at
https://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml#isakmp-registry-13

Note you might need to convert network order to host order of that byte
stream.

So from my head, probably completely wrong type of before coffee
calculation, that could be lifetime in seconds (00 00 00 01) for
1c00 seconds, aka 7168 seconds, prob 7200 (2h) when it started?

And in a related question: My peer seems to have enabled some sort of inactivity (or idle) timeout. Does LibreSWAN have a similar feature?
Or will auto=ondemand suffice once the SAs have timed out?

Not currently. It is on the radar though. We can already ask the kernel
about SA activity, and I believe we could even tell the kernel to let
us know when it is idle via the "soft use" parameter (on xfrm/netlink
anyway)

Paul
ps. pet peeve: It is "Libreswan" or "libreswan", not "LibreSWAN" - SWAN is a trademark of RSA Inc.

[h***@horiba.com]

Post by Paul Wouters
So from my head, probably completely wrong type of before coffee
calculation, that could be lifetime in seconds (00 00 00 01) for
1c00 seconds, aka 7168 seconds, prob 7200 (2h) when it started?

Well the message comes in during the initial Phase 1 - so it might be that
Cisco defaults to something like 7168 seconds?
Peer admin configured 28800s on the GUI, but I couldn't find out what
phase.

well... what phase is IPSEC_RESPONDER_LIFETIME related to? ikelifetime or
salifetime?

I experimented and reduced both to 1800s. That at least takes the pressure
from me babysitting the connection - but still the peer seems to throw the
phase 1 away and Libreswan doesn't seem to notice, resulting in a broken
tunnel...

000 State list:
000
000 #54: "remote":4500 STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_EXPIRE in 144s; lastdpd=938s(seq in:0 out:0); idle; import:local
rekey
000 #63: "remote":4500 STATE_QUICK_I1 (sent QI1, expecting QR1);
EVENT_v1_RETRANSMIT in 6s; lastdpd=-1s(seq in:0 out:0); idle; import:local
rekey
000 #61: "remote":4500 STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 57s; newest ISAKMP; lastdpd=300s(seq in:0 out:0);
idle; import:local rekey

with a dpdtimeout of 120 - shouldn't Libreswan have thrown away those (#54
and #61)? Or does DPD only work on Phase 2?

Post by Paul Wouters
ps. pet peeve: It is "Libreswan" or "libreswan", not "LibreSWAN" -
SWAN is a trademark of RSA Inc.

I'll try to remember that :)

Best Regards
Heiko Helmle

[Lennart Sorensen]

Post by h***@horiba.com

Post by Paul Wouters
So from my head, probably completely wrong type of before coffee
calculation, that could be lifetime in seconds (00 00 00 01) for
1c00 seconds, aka 7168 seconds, prob 7200 (2h) when it started?

Well the message comes in during the initial Phase 1 - so it might be that
Cisco defaults to something like 7168 seconds?
Peer admin configured 28800s on the GUI, but I couldn't find out what
phase.
well... what phase is IPSEC_RESPONDER_LIFETIME related to? ikelifetime or
salifetime?
I experimented and reduced both to 1800s. That at least takes the pressure
from me babysitting the connection - but still the peer seems to throw the
phase 1 away and Libreswan doesn't seem to notice, resulting in a broken
tunnel...
000
000 #54: "remote":4500 STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_EXPIRE in 144s; lastdpd=938s(seq in:0 out:0); idle; import:local
rekey
000 #63: "remote":4500 STATE_QUICK_I1 (sent QI1, expecting QR1);
EVENT_v1_RETRANSMIT in 6s; lastdpd=-1s(seq in:0 out:0); idle; import:local
rekey
000 #61: "remote":4500 STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 57s; newest ISAKMP; lastdpd=300s(seq in:0 out:0);
idle; import:local rekey
with a dpdtimeout of 120 - shouldn't Libreswan have thrown away those (#54
and #61)? Or does DPD only work on Phase 2?

Post by Paul Wouters
ps. pet peeve: It is "Libreswan" or "libreswan", not "LibreSWAN" -
SWAN is a trademark of RSA Inc.

I'll try to remember that :)

http://www.freeswan.org/credits.html says it is S/WAN not SWAN that is
trademark by RSA.