|
Hello,
On Mon, 18 Feb 2002, Roberto Nibali wrote:
> > OK, at least, we are one step forward:
> >
> > http://www.linuxvirtualserver.org/~julian/LVS_IPSEC.txt
>
> Holy sheep, Julian, where do you steal the time to write all those
> documents. You write more than I can read in my spare time :)
Relax, it does not happen often :)
> o The initial connection setup where to SA pools for the IPsec endpoints
> are generated is not encrypted. Your document says all ISAKMP traffic
> is encrypted. This can't be the case. The keys to encrypt connection
> are generated after the ISAKMP initial 'handshaking' where we
> negatiate about SPI-pools, used crypto-hashes and lifetime and such.
> We could theoretically be able to intercept and read that traffic.
I'm not sure about this part. My understanding was that
the ESP SAs are negotiated at Phase 2 where everything is
encrypted. We have to be sure for this. But IMO, it is not
interesting for LVS.
> o Could you extend the part with the "We don't need to maintain
> connection entries ..."? You should add that if you have a fwmark for
> 0/0->VIP:500 that the ESP/AH packets need to be scheduled to the same
> RS or the monkey won't fly. Actually I don't understand the whole
The lookup for CIP->VIP:500 entry should be enough?
The ISAKMP channel is uniquely defined between CIP and VIP,
if two VIPs are part from a fwmark based service we should
create 2 entries for them. Note that the virtual service
is used only at scheduling time, not for already established
entries. As for the fwmark value it is used only also to
create the connection template.
So, this is the client's point of view. I'm not sure
whether the NAT Traversal will introduce requirement for
relaxed ISAKMP CPORT, may be not? If the CPORT is relaxed (not
500) we should distinguish them.
> paragraph. Do you mean what I mean above? If you add ESP/AH to the
> same template as fwmark'd VIP:500 then we're safe? I read the para-
> graph below and if I read it correctly I think we both mean the same
> thing :)
The conn template is used at scheduling time. But before
that we should check for CIP->VIP:500 when we see ESP/AH traffic
and to account the byte and packet stats to it (to the virtual
service and the real service, of course). By this way we can
define one simple virtual non-fwmark based service:
ipvsadm -A -u IPSEC_GW:500 -s wlc
that will cover the ESP/AH traffic too.
> o Julian, how can an administrator configure a machine not to check the
> TCP/UDP checksums?
He-he, good question. The answer can be more complex in
2.4. But may be the ESP decaps procedure has exactly this job,
to restore the pseudo checksum for every embedded protocol
known to have this problem on NAT: you know the IP addresses
before ESP and after ESP header, make the missing incremental
checksum update before feeding TCP or UDP with the packet.
> Best regards,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
