[Swan-dev] ip_range
Andrew Cagney
andrew.cagney at gmail.com
Mon Oct 14 13:33:22 UTC 2019
On Mon, 14 Oct 2019 at 05:44, Antony Antony <antony at phenome.org> wrote:
>
> On Sun, Oct 13, 2019 at 01:18:29PM -0400, Andrew Cagney wrote:
> > PS:
> >
> > Moving the size logic out of ttorange() and into a function vis:
>
> agree. Though I want to recored is_subet (with /) or a range (with
> - ) inside the ttorange. That is important for jam_range.
Yes, the two are unrelated. Like your comment says, it's just a hint
to jam_range().
Once size and "overflow" are turned into a function (which makes them
robust - redundancy in these structures has proven dangerous) we've no
need for a new type. Least of all one that only address-pool might
need.
> > 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.
>
> I have the similar idea. If the offset is variable lease the address could
> begin closer to the prefix boundry.
>
>
> > 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:
>
> in ikev2 traffic selectors it is a transient use. I tempted to leave
> ip_range the same for now. Your next argument is more convincing. See
> bellow.
>
> > > /*
> > > * 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.
>
> no. I don't think so. Libreswan and linux kernel currenly only accept a
> subnet. I herd a Kernel developer, Stefeen, mumbling add kernel support for
> range because in RFC IP and port are ranges.
>
> > > >
> > > > 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.
>
> Yes.
>
> However, there is convience factor in accepting smaller prefixes say /64,
> even upto /32 and for testing purposes /1; even though size is truncated to
> to 2^32-1.
Right. The only thing that uses size is the address pool. It doesn't
need to be in ip_range, and there doesn't need to be a new type.
> > > > 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.
> > > >
>
> sure. sounds good to me. I don't have a preference. I guess I will move the
> .size to ip_pool and size computation a funcation as Andrew suggest.
>
> > > > Among other things, this would allow improved modularization and
> > > > better diagnostics.
>
> -antony
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
More information about the Swan-dev
mailing list