Re: [Ipsec-tools-devel] Re: IPSEC: on behavior of acquire

[Aidas Kasparas <a.kasparas@gmc.lt>]

jamal wrote:
> On Mon, 2005-04-04 at 08:59, Aidas Kasparas wrote:
> 
>>jamal 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.
>>
>>Why?
> 
> 
> 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.


-- 
Aidas Kasparas
IT administrator
GM Consult Group, UAB