PS: Moving the size logic out of ttorange() and into a function vis:
bool range_size(const ip_range *range, uintmax_t *staturated_size) MUST_USE_RESULT /* false if overflow */ (same for converse range+offset) I think does have merit. Andrew On Sun, 13 Oct 2019 at 12:49, Andrew Cagney <[email protected]> wrote: > > 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
