Herbert Xu wrote:
On Wed, Jul 27, 2005 at 03:18:39PM -0700, David S. Miller wrote:
One idea tossed around between Herbert Xu (also CC:'d) and myself is
to store a generation counter when we attach a route to a socket, then
sk_dst_check() can verify that this generation count matches the
current IPSEC flow cache generation count.
Yes we did talk about having generation IDs for IPsec dst entries.
However, it doesn't help us when IPsec SAs change. The flow cache
generation ID is only incremented for policy changes, not state
changes.
This particular bug report relates to the case where SAs are
renegotiated but the policy remains unchanged.
IMHO this is something that user space can and should deal with.
All the KM has to do is to delete the old outbound SA when the
new outbound SA has been negotiated. This will cause all new
traffic to start using the new SA immediately. It will also
allow the remote side to continue using the old SA until it
expires since we're not removing the existing inbound SA.
The key management protocols have the timing and procedure to delete
old SAs in the rekeying. We may not able to delete the outbound SA
with the reasone. But we can delete the old SA(s) when implementing
delete procedure on IKEv2 and KINK.
IKEv1 does not define the rekey. We can probably delete the old outbound SA
like the above.
We could do this in the kernel. However, it'll end up being
harder since the kernel doesn't really know which old SA(s)
the new SA is meant to replace.
I'm anxious about MIPL 2.0 because it is implemented on the xfrm
architecture.
--
Kazunori Miyazawa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
