|
Hello,
On Thu, 14 Feb 2002, Roberto Nibali wrote:
> > This should be investigated, what behaviour has the ISAKMP
> > traffic.
>
> It's UDP I don't expect anything special there. Maybe that the ISAKMP
> daemon should be aware of the whole IPsec termination cluster, something
> like the cookie problem.
It is not needed. In the SSL world you need to decrypt
SSL on the director box just to make correct HTTP scheduling. We will
stick with the default method: CIP connects to VIP(FWMARK) via ESP or AH.
These unique hash keys are able to identify all VPN clients behind
CIP. We better not to try to differentiate the different masqueraded
VPN clients behind CIP by SPI. It is a job for the web director
behind the IPSec termination to play with the cookies. What is the
drawback: all the masqueraded VPN clients will be scheduled to
same RS - bad for load balancing? Not sure for IPSec.
> > This is a non-LVS issue, the termination on the LVS box.
> > I mean, all RS have same keys, they are terminators.
>
> How do you share the keys among the RS?
Hm, use rsync :))) Push all private RSA keys or X.509
Certificates to all real servers :) Or any other standardized
proto for cert management :)
> > May be in the next days/weeks, there is another pending
> > stuff to complete... But until then we will investigate the
> > internals.
>
> Hope that Henrik can wait that long.
Yes, this will need rewriting the LVS, in the next devel
versions. Of course, until then someone can experiment too :)
> > I prefer not to make the real servers' routing more difficult
> > by allowing different client connections to reach different real
> > servers but this is TOCHECK.
>
> Yes, I think the first approach should be LVS-DR and IPsec using
> transport mode. After that we move to IPsec tunnel mode.
Yes, for the tunnel mode I'm not sure how the routing through
the real servers will work, from the Director A. May be SNAT.
> > > Timeouts for what?
> >
> > For the "connection", I'm not sure how much long should
> > last one ISAKMP or ESP entry in LVS.
>
> Ahhh, this is nasty. Netfilter has a table for AH/ESP in conntrack
> but if we do LVS-DR we cannot use this, or can we? It would be easy
It is useless for me. We can get it if it is needed.
> to poll conntrack timeout entries and fill in those or we just define
> one. Someone of us should start reading the RFC :)
Yep
> > Yes, ESP and AH will use different keys. Note that the
> > fwmark services don't care for protocols, they are protocol
> > independent.
>
> IMO ESP doesn't need a key, or what do you mean by key? And yes,
> fwmark is excellent for this task.
I mean the hash keys needed to maintain the LVS entries
> > > Well you could hash the information with the SPI and then take the
> > > resulting hash value as routing key.
> >
> > Yes, may be saddr->daddr,sSPI can be a hash key
>
> Hmm, if you run IPsec in tunnel mode (most deployed) you don't have
> changing information in daddr until you descramble the ESP Header.
Yes, plain routing
> +--------------+---+-------+----+------+-------+---------+
> |orig IP header|SPI|Seq.Nr.|TCP | DATA |Padding|Auth.Data|
> +--------------+---+-------+----+------+-------+---------+
>
> Here the IP header contains the destination net entity which you
> can use for load balancing (routing) information
The first IP header, where iph->protocol==ESP.
No need to lookup into the internal headers, may be only for SPI.
> +-+-+---+-------+-+---+----+-------+---------+
> |A|B|SPI|Seq.Nr.|C|TCP|Data|Padding|Auth.Data|
> +-+-+---+-------+-+---+----+-------+---------+
>
> Where:
> A: new IP header (DGW, in our case the load balancer)
> B: new extensions (not sure, I think hop-by-hop stuff)
> C: original IP header (unfortunately _encrypted_)
A
> LVS_DR with case 1 should be ok:
> o fwmark the service
> o route key from IP header
> o persistency template including <saddr:daddr:SPI>
Agreed
> LVS_DR with case 2 is a little bit tricky:
> o fwmark the service
> o route key is not possible from encapsulated packet
No, we need the saddr and daddr which are the secure
gateway IPs
> o persistency template could be some information of the new
> extensions and maybe SPI
Or SNET->FWMARK/AnyPROTO (already implemented)
> General Problems:
> o We simply don't know if SPI is persistent per se per session.
> If it changes we're fucked or we need to maintain the SPD
> hash pool.
Yes, we don't know how much time to keep one ISAKMP and
ESP session. Are there any keep-alives standardized? (A: RTFM :))
> Suggestions, comments, Wensong (yi jian zhongqing)?
>
> Best regards,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
