On Fri, 27 Sep 2019 at 15:04, Paul Wouters <[email protected]> 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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
