From: jamal <[EMAIL PROTECTED]> Date: Thu, 15 Dec 2005 15:56:52 -0500
> Refer to Herberts solution and see if that "solves the problem". I think the kernel is definitely within it's rights to interpret section 4.3 of RFC2408 the way that it does. And I bet that whoever wrote those paragraphs used "SHOULD" exactly because they realized that there might be a serious performance penalty assosciated with immediately using a new SA across the whole system when there was an old SA still around. It's a SHOULD, not a MUST, and RFC2119 is very clear what that means. And in all the cases I have seen where this decision is causing problems, errors occuring at the key manager level are the true cause of the eventual failure. If the daemon ignores an SA delete from the peer, we're expecting the kernel to mop up the problem by always immediately using the new SA? That's rediculious and a bandaid, and the problem should be fixed at the source. If the SA delete transpired properly, there wouldn't be a communication failure. In the SA expiry situation with certain CISCO products, that's even worse. I'm surprised that doesn't cause all sorts of other problems. That being said: 1) I don't understand how a routing cache flush "fixes" the problem. The routing cache flush only marks non-IPSEC cached routes as invalid, not IPSEC ones. 2) There are quality of implementation arguments for using the new SA immediately. And if we can find an efficient way to do this in the kernel, I'm all for it. I'll look over this some more... - 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
