[Swan-dev] ip_range
Andrew Cagney
andrew.cagney at gmail.com
Sun Oct 13 16:49:59 UTC 2019
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
More information about the Swan-dev
mailing list