|
Hello,
On Fri, 15 Feb 2002, Roberto Nibali wrote:
> > OK, at least the schedulers are modular (mostly). We
> > can do the same for the protocols (may be not in separate file
> > but at least with distinct methods).
>
> How about a generic scheduler where you can register schedulers that
> feed that generic scheduler with input. For example let's assume the
> scheduler just does weighted round robin but also has an interface to
> get new scheduling input from others. Like this a lot of schedulers
> could be tested an all we need is an API for user space calls into the
> kernel. Alexandre Cassen is indirectly going into that direction. In
> principle you only supply the new weight to the scheduler and it takes
> care of the rest.
Currently, all schedulers can receive weight and in most
cases this is enough. If you want to feed it with something else
then it should be implemented. WRR is clever enough to keep the
weights you set. From your words I assume it is not enough? As
for testing new scheduler, why not to copy one simple scheduler
and to fill all its hooks. Rename ip_vs_wrr.c to ip_vs_wrr_saved.c
and ip_vs_thebestone.c to ip_vs_wrr.c and do ipvsadm -A -s wrr :)))
> > It is one of the variants (masquerade). May be there is
> > another way, I can't see it now.
>
> All ways with NAT disable some functionality of IPsec.
Client is masqueraded after IPSec termination. By this way
the next hosts behind the termination will know how to reply back to the
IPSec gateway, the real server that decrypted the traffic. I agree,
this is not ideal solution.
> > Good idea, RTFM first. As for the netfilter AH/ESP support, it is
> > only a match.
>
> Well, I informed myself a bit on the timeout issue and in principle it
> is dead simple, the impact on LVS routing is a general PITA. A
> "established", authenticated IPsec connection between two endpoints
> basically stays up forever. If however the setup is done in a different
Bad news which is good to know.
> way, the user can specify the timeout. This is transfered via the UDP
> packets first which initiate the whole connection setup. After that the
> IKE SA setup does some magic key handshaking and generates on each side
> an SA for the connection. All those things have to be persistent. Now
> the SPI stays for the session until the timeout expires and that is
> where we have to pay attention. If a SA pool creates a new SPI we need
> to figure that out and to some kind of RELATED entry and put that into
> the persistence template of the old session.
If we look at the SPIs at all. I'm even thinking of
code such as:
- get the iph->protocol
- if it is ICMP => try for related ICMP
- if it is UDP/TCP/ICMP => do balancing
- if it is ESP/AH => do balancing
- unknown but fwmark-based => do balancing (optional, can be PASS TO STACK)
> > I think (before any coding) that there should not be
> > big problems.
>
> I'm not so optimistic.
Yep, we need to know when one connection dies.
> >>Exactly, so basically transport mode should be quite easy.
> >>
> >
> > In fact, we don't care what we reroute, tunnel, transport
>
> Well, for selecting the routing key you certainly to, or do you only
> want to take saddr->fwmark as a key? SPI works if we can keep track of
> rekeying events of related sessions.
Yes, with the persistent fwmark service we can forward
any protocol, the minimum we need to know is when to create and when
to release a LVS entry. Everything else is routing. We don't want
to rely on the dropentry memory-defense strategy to make the decision for
the entry life :)
> > We don't care about the method, we are not terminator.
>
> Actually the RFC strangely mentiones that one doesn't need to know such
> things for routing. So I'm convinced now.
Yes, for our routing decisions ESP/AH is a IP protocol, we
even don't need to look at the protocol header and as a bonus we
even don't need to defragment these packets. Defrag is needed only
for TCP/UDP/ICMP because we use information from their headers.
So, ESP/AH is easy for forwarding but ISAKMP ... we still don't know.
> Well, tonight while cooking for Valentine's Day dinner this idea popped
> into my head too. SNET->FWMARK template is the smallest possible working
> subset for IPsec tunnels. I agree.
Yes, run your new scheduler, apply dynamic weights and
the imbalance caused from persistence is gone :) Almost.
> > Yes, most of the things are clear now, we simply should
> > try it one day. I have env to test it, so no problem.
>
> Oh, good. Well, I kinda know now how this works. But since the template
> will be saddr only, a timeout or rekeying is not an issue anymore. The
> only problem we could face is that if we would allow infinit timeouts
> that this would potentially open a small risk of overflowing the kernel
> memory by time. So I suggest one implements the persistency template
> timeout to the code too.
The persistence timeout is useless if we don't have correct
control for the ISAKMP and the ESP/AH entry life, they can't live
forever in our context. We should analyze ISAKMP (if someone is
aware please help) to add correct entry life timeouts because the
problem with attacks can be unavoidable. This is DR method (input
only).
> Good night,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
