[Swan-dev] does the address pool really share leases?
paul at nohats.ca
Fri Sep 27 19:04:18 UTC 2019
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" ?
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
> - 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
> - 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:
but it would be a strange use of it. Because you could just rewrite that to:
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.
More information about the Swan-dev