> > >> >> 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. >
and of course long after the code was written, the suffixes were standardised by IEC et.al. ('99) and we're now meant to use GiB et.al. https://en.wikipedia.org/wiki/Binary_prefix :-) > >> >> >> 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 >> Swan-dev@lists.libreswan.org >> https://lists.libreswan.org/mailman/listinfo/swan-dev >> >
_______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev