Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (ASCEND) Pool handling strategies (was: IP Addresses needed for 4048)
On Thu, Apr 02, 1998 at 12:12:06PM +1000, Damien Miller wrote:
> On Wed, 1 Apr 1998, Andre Beck wrote:
> > 1) I want to revert the "unclean shutdown" argument. If a user drops
> > his connection with TCP connections still open, these connections
> > will live _forever_ - constantly retrying with a new segment every
> > minute or two. This is _evil_ when you use dialed connections. If
> > an IP would be reused fast, the dangling TCP connection would be
> > RSTed by the new target soon. The dangling TCP lives as long as
> > the IP is _not_ reused.
>
> Timeouts should take care of this. Or the Max should generate an ICMP
> destination unreachable (it seems to already).
In an ideal world, yes. If you ever had a telco bill of some thousands
bucks just because a dial on demand connection with a 80 s dial timeout
was triggered by a dangling TCP connection every 2 mins and never did
timeout for weeks you don't rely on timeouts any longer. Thats the Inter-
net effect probably, even if 99.999% of all peers out there have well
working application layer timeouts there is much chance that you happen
to hit a trashy one just because of the enourmous population. We seem to
hit one every 4 months or such (or see someone else hitting one, actually).
> > My thinking about this (likely not Ascends - bad enough):
> >
> > 1) Pool IPs should be handed out with a "try-my-best-to-reget-the-old-IP"
> > strategy. If the IP cannot be reused or the NAS has no information
> > any longer about which profile did have which IP a hour ago, it should
> > be LRU - but only then.
>
> This is IMHO a bad idea. It would make session hijacking much easier. All
> you would have to do is (for example) winnuke a windows box and and time
> you dial-in attempt correctly. You would probably have some problems with
> sequence numbers though.
Only if you can log in to the Max with the same authentication as the
guy you nuked. What states a severe security problem in itself IMHO.
If you log in with another authentication the Max should realize that
you are someone else and try to give you the IP you had when you logged
in the last time or a rotated one if that is impossible.
The more interesting security problem lies in Pool Only=Relaxed like
described by me: this would allow you to kick someone out, log in and
try to IPCP for his IP address. The Max could notice this (you are
trying to aquire an IP from the pool that was just released from some-
one with other auth credentials than you) and even prevent it in the
same way it prevents you from aquiring non-pool IPs or pool IPs which are
in use. But that complicates the strategy a bit. Good point we've found
that flaw before Ascend implements it ;)
(Actually there is another problem here: if you are below a low water
mark of free IPs in the pool you have to stop beeing picky about who
gets which IP. You should have some spare IPs in a pool for the strategy
to be successful, but the allocation authorities won't want to under-
stand this...)
--
Kanther-Line: PGP SSH IDEA MD5 GOST RIPE-MD160 3DES RSA FEAL32 RC4
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) beck@ibh-dd.de XLink PoP Dresden | o |
+-o-+--------------------------------------------------------+-o-+
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>
References: