[Swan-dev] WIP: supporting xfrm SA expire

[Paul Wouters]

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