On Mon, 27 Jan 2020 at 11:39, Antony Antony <[email protected]> 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 > > [email protected] > > https://lists.libreswan.org/mailman/listinfo/swan-dev _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
