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@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev