<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 27 Nov 2021 at 14:04, Antony Antony <<a href="mailto:antony@phenome.org">antony@phenome.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
I rebased this branch and improved expire handling.<br>
<br>
#sa-expire or #sa-expire-20211127<br>
<a href="https://github.com/antonyantony/libreswan/tree/sa-expire" rel="noreferrer" target="_blank">https://github.com/antonyantony/libreswan/tree/sa-expire</a><br>
<br>
I renamed keywords to salifebytes= salifepackets= <br>
<br>
added few basic checks to avoid corner cases those netlink calls will return error:<br>
 - do not send delete request to kernel for a "hard" expired SA (one directional). xfrm already deleted it.<br>
 - do not query traffic,  get_sa_info() in delete_state() on hard expired SA<br>
When there is expire store the last known traffic.<br>
Also added fuzzing to soft bytes, and packet limits using c->sa_rekey_fuzz.<br>
<br>
At the moment I am leaving the responder with hard expire == soft expire.<br>
I want give preference to initiator. I will change the responder soft limit <br>
calculation. I am still trying to come up with a simple calculation.<br>
Ideally the inititiator should trigger the rekey first. If both sides have <br>
the same softlimit, both sides will trigger rekey on the same packet.<br>
It would lead to extra SA. That is why it is important to have initiator <br>
value entirely less than the responder values.<br>
<br>
One thing decide as group is how to represent big number (2^64) bytes and <br>
packets, especially the default 2^64  will appear in "ipsec status:  <br>
output.<br>
 18446744073709551615 look ugly:)</blockquote><div><br></div><div>There's readable_humber() but that would need work.</div><div>Conversely is there something to convert things like 100gb back to bytes.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
<br>
tests that log "ipsec status" output will get a diff:<br>
<br>
-000 "west":   ike_life: 28800s; ipsec_life: 28800s; replay_window: 128; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;<br>
+000 "west":   ike_life: 28800s; ipsec_life: 28800s; replay_window: 128; rekey_margin: 540s; rekey_fuzz: 100%; ipsec_life_bytes 18446744073709551615; <br>
ipsec_life_packets 18446744073709551615; keyingtries: 0;<br>
<br>
I see three choices to represent 18446744073709551615.<br>
<br>
1.  ipsec_life_bytes: 2^64;<br>
<br>
2. ipsec_life_bytes: 18E( it is 18.4467441 Exabytes)  18E would be an <br>
approximation.<br>
<br>
3. ipsec_life_bytes: INF<br>
"ip xfrm state" output use INF to represet 2^64.  <br>
e.g "limit: soft (INF)(packets), hard (INF)(packets)"<br>
<br>
any preferences?<br>
<br>
regards,<br>
-antony<br>
<br>
On Tue, Apr 06, 2021 at 02:38:08PM -0400, Paul Wouters wrote:<br>
> On Tue, 6 Apr 2021, Antony Antony wrote:<br>
> <br>
> > > I noticed you used salifebytes= and salifepackets=. I think it would be<br>
> > > more intuitive to call these maxbytes= and maxpackets. Or limit-bytes=<br>
> > > or bytelimit= and packet-limit= ?<br>
> > <br>
> > given that we have "salifetime" for IPsec and "lifetime" from IKE<br>
> > I feel life* would be better choce, so I choose salifebytes salifepackets.<br>
> <br>
> Yes, it makes sense as a consistent choice. I'm just trying to think of<br>
> the meaning of things for mortal end users :)<br>
> <br>
> > My next proposals are "rekey-bytes" and "rekey-packets". Those would align<br>
> <br>
> But rekey might not be the action. But it does show better than "maxFOO"<br>
> to explain what will happen. So I also understand why those terms were<br>
> used by them.<br>
> <br>
> > > those maximums could just be hardcoded to a much lower count and might<br>
> > > never need to be user configurable? Like wouldn't 1Gbyte of IKE<br>
> > > traffic be a good time to re-auth or rekey-with-pfs ? In which case it<br>
> > <br>
> > well with Post Quantuam and PCPU I can imagine conerns abou IKE rekey on the<br>
> > horizon.<br>
> <br>
> We already have this formally with FIPS requirements. Sure, I don't<br>
> think it is realistic to ever reach 2^16 IKE bytes, but we have to<br>
> rekey before that happens :)<br>
> <br>
> I know I added code a long time ago to check the number of IKE bytes<br>
> that have happened, but I don't think we act on it. We expect you would<br>
> see issues with 2^16 IKE bytes in 1h (or since recently, 8h)<br>
> <br>
> > > might make sense to omit the "sa" prefix for the regular admin?<br>
> > <br>
> > again, what about "salifetime" are you going change that.<br>
> <br>
> the word "lifetime" is an english word. It suggests a start and end of<br>
> life. It suggests a unit of time. But lifepackets or lifebytes does not<br>
> exist as english word. As for the "sa" prefix, no other IPsec SA<br>
> options have this prefix. It is usually clear from the context if it<br>
> relates to IKE or IPsec. The lifetime/salifetime/ikelifeime was so<br>
> far the only one that applied to both.<br>
> <br>
> Anyway, if we can't come up with better names, salifebytes/salifepackets<br>
> will do.<br>
> <br>
> > > I'm glad to see you decided on configuring soft timeouts at a fixed (80%)<br>
> > > rate of hard limits. I was also hoping to not have an option for this.<br>
> > <br>
> > I did it because I am lazy to code! I am not proud of it. I hope that one<br>
> > day we will support soft and hard limits. I clearly see benfits of the<br>
> > flexibilty. Especially if we want to be more of reference implementation.<br>
> <br>
> I'm still trying to not give users more options then needed. Yes, it is<br>
> cheap to add soft/hard variant keywords and to set it for the kernel.<br>
> But hard limits are things that a properly configured system should<br>
> never reach, and an admin should never need to think about what soft<br>
> limit they need to set with enough safety margin to avoid hitting the<br>
> specified hard limit.<br>
> <br>
> > At the moment I am only looking for test case PR. That is my work flow at<br>
> > the moment! I just noticed you send a PR with tests I will see what I can<br>
> > pickup. Thanks.<br>
> <br>
> Feel free to close the PR if it does not work for you.<br>
> <br>
> I'll continue working on my branch on code and testing. Feel free to<br>
> pick up only testing commits. They will always be seperate from code<br>
> commits.<br>
> <br>
> Paul<br>
_______________________________________________<br>
Swan-dev mailing list<br>
<a href="mailto:Swan-dev@lists.libreswan.org" target="_blank">Swan-dev@lists.libreswan.org</a><br>
<a href="https://lists.libreswan.org/mailman/listinfo/swan-dev" rel="noreferrer" target="_blank">https://lists.libreswan.org/mailman/listinfo/swan-dev</a><br>
</blockquote></div></div>