|
Hi Julian,
> > then is to disable re-keying (set rekey=no) so we don't need to support
> > a back connection request for key exchange. Like this we have cleaned
> > the peer-2-peer connection a little bit by allowing it only into one
> > direction. It's like with identd ;)
>
> 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.
> 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?
> > Send it to QUEUE target and do the decryption in user space :)
>
> :)
Oh, or give it to Wensong for ktcpvs ...
> May be only the client's SPIs, if the client masquerades other
> VPN clients. May may be there are same issues with unknown SPI values
> at the first packets, I don't remember how was handled this in the
> VPN Masquerade 2 years ago, I have to check it.
Forget it with LVS-NAT, too much to rewrite.
> > You need an SA pool called SPD (Security Policy Database) where you
> > store the SPI information for post processing. If we decide to strip of
> > some daisy-chained headers from AH we need to make sure that
> > checksumming is disabled or the IPsec endpoint will not accept the
> > packet anymore (needs to be tested). But at least we would not need the
> > SPI information.
>
> Yes, I prefer this case
Actually after sleeping over it, I think we can have it a lot easier.
> 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.
> 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.
> > 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
to poll conntrack timeout entries and fill in those or we just define
one. Someone of us should start reading the RFC :)
> 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.
> > 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.
Let me give you an overview, so we talk about the same here:
Case 1: IP ESP in transport mode (good for routing information)
---------------------------------------------------------------
|ESP Header |ESP payload|ESP trailer |
+--------------+---+-------+----+------+-------+---------+
|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
Case 2: IP ESP in tunneling mode (hard to find routing key)
-----------------------------------------------------------
|ESP header |o.IP DGRAM|ESP trailer |
+-+-+---+-------+-+---+----+-------+---------+
|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_)
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>
LVS_DR with case 2 is a little bit tricky:
o fwmark the service
o route key is not possible from encapsulated packet
o persistency template could be some information of the new
extensions and maybe SPI
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.
Suggestions, comments, Wensong (yi jian zhongqing)?
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
