<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 6 Apr 2021 at 11:51, 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">On Mon, Apr 05, 2021 at 01:22:39PM -0400, Paul Wouters wrote:<br>
> On Mon, 5 Apr 2021, Antony Antony wrote:<br>
> <br>
> > Here is my sa expire branch rebased to main.<br>
> > <br>
> > #sa-expire<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>
> Thanks! I had a look and I think it looks pretty good.<br>
> <br>
> > It need a bit more work to merge to main. I look the code again and fix<br>
> > "FIXME". It also need more tests.<br>
> > <br>
> > If you feel like helping add more tests. This would help to get the<br>
> > branch ready to merge sooner than later.<br>
> <br>
> I'm working on that now.<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>
> Similarly, where strongswan has inactivity= I think idletimeout= or<br>
> idle-timeout= would be more clear? I wouldn't call in inactive because<br>
> the tunnel is "active" (or "up") - there is just no traffic happening.<br>
<br>
I have no idea about those:)<br>
<br>
> I do understand why you added the "sa" prefix, because we in theory also<br>
> have these options on the IKE SA (for FIPS compliance), but I think<br>
<br>
I choose salifebytes because we already have "salifetime" I am not too <br>
attached to it. However, your proposals are not more appealing at the <br>
momet:) Lets see how this goes.<br>
<br>
My next proposals are "rekey-bytes" and "rekey-packets". Those would align <br>
with swanctl config. swanctl full name is <br>
<br>
connections.<conn>.children.<child>.rekey_bytes<br>
<br>
Do not compare to ancient strongswan pluto keywords.<br>
<br></blockquote><div><br></div><div>perhaps borrow terminology from setrlimit(2) which uses terms such as hard limit, soft limit, and maximum ...</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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>
> 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>
> 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 will look at adding some logging based on hitting soft and hard timer.<br>
> Right now, one just sees a rekey but there is no message as to why.<br>
<br>
> And I'll add an impair test that stalls and rekeying so we hit the hard<br>
> timer and see if we can distinguish that. Because we should delete the<br>
> SA if the hard timer was hit since the kernel already removed it in that<br>
> case.<br>
> <br>
> Thanks for the work on this! I'll send a PR later today against your<br>
> branch.<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>
-antony<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>