Pekka Riikonen writes:
> 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?
The other end is telling that he does not have incoming SPI given that
number. The peer is sending message saying he wants to delete the pair
of that SPI meaning is incoming SPI of the same Child SA pair. It is
not exactly same thing.
It could perhaps be interperted that as other end send INVALID_SPI for
his inbound SPI, then that SA is not there, so peer should not wait
for the corresponding delete with that SPI to his request to delete
his own inbound SA.
RFC5996 still says that "A node MAY refuse to accept incoming data on
half-closed connections but MUST NOT unilaterally close them and
reuse the SPIs." which quite clearly say that node who still has SA
up, cannot silently remove his inbound SPI and reuse the SPI, but must
send delete for it before reusing it.
I think correct way to handle INVALID_SPI is that consider it as same
as the other end would have sent delete for that his inbound SPI
listed in the notification, and then send corresponding delete for
your inbound SPI, which the other end will ignore as specified in the
2.25.1:
... If a peer receives a request to close a Child SA
that does not exist, it SHOULD reply without a Delete payload.
But anyways, as I have requested before I think we need to add text
for different cases and how to recover them. I.e. how to handle
following situations (Host B1 is the one who has lost state, Host B2
is the new instance missing some state):
1) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but
B2 does not know anything about it and host A tries to send traffic
to that SA.
2) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but
B2 does not know anything about it and host A tries to rekey that
SA.
3) Host A has sent CREATE_CHILD_SA and got reply to that from B1, but
B2 does not know anything about it and host A tries to delete that
SA.
4) Host A has sent CREATE_CHILD_SA and but has not received anything
from host B before getting sync message ID notification from B2.
5) Host A has sent Delete payload in INFORMATIONAL exchange to B1 and
has received reply from B1, but now B2 continues sending data to
the SA which has already been deleted.
6) Host A has sent Delete payload in INFORMATIONAL exchange to B1 but
has not received anything from host B before getting sync message
ID nortification from B2.
7) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but
B2 does not know anything about it and host A tries to send traffic
to that SA.
8) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but
B2 does not know anything about it and host A tries to rekey that
SA.
9) Host B1 has sent CREATE_CHILD_SA and got reply to that from A, but
B2 does not know anything about it and host A tries to delete that
SA.
10) Host B1 has sent Delete payload in INFORMATIONAL exchange to A and
has received reply from A, but now B2 continues sending data to
the SA which has already been deleted.
11) Similar cases for IKE SA rekeying and deletion.
I would expect we can create generic rules for handling most of those
cases, but I think it is important to analyze all cases (like RFC4718
and RFC5996 did, i.e. RFC4718 did analyze lots of cases, and RFC5996
includes generic rules which covers the cases analyzed in the
RFC4718). Creating those generic rules is impossible unless we really
go through what happens in each situation.
> : 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.
Yes, but what should it do next? If that was delete notification,
should it retry (most likely yes)? If this was IKE SA rekey
notification, then it is not supposed to send anything else than
delete for IKE SA after CREATE_CHILD_SA exchang rekeying IKE SA etc.
Those cases needs to be analyzed and checked out what is the correct
handling for them. This is timeconsuming task (I remember that Pasi
complained that when he analyzed the collision cases in the RFC4718 it
took some time) and I do not have time to do that, so I would expect
the draft to cover those cases.
> : > 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.
Even if we are agreeing what should be done for those messages, we
need text in the document explaining those cases and how to handle
them.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
