Yaron Sheffer writes:
> Hi Pasi,
>
> Tero's mail gives a clearer explanation of the situation than your proposed
> text. Gluing the two together, how about replacing your last paragraph with:
>
> If the failure is related to creating the IKE SA (for example,
> AUTHENTICATION_FAILED), the IKE_SA is not created. Note that although the
> IKE_AUTH messages are encrypted and integrity protected, if the peer
> receiving this notification has not authenticated the other end yet (or if
> the peer fails to authenticate the other end for some reason), the
> information needs to be treated with caution. More precisely, (assuming that
> the MAC verifies correctly) the sender of the error indication is known to
> be the responder of the IKE_SA_INIT exchange, but the sender's identity
> cannot be assured.
That is also good, but I would like to add also something about what
implementations should do in that situation.
Texts with "treated with caution" etc are fine for specifications, but
are really annoying for implementors. What does that mean for my
implementation? What kind of things should I do after that?
I.e. it should tell following things:
- If properly MACed error reply is received, the IKE SA creation
fails, and no more retransmissions is sent.
- This is not fatal permanent error as the identity of the other end
could not be proven, meaning active attacker could have faked
those messages.
- Because of this it should still retry IKE SA creation from the
beginning several times, before completely giving up (and perhaps
enable multiple IKE_SA_INIT response processing described in
section 2.4).
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
