[Swan] Decoding IPSEC_RESPONDER_LIFETIME

[Paul Wouters]

On Wed, 20 May 2015, heiko.helmle at horiba.com wrote:

> 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?

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.