[Swan-dev] ref-counting xfrmi interfaces

Brady Johnson bradyallenjohnson at gmail.com
Fri Mar 3 13:48:32 EET 2023


Ok, agreed it should be decoupled from updown.

I'm trying to determine where to store the ref counted IP addresses
(v4/v6). I could add it to the pluto_xfrmi struct
(kernel_xfrm_interface.c/h) but then that would not include VTI interfaces.
Everything related to creating VTI interfaces is performed in the updown
script. If we want to also refcount IPs for VTI interfaces, then perhaps
the best place to store it would be in connections.c/h?

If we just want to do this for XFRMI interfaces, then I could just add a
pointer to the following new struct to pluto_xfrmi (which would be a simple
linked list, similar to struct pluto_xfrmi) as follows:

struct pluto_ips {
    ip_address ip;
    refcnt_t refcnt;
    bool pluto_added;
    struct pluto_ips *next;
};


There is still the issue of how/where to remove the IP from the interface.
Currently this never happens, so should we do this in the updown script or
from Pluto? Considering the IP addresses are added to the interfaces in the
updown script, it seems logical to also remove them in the updown script.

Thoughts??

Regards,

Brady


On Thu, Mar 2, 2023 at 6:15 PM Paul Wouters <paul at nohats.ca> wrote:

> On Thu, 2 Mar 2023, Brady Johnson wrote:
>
> (CC:ing dev list, because why not)
>
> > I have started looking into how to ref count the IP addresses. It looks
> like currently the IP addresses are set on the interfaces in
> > the updown shell script with the "up-client" verb. Currently the
> addresses are never deleted from the interfaces. I verified this
> > when manually testing my previous patch.
> > To refcount when addresses are added, I could just add code to
> the do_updown() function in programs/pluto/updown.c. But for
> > deleting, I could also control that in the do_updown() function, but I
> guess I would also need to modify the updown script to
> > actually remove the IP from the interface.
> >
> > This is all on Linux with xfrmi/vti interfaces.
>
> It should not be too tightly coupled with "updown", because we are
> thinking of trying to make leftupdown= optional with a default to no,
> and move all the "standard" things into pluto.
>
> Most of the things we do in "updown" are related to IP addresses,
> routing and DNS settings. When we split DNS into its own helper, it
> avoids all those calls/checks when there is no need.
>
> Similarly, when no IP addresses are being removed / added or routes
> changed (or MTUs set via route changes), we hope to avoid calling
> updown (which is very expensive to call)
>
> Note also that updown as a "verb", giving it different meanings. It
> can be: up/down host, up/down client, up/down route. The route mostly
> stems from KLIPS that triggered the IPsec kernel code by routing into
> "ipsecX" interfaces. KLIPS was removed and usually those route calls
> are no longer needed.
>
> So while the locations where updown is called by pluto might be good
> spots to add your refcounting call, I wouldn't couple it too tightly
> to updown itself.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20230303/3bbe4916/attachment.htm>


More information about the Swan-dev mailing list