On Thu, Dec 15, 2005 at 02:55:13PM -0800, David S. Miller wrote: [....] > I think the kernel is definitely within it's rights to interpret > section 4.3 of RFC2408 the way that it does.
We can say that, but then, we have to accept that this interpretation can lead to interoperability problems ! > 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. Yes, it's clear: "full implications must be understood and carefully weighed before choosing a different course". Here, "full implications" include interoperability problems. > 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. You can NOT consider the DELETE_SA will be properly proceeded, as this DELETE_SA is sent using UDP transport layer, and it's delivery is NOT guaranteed ! I already saw *real world* configurations where packet loss is significant enough to consider that a DELETE_SA can *really* be lost. Using new SA "asap" really solves the problem here, as if an ESP packet using the new SA is lost, the next one, also using the new SA, will generate the same reaction: accept it and optionnaly purge the old SA. The cases of DELETE_SA not handled by racoon reported is NOT a part of the discussion for me, as it is really a specific condition, and as it will be fixed ASAP (when we'll have enough informations) if it is really a racoon's bug. But you can NOT rely on correct delivery of DELETE_SA, as you can NOT rely on the simple fact that your peer will send this DELETE_SA ! Yvan. - 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
