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

[Andrew Cagney]

On Mon, 27 Jan 2020 at 11:39, Antony Antony <antony at phenome.org> wrote:
>
> 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.

Perhaps the keyword should be disabled for now.

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

Right.  The limitation seems to be largely historic.

If there's an option, perhaps called sourceip=, perhaps called
something else that accepts any of (subnet, endpoint, address, see
below, ...) does iface-ip and/or vti become redundant?


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

Right.

Subnet is a well understood industry and technical term but it refers
to only a strict subset of what is allowed here.  For instance,
https://en.wikipedia.org/wiki/Subnetwork makes no reference to ports.

What we've got is what IKEv2's called traffic selectors - PROTOCOL ::
LO_ADDRESS..HI_ADDRESS : LO_PORT..HI_PORT - which includes:

true subnet  - address/bits
address
endpoint - address:port

and much more.  Having a structure allowing all of these called
ip_subnet is unfortunate and confusing.  For instance, I'm fairly sure
that the reason why we've ended up storing the client's port (if there
is one) both in struct end's ip_subnet client and int port is because
a subnet having a port is non-obvious.

Anyway, looking around, ip-xfrm(8) uses the term SELECTOR
(ip_selector) and firewalls use the term filter (ip_filter).  Both of
which seem more meaningful in this context.  Food for thought.

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