[Swan-dev] ip_range

[Andrew Cagney]

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 <andrew.cagney at gmail.com> wrote:
>
> On Sun, 13 Oct 2019 at 11:04, D. Hugh Redelmeier <hugh at mimosa.com> 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
> > Swan-dev at lists.libreswan.org
> > https://lists.libreswan.org/mailman/listinfo/swan-dev