On Sat, 27 Nov 2021 at 14:04, Antony Antony <[email protected]> wrote:
> 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:) There's readable_humber() but that would need work. Conversely is there something to convert things like 100gb back to bytes. > > > 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 > _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
