: Define "normal crash recover". We did get rid of most of the crash
: recovery stuff in the IKEv2 compared to IKEv1. In RFC5996 we have text
: saying:
:
I was talking about INVALID_SPI notify.
: But there is no real description what to do when we receive
: INVALID_SPI message (most likely the Child SA will be deleted by
: sending normal delete notification, but as the other end will not know
: anything about the Child SA it will not reply this message and this
: will result in half-closed Child SA, where the section 1.4.1 says:
:
I don't think sending delete notification after receiving INVALID_SPI
(over IKE SA) is appropriate. The other end has already told you it
doesn't have the SA. It should be just deleted without notification.
Isn't this the typical thing to do?
: What should host A do if it DOES receive replies for those missing
: messages?
:
It can't do anything because it doesn't have any state for those
responses. They existed in the crashed node. And, they are behind
the new window anyway so they are dropped.
: > o Similarly, the peer should also not wait for pending (incoming)
: > requests. For example if the window size is 5 and the peer's
: > window is 3-7 and if the peer has received requests 4, 5, 6, 7 but
: > not 3, then it should send the value 8 in the
:
: Again what should the peer do if it does get those messages? Ignore
: them? Process them? If they are sent before the crash and were delayed
: in the network, and arrived after the sync message, they were most
: likely from the previous incarnation of the other end, thus most
: likely they need to be ignored.
:
Again, they are behind the new window and will be dropped.
As long as both ends follow the protocol both ends should have deleted the
states for any pending requests and responses and moved the window, and
any stray packets from the network should now fall behind the window and
are simply dropped.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
