On Thu, Jan 30, 2020 at 10:35:48AM -0500, Andrew Cagney wrote: > On Wed, 29 Jan 2020 at 04:06, Paul Wouters <p...@nohats.ca> wrote: > > > > On Wed, 29 Jan 2020, Antony Antony wrote: > > > > > Antony foresee new type ttipcider(), as there are objections to reuse > > > subnet(). We will see when we add the code. If the subnet is left alone > > > without port and protocol it can used for ttipcider(). > > > > > > Additionally: > > > suggests to leave subnet as without ports and protocol, and create > > > traffic_selectior() for parsing keyword subnet from our config. > > Just to be clear, any thing using ip_subnet and ttosubnet() will > accept ports. For instance: > subnet=1.2.3.4/32:10 > (a quick test suggests it is silently ignored).
now that you clarified ttosubnet() is actually ttots(). it easy to reject subnet+port for VTI and inetface-ip Last week I noticed IP6 addresspool accept ports. I took a note to revisit use of ttosubnet(). thanks for pointing it out. fix sems easy conf leftaddresspool=2001:db8:0:3:1::/97:10 addconn connection's leftaddresspool set to: 2001:db8:0:3:1::/97:10 pluto | pool 2001:db8:0:3:1::/97: creating new address pool I plan to push an improvement for this soon. reject 2001:db8:0:3:1::/97:10 Proposed change: connection's leftaddresspool set to: 2001:db8:0:3:1::/97:10 while loading 'east': bad leftaddresspool=2001:db8:0:3:1::/97:10 [port must be zero for addresspool] bad leftaddresspool=2001:db8:0:3:1::/97:10 [port must be zero for addresspool] > It isn't a question of reusing ip_subnet to implement traffic > selectors. Rather its the reverse, we've already got a traffic > selector type and it's being used everywhere; it's just that it is > unfortunately called ip_subnet. > > > Seems reasonable. Although for now I am also okay with using ip_subnet > > as was done for the vti case. _______________________________________________ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev