|
Hello,
On Tue, 19 Feb 2002, Roberto Nibali wrote:
> > Then the above statement is true, as long as no tunnel is set up. when
> > the tunnel for a subnet is up, we have no choice. Tunnels will stay for
> > hours, days, weeks ...
>
> Julian, do you copy? WEEKS!! This is going to use more RAM eventually.
> What is you rekeying time policy? Do you provide an SLA-like agreement
> where you say that after 2 weeks of no byte stream we will close the tunnel?
Keep the rekey interval below the ISAKMP timeout in LVS and be
happy, the connections can last months :))) One ISAKMP entry per
CIP[:CPORT], no ESP/AH entries.
> o your NMS has a DB which "knows" about incoming CIP1->dst_net1 and
> thus sets up the director with a fwmark1 (CIP1/32->VIP/32) and if he
> smells CIP2 is requesting a IPsec connection, you setup a new entry
> to LVS using fwmark2 (CIP2/32->VIP/32).
> o your RS (IPsec endpoints) still need to be able to route to all
> possible net entities addressed by your customers.
> o This mine topology tends to load imbalance horribly.
I don't believe a client will create many ESP connections
to one server, this is not a web :))) Note that there must be a save
mechanism the server to notify the client about many different
subnets guarded from this gateway. May be only if ISAKMP is
extended to create a list of subnets for negotiation. Currently,
it is only one subnet (we are talking about the proposed
opportunistic encryption). But the hidden issue is how much traffic
creates each SA, as we discussed it already. It can be handled
safely by using dynamic weights for RSs. And with IPSec termination
the RSs will do mostly decryption, with small traffic :)
> Best regards,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
