[Swan-dev] better name for {left,right}ifaceip?

[Paul Wouters]

On Mon, 27 Jan 2020, Antony Antony wrote:

> On Mon, Jan 27, 2020 at 10:58:45AM -0500, D. Hugh Redelmeier wrote:
>> Has iface-ip been advertised?
>
> no. code is incomplete. We can change at this point. I would be happy to.

yes we can still change it until we release 3.30. This option has not
appeared in a full release yet.

> My recollection is, he want something similar to
> leftvti=10.0.1.254/24 for ipsec-ineterface/xfrmi, so when we kill VTI this
> new IP address can take leftvti's function. I argued it is also useful for
> non ipsec-inetrface case.

Yes, some people with 0/0 to 0/0 subnets need to put an IP on the
interface for their routing daemon.

As Andrew pointed out, it is tricky for us to specify an IP/MASK using
ip_subnet() because of some assumption on it being written as the
network address, instead of being two independent bits of information.

> There request was to add something like VTI usecase.  We need an IP
> address/mask (not same as subnet, no port and broadcast and network address
> should be invalid).

Unless you want to get into a fight with John Gilmore, don't say the
network address is invaid. It is not, and it is regularly used now. I do
get a .0 address at times. A year ago I did testing and gave public my
own public 193.111.228.0/24 address and it worked fine.

But yes, there is the issue of Traffic Selectors versus CIDRs. While
IETF supports TS ranges, and so our code sort of does too, our
configuration mostly limits that to CIDRs because that's what humans
use. People don't build a VPN with a range from 192.168.10.23 to 192.168.10.45.
If we needed to support that, we would need something like left/rightts=

We had long discussion in the past about addresspool and only using CIDR
for that or not. I prefered only using CIDRs, but Antony prefered ranges
as that is very commonly used with other software (like dhcpd, dnsmasq,
etc) and on cisco. So people use that. Possibly also, some people don't
get a full CIDR but only 2 or 3 IPs, or 6. And so with a range they can
use it even if they do not own the entire CIDR. I hated it but agreed it
would give people a little more flexibility.

But back to this case, a CIDR is fine because we are talking about an IP
address plus netmask configuration option. We had some discussion about
interface-ip= vs iface-ip= but after weeks of discussion I was tired and
Antony strongly prefered iface-ip= over interface-ip=.

> sourceip != iface-ip. Sourceip is only allowed with /32 or /128 prefix
> length.  With source ip there will be a route with that IP address as the
> source, for source address selection based on route.

And I actually dont like overloading sourceip at all, like strongswan
did with leftsourceip=%config. The concept of sourceip is that we need
to ensure that a certain destination uses a certain source. That is
quite different from obtaining IPs from VPN servers or adding your own
non-VPN related IP/mask onto an ipsec interface created by libreswan.

> iface-ip, when complete, will not be used as the souce ip address for the
> route.  It should allow prefix length, no ports, protocols... I thought I
> can use the subnet with clash. This was a while ago I will look again.
> I think in libreswan speak it is a subnet with clash, 0 port, 0 protocol.
> I was trying to avoid anther ttoipmask() may be it is necessary

I'm not sure if our code now changes any "subnet" value to the network
address, so that the type cannot be re-used here. But if remotely
possible, re-using the type used by leftsubnet= etc would be the nicest
I think. Adding a new type would be a bit overkill, as all the option
does is take the IP and mask and stuff it into environment variables for
updown to run the ip command on. (or perhaps some of that is now done
with netlink in pluto, but still the same single use case of the option)

> On Mon, Jan 27, 2020 at 10:51:20AM -0500, Andrew Cagney wrote:
>> I noticed this user visible addition:
>>     whack.h:  ip_subnet ifaceip;
>>     keywords.c:509:  { "iface-ip", kv_conn | kv_leftright ,
>> kt_subnet, KSCF_IFACE_IP, NULL, NULL, },
>> the problem I see is that, contrary to the name, it isn't an IP (i.e,
>> ip address).  Rather, to use IKEv2 terminology, its a traffic
>> selector.  In fact while:
>>    1.2.3.0/24

Just to to be clear, this option is definitely NOT a traffic selector.

Paul