Message-ID: <ZuBD7TWOQ7huO7_7@hog>
Date: Tue, 10 Sep 2024 15:04:45 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Antonio Quartulli <antonio@...nvpn.net>
Cc: netdev@...r.kernel.org, kuba@...nel.org, pabeni@...hat.com,
	ryazanov.s.a@...il.com, edumazet@...gle.com, andrew@...n.ch
Subject: Re: [PATCH net-next v6 12/25] ovpn: implement packet processing

2024-09-06, 15:19:08 +0200, Antonio Quartulli wrote:
> On 04/09/2024 17:01, Sabrina Dubroca wrote:
> > 2024-09-04, 14:07:23 +0200, Antonio Quartulli wrote:
> > > On 02/09/2024 16:42, Sabrina Dubroca wrote:
> > > > 2024-08-27, 14:07:52 +0200, Antonio Quartulli wrote:
> > I can think of a few possibilities if this causes too many unwanted
> > drops:
> > 
> >   - use a linked list of keys, set the primary instead of swapping, and
> >     let delete remove the unused key(s) by ID instead of slot
> > 
> >   - decouple the TX and RX keys, which also means you don't really need
> >     to swap keys (swap for the TX key becomes "set primary", swap on RX
> >     can become a noop since you check both slots for the correct keyid)
> >     -- and here too delete becomes based on key ID
> > 
> >   - if cs->mutex becomes a spinlock, take it in the datapath when
> >     looking up keys. this will make sure we get a consistent view of
> >     the keys state.
> > 
> >   - come up with a scheme to let the datapath retry the key lookup if
> >     it didn't find the key it wanted (maybe something like a seqcount,
> >     or maybe taking the lock and retrying if the lookup failed)
> > 
> > I don't know if options 1 and 2 are possible based on how openvpn (the
> > protocol and the userspace application) models keys, but they seem a
> > bit "cleaner" on the datapath side (no locking, no retry). But they
> > require a different API.
> 
> After chewing over all these ideas I think we can summarize the requirements
> as follows:
> 
> * PRIMARY and SECONDARY in the API is just an abstraction for "KEY FOR TX"
> and "THE OTHER KEY";
> * SWAP means "mark for TX the key that currently was not marked";
> * we only need a pointer to the key for TX;
> * key for RX is picked up by key ID;
> 
> Therefore, how about having an array large enough to store all key IDs (max
> ID is 7):

Right, I forgot about that. For 8 keys, sure, array sounds ok. MACsec
has only 4 and I also implemented it as an array
(include/net/macsec.h: macsec_{tx,rx}_sc, sa array).

> * array index is the key ID (fast lookup on RX);
> * upon SET_KEY we store the provided keys and erase the rest;

I'm not sure about erasing the rest. If you're installing the
secondary ("next primary") key, you can't just erase the current
primary? ("erase the rest" also means you'd only ever have one key in
the array, which contradicts your last item in this list)

> * upon SET_KEY we store in a new field the index/ID of the PRIMARY (fast
> lookup on TX), namely primary_id;
> * upon SWAP we just save in primary_id the "other" index/ID;

I'm confused by these two. Both SET_KEY and SWAP modify the primary_id?

> * at any given time we will have only two keys in the array.

This needs to be enforced in the SET_KEY implementation, otherwise
SWAP will have inconsistent effects.


> It's pretty much like your option 1 and 2, but using an array
> indexed by key ID.

Are you decoupling TX and RX keys (so that they can be installed
independently) in this proposal? I can't really tell, the array could
be key pairs or separate.


> The concept of slot is a bit lost, but it is not important as long as we can
> keep the API and its semantics the same.

Would it be a problem for userspace to keep track of key IDs, and use
that (instead of slots) to communicate with the kernel? Make
setkey/delkey be based on keyid, and replace swap with a set_tx
operation which updates the current keyid for TX. That would seem like
a better API, especially for the per-ID array you're proposing
here. The concept of slots would be almost completely lost (only
"current tx key" is left, which is similar to the "primary slot").
(it becomes almost identical to the way MACsec does things, except
possibly that in MACsec the TX and RX keys are not paired at all, so
you can install/delete a TX key without touching any RX key)


Maybe you can also rework the current code to look a bit like this
array-based proposal, and not give up the notion of slots, if that's
something strongly built into the core of openvpn:

- primary/secondary in ovpn_crypto_state become slots[2]
- add a one-bit "primary" reference, used to look into the slots array
- swap just flips that "primary" bit
- TX uses slots[primary]
- RX keeps inspecting both slots (now slot[0] and slot[1] instead of
  primary/secondary) looking for the correct keyid
- setkey/delkey still operate on primary/secondary, but need to figure
  out whether slot[0] or slot[1] is primary/secondary based on
  ->primary

It's almost identical to the current code (and API), except you don't
need to reassign any pointers to swap keys, so it should avoid the
rekey issue.

-- 
Sabrina

Powered by blists - more mailing lists