On Tue, 23 Nov 2010, Tero Kivinen wrote:
: 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:
:
I'm not sure I agree. I think it's reasonable to assume that if you
receive INVALID_SPI notification instead of delete notification is that
the remote end has crashed or there is something else terribly wrong with
it and that it most likely doesn't have any state for the SA pair. In
which case sending a delete notification would be redundant. And even if
you are wrong and the other end has the outbound SA, you will now start
receiving packets with unknown SPI and will eventually reply with
INVALID_SPI. Hence, the situation resolves itself. The text you quote
are from the section dealing with delete notifications. But since the RFC
doesn't specify what to do with INVALID_SPI I think this is a _reasonable_
assumption, especially since this is what is says about it:
o If an ESP or AH packet arrives with an unrecognized SPI. This
might be due to the receiving node having recently crashed and
lost state, or because of some other system malfunction or attack.
In the first case, if the receiving node has an active IKE SA to the
IP address from whence the packet came, it MAY send an INVALID_SPI
notification of the wayward packet over that IKE SA in an
INFORMATIONAL exchange.
It especially mentions crashed node with sending INVALID_SPI. I know, it
doesn't say what to do (and it's MAY), but I think it's best to handle
INVALID_SPI and delete notification differently. It's unfortunate this
was left ambiguous.
: > 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.
:
The first thing here is that we don't know what kind of exchanges they
were. In a typical cluster implementation all nodes would have the full
state, that is they have all IKE SAs and IPSEC SAs, and all nodes know
when they expire and when rekeys need to be started.
The node should know for example that IKE SA expired during the failover
transition and perhaps it's best to delete it instead of trying to do
anything else with it (and send N(INITIAL_CONTACT) with possible new
negotiation). I'm not sure. If the IKE SA rekey happened the sync
protocol will fail and the IKE SA would be deleted. The node doesn't have
the new IKE SA either and that SA will probably get deleted too.
Unfortunately, this all takes time to resolve.
The IPSEC SA desync problem (new SA, rekeyed, deleted) would resolve
itself if we have consistent way of handling the INVALID_SPI.
Okay, here's my take on this:
: 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.
:
INVALID_SPI fixes (assuming we agree its handling). Delete notification
fixes too but will result into half-closed SA for the A's inbound SA. The
host A will never receive any 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.
:
So this would be case where the SA never had any traffic and is merely
rekeyed. This is specified in RFC 5996 section 2.25.1:
If a peer receives a
request to rekey a Child SA that does not exist, it SHOULD reply with
CHILD_SA_NOT_FOUND.
I guess it should delete it.
: 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.
:
Same section as above:
If a peer receives a request to close a Child SA
that does not exist, it SHOULD reply without a Delete payload.
The B2 will never send any traffic to the SA because it doesn't have it.
: 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.
:
Covered by the draft. It deletes the pending request. It can retry
later.
: 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.
:
INVALID_SPI fixes (assuming we agree its handling). Delete notification
fixes too but will result into half-closed SA for the B2's inbound SA.
The host B2 will never receive any traffic to that SA.
: 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.
:
Covered by the draft. It deletes the pending request. It can retry
later.
: 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.
:
Same as 1.
: 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.
:
Same as 2.
: 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.
:
Same as 3.
: 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.
:
Same as 5, different sides.
I don't see anything that prevents working connections.
Pekka
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
