[Swan-dev] ref-counting xfrmi interfaces

Antony Antony antony at phenome.org
Mon Mar 6 20:03:23 EET 2023


On Fri, Mar 03, 2023 at 12:48:32PM +0100, Brady Johnson wrote:
> 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;

Is there a prefix length in struct ip_address? I didn't see one one in a 
quick look! I thingk pluto has one with prefix length. I imagine use case 
10.0.0.1/24 and 10.0.0.1/16 on the same xfrmi from two different 
connections. If you are not going to support that initialy
atleast add error or a log message.

Also what would happen when the interface-ip=10.0.4.1/16 and the negotiateed 
subnet for this side is 10.0.0.0/24? or interface-ip=10.0.0.1/16 and 
negotiated 10.0.0.0/24. Would pluto automagically change the prefix? Think 
of IPv6 too.

There is also an idea to have "interface-ip=first-ip|last-ip" or something 
similar.

>     refcnt_t refcnt;
>     bool pluto_added; 

would also need to moniter RTM_DELADDR and likely RTM_NEWADDR too.
Responding to RTM_DELADDR could be added later. However, I think monitoring 
that would be necessary.

>     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??

Did you look into using netlink methods(RTM_NEWADDR, RTM_DELADDR, 
RTM_GETADDR) from pluto? That was my first question! I don"t think scripts 
are good idea. And I would leave the VTI code alone.

-antony


More information about the Swan-dev mailing list