[Swan-dev] WIP: supporting xfrm SA expire

[Antony Antony]

Hi,
I rebased this branch and improved expire handling.

#sa-expire or #sa-expire-20211127
https://github.com/antonyantony/libreswan/tree/sa-expire

I renamed keywords to salifebytes= salifepackets= 

added few basic checks to avoid corner cases those netlink calls will return error:
 - do not send delete request to kernel for a "hard" expired SA (one directional). xfrm already deleted it.
 - do not query traffic,  get_sa_info() in delete_state() on hard expired SA
When there is expire store the last known traffic.
Also added fuzzing to soft bytes, and packet limits using c->sa_rekey_fuzz.

At the moment I am leaving the responder with hard expire == soft expire.
I want give preference to initiator. I will change the responder soft limit 
calculation. I am still trying to come up with a simple calculation.
Ideally the inititiator should trigger the rekey first. If both sides have 
the same softlimit, both sides will trigger rekey on the same packet.
It would lead to extra SA. That is why it is important to have initiator 
value entirely less than the responder values.

One thing decide as group is how to represent big number (2^64) bytes and 
packets, especially the default 2^64  will appear in "ipsec status:  
output.
 18446744073709551615 look ugly:) 

tests that log "ipsec status" output will get a diff:

-000 "west":   ike_life: 28800s; ipsec_life: 28800s; replay_window: 128; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;
+000 "west":   ike_life: 28800s; ipsec_life: 28800s; replay_window: 128; rekey_margin: 540s; rekey_fuzz: 100%; ipsec_life_bytes 18446744073709551615; 
ipsec_life_packets 18446744073709551615; keyingtries: 0;

I see three choices to represent 18446744073709551615.

1.  ipsec_life_bytes: 2^64;

2. ipsec_life_bytes: 18E( it is 18.4467441 Exabytes)  18E would be an 
approximation.

3. ipsec_life_bytes: INF
"ip xfrm state" output use INF to represet 2^64.  
e.g "limit: soft (INF)(packets), hard (INF)(packets)"

any preferences?

regards,
-antony

On Tue, Apr 06, 2021 at 02:38:08PM -0400, Paul Wouters wrote:
> On Tue, 6 Apr 2021, Antony Antony wrote:
> 
> > > I noticed you used salifebytes= and salifepackets=. I think it would be
> > > more intuitive to call these maxbytes= and maxpackets. Or limit-bytes=
> > > or bytelimit= and packet-limit= ?
> > 
> > given that we have "salifetime" for IPsec and "lifetime" from IKE
> > I feel life* would be better choce, so I choose salifebytes salifepackets.
> 
> Yes, it makes sense as a consistent choice. I'm just trying to think of
> the meaning of things for mortal end users :)
> 
> > My next proposals are "rekey-bytes" and "rekey-packets". Those would align
> 
> But rekey might not be the action. But it does show better than "maxFOO"
> to explain what will happen. So I also understand why those terms were
> used by them.
> 
> > > those maximums could just be hardcoded to a much lower count and might
> > > never need to be user configurable? Like wouldn't 1Gbyte of IKE
> > > traffic be a good time to re-auth or rekey-with-pfs ? In which case it
> > 
> > well with Post Quantuam and PCPU I can imagine conerns abou IKE rekey on the
> > horizon.
> 
> We already have this formally with FIPS requirements. Sure, I don't
> think it is realistic to ever reach 2^16 IKE bytes, but we have to
> rekey before that happens :)
> 
> I know I added code a long time ago to check the number of IKE bytes
> that have happened, but I don't think we act on it. We expect you would
> see issues with 2^16 IKE bytes in 1h (or since recently, 8h)
> 
> > > might make sense to omit the "sa" prefix for the regular admin?
> > 
> > again, what about "salifetime" are you going change that.
> 
> the word "lifetime" is an english word. It suggests a start and end of
> life. It suggests a unit of time. But lifepackets or lifebytes does not
> exist as english word. As for the "sa" prefix, no other IPsec SA
> options have this prefix. It is usually clear from the context if it
> relates to IKE or IPsec. The lifetime/salifetime/ikelifeime was so
> far the only one that applied to both.
> 
> Anyway, if we can't come up with better names, salifebytes/salifepackets
> will do.
> 
> > > I'm glad to see you decided on configuring soft timeouts at a fixed (80%)
> > > rate of hard limits. I was also hoping to not have an option for this.
> > 
> > I did it because I am lazy to code! I am not proud of it. I hope that one
> > day we will support soft and hard limits. I clearly see benfits of the
> > flexibilty. Especially if we want to be more of reference implementation.
> 
> I'm still trying to not give users more options then needed. Yes, it is
> cheap to add soft/hard variant keywords and to set it for the kernel.
> But hard limits are things that a properly configured system should
> never reach, and an admin should never need to think about what soft
> limit they need to set with enough safety margin to avoid hitting the
> specified hard limit.
> 
> > At the moment I am only looking for test case PR. That is my work flow at
> > the moment! I just noticed you send a PR with tests I will see what I can
> > pickup. Thanks.
> 
> Feel free to close the PR if it does not work for you.
> 
> I'll continue working on my branch on code and testing. Feel free to
> pick up only testing commits. They will always be seperate from code
> commits.
> 
> Paul