netdev
[Top] [All Lists]

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

To: hadi@xxxxxxxxxx
Subject: Re: [Ipsec-tools-devel] Re: IPSEC: on behavior of acquire
From: Aidas Kasparas <a.kasparas@xxxxxx>
Date: Mon, 04 Apr 2005 17:20:59 +0300
Cc: ipsec-tools-devel@xxxxxxxxxxxxxxxxxxxxx, netdev <netdev@xxxxxxxxxxx>, nakam@xxxxxxxxxxxxxx
In-reply-to: <1112620159.1087.486.camel@xxxxxxxxxxxxxxxx>
References: <1112405303.1096.37.camel@xxxxxxxxxxxxxxxx> <424E454D.4090402@xxxxxx> <1112477326.1088.321.camel@xxxxxxxxxxxxxxxx> <424FA946.70809@xxxxxx> <1112538566.1096.391.camel@xxxxxxxxxxxxxxxx> <425067D9.9050603@xxxxxx> <1112618007.1096.465.camel@xxxxxxxxxxxxxxxx> <42513A2F.7020504@xxxxxx> <1112620159.1087.486.camel@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Debian Thunderbird 1.0 (X11/20050116)


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

<Prev in Thread] Current Thread [Next in Thread>