[Swan-dev] WIP: supporting xfrm SA expire

[Andrew Cagney]

On Sat, 27 Nov 2021 at 14:04, Antony Antony <antony at phenome.org> 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
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20211127/1cab862d/attachment.htm>