[Swan-dev] does the address pool really share leases?

[Andrew Cagney]

On Fri, 27 Sep 2019 at 15:04, Paul Wouters <paul at nohats.ca> wrote:
>
> On Thu, 26 Sep 2019, Andrew Cagney wrote:
>
> > I'm trying to understand shared leases - while the code gives the
> > impression that arbitrary connections can share leases I suspect that
> > isn't true.  Instead, I suspect there are two scenarios:
>
> I think you are mising up "shared lease" with "shared pool" ?

Unfortunately, no:

 *
 * Leases are shared between appropriate connections.
 *
static bool can_share_lease(const struct connection *c)

so I guess sharing but not as we know it

> Connections can share a single pool of leases. Each lease can only be
> handed out once, and is only potentially available to another connection
> instance of the same user (as identified by the user ID)
>
> > - where an SA shuts down (cleanly), so that the same lease might be
> > assigned when the SA later re-establishes, the id:lease pair
> > this doesn't involve sharing, but is only useful when leases can be
> > uniquely identified using the ID
>
> Yes, this is not "sharing" though. It is mostly just trying to give the
> same IP to the same user to try and prevent connections that were still
> open from breaking. Ideally, with things like MOBIKE, that would not
> happen.
>
> > - where a new CHILD SA is trying to steal an existing lease
> > . SAs establish with a lease assigned
> > . something goes wrong, an end starts bringing up a new SA and wants
> > to re-use the old lease (but it is still reserved by the old SA)
> > . since the IDs match the lease is shared
> > . when the new SA hits the kernel things get updated
> > . when the old SA gets zapped, the sharing stops
>
> Yes.
>
> > - is there anything else?
>
> I don't think so.
>
> > More generally, the second problem seems to have a lot in common with
> > connection instances - trying to pair up a new SA with an existing but
> > failing instance using the ID.  Can (shared) leases only be assigned
> > to connection instances and vice versa?
>
> In practise yes. In theory, a static client with left=ip, right=ip
> could use the client mechanism to request an IP(4 and/or 6) and get
> this from the addresspool? eg:
>
> conn test1
>         left=76.10.157.69
>         leftsubnet=0.0.0.0/0
>         right=1.2.3.5
>         rightaddresspool=10.100.1.1-10.100.1.3
>
> but it would be a strange use of it. Because you could just rewrite that to:
>
> conn test2
>         left=76.10.157.69
>         leftsubnet=0.0.0.0/0
>         right=1.2.3.5
>         rightsubnet=10.100.1.1/32
>
> A pool does kind of imply right=%any and instantiation. And if it helps
> you, I wouldn't mind failing to load the above conn test1.

I'll keep that in mind, but I don't think I need it.

The current code is maintaining, and constantly scanning, an ordered
linked list of assigned (and released) addresses.  With "shared
leases" I suspect the list grows until there's an entry for every
possible assigned address - consider 10.0.0.0/8.

By simply changing the list to an array (and doubled in size as
needed) I suspect most of this goes away (sprinkled with some lists,
and slightly more aggressive address reuse strategy, and a hash table
for ID->lease).  At least that's the theory.

Andrew