On Mon, 2005-04-04 at 08:59, Aidas Kasparas wrote:
I think i have made a bad case of explaining.
Yes, I know where acquires terminate. However this is not about where
acquires terminate. It is insufficient to assume that a succesful
acquire to user space equates to successful interaction to the KE server
which will do an update.
The reason the kernel sends an acquire is to update larval SAs it
created. The result is either updating the SA or a rejection for that
matter. Else theres failure in communication.
Anology: If you are trying to send a message from one end system
to another and there are multiple hops between them, then just because
it made it to the first hop does not equate it made it to its final
destination. To make it to the final destination, the confirmation has
to come from the target end.
So if you said the KE was the final destination then kernel to user
space was the first hop.
I am not sure if this is clear as an analogy.
OK, if you have a chain with sevaral hops, then probably there is no
better way than signal from other end that it got something. The thing
we do not agree is how this should be managed and supervised.
I would like to provide an analogy too. You have a telenet application.
You try to connect to some host:port. Your telnet application just makes
connect(2) syscall and do not cares how kernel establishes that
connection. What MAC address to send packet to, how and when to
retransmit syn packet if the ack was not received in timely fashion, and
so on, so on, so on. If kernel does his job fine, then we have connected
socket on which to communicate further. If it does not, or there are
some problems on the target host or network in between, then we will not
have that connected socket - syscall will return an error.
With ipsec system the situation is quite similar, just kernel and
userspace have swaped places. Kernel told the userspace to update larval
SA. Userspace works on that. If it has negotiated keys for that SA with
KE at remote site, fine, userspace will update SA. If there are
problems, and key negotiation is not possible -- these SA will not get
updated and eventually will die. But single signal to userspace is
sufficient for that process to be performed. Yes, kernel can check state
of SA every time some packet has to use that SA. But to make noise by
asking "please negotiate the SA which you're supposed to be negotiating
already" ... IMHO it is contrproductive.
GM Consult Group, UAB