|
Hi Julian,
On Mon, 27 Mar 2000, Julian Anastasov wrote:
> OK, may be we can implement some statistics in the LVS:
>
> - dropped entries
> - traffic for each real service
> - etc
>
> Or may be just for debugging, i.e. to check the behavior under
> attack and with the goal to tune the mechanisms. We can encount the
> ICMP_PORT_UNREACH packets sent back to the real server too. This
> is only an idea.
>
Both are OK. Statistics information is good, as long as it won't take too
much CPU cycles to collect those information.
> > > I like the idea of many independent sysctl vars.
> > > We have to choose correct names for the above sysctl vars.
> > >
> >
> > It is good to have many independent sysctl vars. However, it might be good
> > to have an ip_vs_defence_level sysctl, whoes value can be 0,1,2,3,4...,
> > different level means different defence strategies, then there is only one
> > sysctl on this. ;)
>
> I think it is very useful to combine delayed ES transitions
> with dropping packets (without passing them). Lets choose some names
> for them.
>
> 1. "dropping entries" => from table
> 2. "dropping packets" => without passing them (using rate)
> 3. "secure tcp" ??? I.e. when we follow the real servers TCP state
>
> Method 3 can be problematic for services which assume
> timeout 15 minutes after the connection setup. May be this method
> can be optional. But methods 1 and 2 seem as mandatory for me. But
> it can be useful each to be set independently. If we choose to
> use one sysctl var, we have to combine the useful combinations.
> I.e. the max is 3 methods ^ 3 values (0/1/2) => 27 values. The
> other parameters can be when each method is triggered in
> automatical mode. OK, may be we have to choose only small number
> of possible settings.
>
Independent sysctl variables are OK, and let users combine one that they
want. I haven't got good names for them, maybe we can simply use
ip_vs_dropentry randomly drop entries from the table
ip_vs_droppacket 1/rate randomly drop packets without
passing
ip_vs_amemthresh available memory threshold to guild
when to do dropentry and droppacket
Maybe you have other good names.
> > > For the UDP entries. Is the checking in ip_vs_random_drop()
> > > for IP_MASQ_S_NONE correct? Isn't the state IP_MASQ_S_UDP? May be
> > > I'm missing something? May be it is better to control the UDP
> > > entries by using ipchains and not to drop entries from the table?
> > > We still can implement dropping UDP entries without passing them.
> > >
> >
> > It is my mistake, the state should be IP_MASQ_S_UDP. But, I cannot see the
> > reason that we cannot drop UDP entries, UDP itself is unreliable and
> > connectionless, UDP packets can be lost, duplicated, out of oder in the
> > transfer.
>
> I don't know. DNS is stateless. But other service are not.
> They are different things: stateless/persistent and connectionless.
> May be the UDP is used for other services, i.e. when the speed is
> preferred and the TCP retransmissions are not useful: game servers.
> And there is a little persistency. For services which
> receive one packet and answer one packet we even don't need to
> remember the entry for long time. If the user thinks the real
> server can answer for 2 seconds, he can set the UDP timeout
> to 2 seconds with ipchains. Anything better?
>
I don't know. Maybe you are right. There are some applications using UDP
for speed, and implement their own simple flow control and dispatching.
> It can be useful each virtual service to use different
> timeouts but it is difficult to achieve. There are so many states.
> May be only for the ES and UDP states. When I implement the
> per-entry timeout table (ms->timeout_table) I'll check if this is
> possible. If the idea looks good. So, this can be an additional timeout
> value. For TCP it is ES timeout. For UDP it is UDP timeout. But the
> goal is only to work under DoS attack.
>
Yeah, it must be complicated to implement different virtual services have
different timeouts. Maybe we can simply implement the under-attack timeout
table as you suggested before, when the system is under attack, we turn to
that defence timeouts (timeouts are often short). Or, maybe we can use
sysctl variables to let people to tune the defence timeouts themselves.
Thanks,
Wensong
|
