[Swan-dev] overlapping address pools

Antony Antony antony at phenome.org
Sun Apr 20 14:40:41 EEST 2014


It would be nice to have an options to assign unique address. When there is an overlap, the new pool mark the unused overlapping addresses in the old pool as used. If an address already in use in an old pool mark it used in the new pool. 

In libreswan, as far I know, there is no overlap check for a subnet. An address pool is very similar to a subnet, imagine it as a /32 subnet. You could even replace it with a subnet. If subnet overlaps with another subnet there is no warning. Then I am wondering why treat an addresspool overlap as an error?

-antony

On Sun, Apr 20, 2014 at 01:23:40AM -0400, D. Hugh Redelmeier wrote:
> Antony and I are having a debate.
> 
> Address pools are a range of IP addresses that can be doled out by a 
> host to clients.  IPv4-only.  Antony added this feature to Pluto.
> 
> Each conn can have an address pool.  If two conns' address pools are 
> identical, they are shared (a single common pool).
> 
> If two address-pools overlap, but not exactly, each pool is separate in 
> the addresspool logic: each pool could allocate the same address without 
> being aware of it.
> 
> I think that this is crazy and should be considered an error: the conn 
> specifying an overlapping pool should be rejected.
> 
> Antony thinks that the user might know what they are doing so that the 
> conn loading should succeed, but with a warning.
> 
> My feeling is that this is like Russian Roulette: Bad Things will happen 
> if both conns allocate the same address.  Which can be the only reason to 
> have overlapping addresspools.  Great idea in security software.
> 
> What the heck is the use-case?
> 
> Alternative "I want this to work, dammit" approach: when the second
> conn is loaded, chop off the overlap from one range or the other
> (assuming none of the addresses is in use) and proceed.  But scenario
> seems too obscure and insufficiently useful to be worth investing much
> effort into.  (The current simpler addresspool logic has taken a lot
> of work already.)
> 
> So: you've heard my side.  Antony may present his view.
> 
> What do you think?
> _______________________________________________
> 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