Pekka Riikonen writes:
>
> 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.
General principle in the IKEv2 is that it is reliable protocol, and
the state should not get out of sync. If you are getting INVALID_SPI
for SA which you think is valid that means that other end is doing
something wrong (for base IKEv2 case).
The assumption in IKEv2 is that if IKE SA is working, then all the
child SAs negotiated with it are also working. If some Child SA can
only be removed by sending delete notification or by deleting whole
IKE SA. There is text in the RFC5996 explaining that in several
places, altough it is splitted around so it might not be that clear:
Receipt of a fresh
cryptographically protected message on an IKE SA or any of its Child
SAs ensures liveness of the IKE SA and all of its Child SAs. Note
that this places requirements on the failure modes of an IKE
endpoint. An implementation needs to stop sending over any SA if
some failure prevents it from receiving on all of the associated SAs.
If a system creates Child SAs that can fail independently from one
another without the associated IKE SA being able to send a delete
message, then the system MUST negotiate such Child SAs using separate
IKE SAs.
...
If an IKE endpoint chooses to
delete Child SAs, it MUST send Delete payloads to the other end
notifying it of the deletion.
Because there is no normal case where INVALID_SPI would be sent inside
the IKE SA in normal IKEv2 there is no processing rules for it in the
RFC5996. As it seems we do need processing rules for it when used in
high availability IKEv2 then that text needs to be in this document.
> In which case sending a delete notification would be redundant.
Most likely yes, but IKEv2 says you do not delete SAs without sending
delete payloads. If we want to modify IKEv2 we need to state so
explictly, not just assume people do same assumptions on the missing
text in RFC5996.
> 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.
Most likely yes, or the other end assumes that state is messed up, and
deletes the whole IKE SA, and starts over (which is what RFC5996
suggests).
> 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:
It is better not to assume people do things same way unless explictly
specified, which is why I think the new high availibility protocol
needs to have text explaining these situations. I do not really care
which way the text is written as long as it is there and tells how to
handle these situations.
> 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.
Note, that the assumption here is that the unrecognized SPI here is
not negotiated over the same IKE SA over which the INVALID_SPI is
sent, thus there is no point of sending delete notifications or
anything similar over the new IKE SA we have with the peer. It is
assumed that the INVALID_SPI for SPI x belonging to the old IKE SA
will most likely trigger liveness check on that old IKE SA, which will
then fail as the other end has rebooted and that will cause old IKE SA
and the Child SAs being deleted.
IKEv2 do assume that if IKE SA is up, then all Child SAs are also up,
unless explictly deleted.
The text above does not even try to cover high availibility cases, as
they were outside the scope of original IKEv2 (and IKEv2bis) work.
> The first thing here is that we don't know what kind of exchanges they
> were.
The one who is throwing away the exchanges he is trying to do, does
know what those are. If the exchanges are already finished then there
is no way to know what they were, and whether they were processed by
the other end or whether they were transferred to the fall back pair.
> Okay, here's my take on this:
That is good start, but it should be put to the draft to be useful.
> : 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.
I agree on that. Adding text for INVALID_SPI handling would most
likely be best.
> : 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.
Yes, I think this is actually covered by the 2.25 and 2.25.1. 2.25
says it even better and says you delete the Child SA:
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
a request to rekey a Child SA that does not exist. The SA that the
initiator attempted to rekey is indicated by the SPI field in the
Notify payload, which is copied from the SPI field in the REKEY_SA
notification. A peer that receives a CHILD_SA_NOT_FOUND notification
SHOULD silently delete the Child SA (if it still exists) and send a
request to create a new Child SA from scratch (if the Child SA does
not yet exist).
> : 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.
But this will leave A with half-closed SAs. The text in 2.25.1 assumes
that the other pair of the SA was deleted because of the exchange
collisions, so it does not need to care about the half-closed SAs as
there will not be such in that situation.
> I don't see anything that prevents working connections.
But in some cases there is leftover half-closed SAs which by IKEv2 the
other end cannot delete without deleting the whole IKE SA. We might
need some way to resolve those.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
