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

[Antony Antony]

first quick answer to Hugh's follow up questions.

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.
Though Paul may have signoff. 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. 

> Andrew's points all seem valid too.  But I haven't thought deeply about
> this. 

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).

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.

e.g

192.1.3.0/24 dev eth0 proto kernel scope link src 192.1.3.209
https://testing.libreswan.org/v3.28-1519-g8a299ca7ad-master/xauth-pluto-16/OUTPUT/road.console.txt
or typically you would see 0/1 and 128/1 with src 192.1.3.209

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

iface-ip=192.1.3.0/24 if we want to be generous 192.1.3.0/255.255.255.0 
would be nice to have. then there is an argument to allow 192.1.3.0 as 
192.1.3.0/32.


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

>    101.102.103.104/32:65535
> are valid, a simple IP address such as:
>   1.2.3.4
> is not (see ip_subnet_check.c).

with port is not valid iface-ip.
1.2.3.4 => 1.2.3.4/32 could be. I am not sure

> A quick fix would be to drop the "ip" from the new user-visible name?

could be. I prefer ip address there like sourceip.
The current one is 
./netkey-vti-09/west.conf:	leftvti=10.0.1.254/24
10.0.2.0/24 dev ipsec0 scope link

> However, this is confounded by libreswan's existing plithera of
> options that either implicitly, or explicitly, specify traffic
> selectors (these are the ones I stumbled across, there are probably
> more):
>   sourceip= - only allows IP addresses and is considered mutually
> exclusive to ifaceip=, I'm not sure why
>   subnet=
>   subnets= - who knew there was already a way to describe multiple
> traffic selectors
>   addresspool=
> 
> This makes me wonder if the new ifaceip= option is needed, and instead
> one of the above should be reused?
> Strongswan, for instance, seems to have extended sourceip= so that it
> accepts subnets, see  interop-ikev2-strongswan-39-mobike-responder).

extending sourceip is a possibilty. It might need more keyword. They %source 
or something?

> PS: per the below from ip_subnet.h, ip_subnet is becoming a really
> unfortunate choice of name

subnet is more popular in industry. subnet:port is a narrow usecase, yet 
important:)

>  * This is not the subnet you're looking for.
>  *
>  * In libreswan ip_subnet is used to store client routing information.
>  * IKEv2 calls this traffic selectors and it allows the negotiation
>  * of:
>  *
>  *    LO_ADDRESS..HI_ADDRESS : LO_PORT..HI_PORT
>  *
>  * The structures below can only handle a limited subset of this,
>  * namely:
>  *
>  *    NETWORK_PREFIX | 0 / MASK : PORT
>  *
>  * where PORT==0 imples 0..65535, and (presumably) port can only be
>  * non-zero when the NETWORK_PREFIX/MASK is for a single address.
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev