On Sun, 13 Oct 2019 at 11:04, D. Hugh Redelmeier <[email protected]> wrote: > > The ip_range type seems to be used for two purposes: > > - traffic selectors
The (ikev2) traffic selector code outputs an ip_subnet, not an ip_range Internally it just happens to use an ip_range as part of the journey towards a subnet. Like the comment points out: /* * 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. */ > - ip address pools > > The two uses have diverged. Lots of complexity has been added for the > address pool case which is not clearly correct or useful for the traffic > selector case. > > Is there an RFC-based limit on range sizes for traffic selectors? > If so, that should be enforced (i.e. violation should be failure, > not truncation). If not, we should not trunctate them. > > For address pools, I think that we get to set the rules. It seems to > me that 2^32 is large enough. That's what our code supports. Why not > treat a larger size as an actual error rather than truncating to > specified range? Then a lot of truncation logic goes away. Clearly > this limit must be spelled out in the documentation (perhaps it is -- > I haven't looked). This is what Antony did. > The routines that currently do truncation don't know whether they are > dealing with a traffic selector or an address pool. > > I suggest that the old ip_range type be reinstated and that a new type, > perhaps "pool_range", be added with the new features. > > The pool_range type could be composed of an ip_range and some additions. > > Among other things, this would allow improved modularization and > better diagnostics. > _______________________________________________ > 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
