|
Hi,
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.
And again you're right :)
The lookup for CIP->VIP:500 entry should be enough?
Yes.
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.
Yes.
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.
Maybe we add this later, if it is the case. Once we see some traffic
coming through LVS, we add some printk()'s and see what happens.
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.
Yes, this is ok.
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.
I don't know. Might work, might also not. Things need to be checked in
real life examples.
Best regards,
Roberto Nibali, ratz
| 